How would you design the relationship between these two classes?

Say you had these two classes:

Code :

---

public class Adult {
	public void crawl() {...}
	public void walk() {...}
	public void run() {...}
}
 
public class Baby {
	public void crawl() {...}
}

---

And pretend that crawl(), walk(), and run() are different enough to deem their separation into their own methods appropriate. Also, assume that crawl() in both Adult and Baby share the same implementation. What is the most appropriate way to make a relationship between these two classes? I have come up with a couple option below:

1. Adult extends Baby. This seems appropriate until you explain the relationship in English: "An Adult "is-a" Baby". Then it doesn't make sense.

Code :

---

public class Baby {
	public void crawl() {...}
}
 
public class Adult extends Baby {
	public void walk() {...}
	public void run() {...}
}

---

2. Adult and Baby extend an abstract class Human. However, in this case, there's no real difference in implementation of crawl() - I am just creating the superclass Human purely for the sake of the relationship making 'sense'.

Code :

---

public abstract class Human {
	public abstract void crawl();
}
 
public class Adult extends Human {
	@Override
	public void crawl() {...}
	public void walk() {...}
	public void run() {...}
}
 
public class Baby extends Human {
	@Override
	public void crawl() {...}
}

---

I feel like I am doing something wrong either way. What is the best way to code this relationship. If it helps at all, this relates to a real coding problem I am having in a game. I have an NPC and playable Player class. Player has all the behaviors and attributes of an NPC + more, but it just doesn't seem 'logical' to extend NPC and call my Player class an NPC.

Thanks in advance.

I think your second organization makes more sense; except, I don't think you need to make crawl() abstract. Since it is the same for adult and baby, you can define exactly what crawl() does right in the Human class.

Google the phrases "composition versus inheritance" and "composition over inheritance". Each technique has its use in different situations. In your case you should evaluate whether composition may be more appropriate...for instance, every adult may not be baby, but every adult has a kid inside ;)

@copeg. So you think that the best solution would be to instantiate an object of Baby within Adult to get code re-use? I think your reasoning that there is a child inside us all is creative. IMO, a little bit of a stretch, but creative nonetheless :).

@snowguy. If I were to use the design that you suggested and just have a Human class and an Adult class, how would Baby fit in? Are you saying that I wouldn't even need a Baby class? I guess I could create an object named baby (ie. Human baby = new Human()), but I don't like the idea that Human class models a baby whereas an Adult class models an adult. It would be nice to have a Baby class model a baby too.

Quote:

---

So you think that the best solution would be to instantiate an object of Baby within Adult to get code re-use? I think your reasoning that there is a child inside us all is creative. IMO, a little bit of a stretch, but creative nonetheless

---

I didn't say best solution, I suggested you look at the idea of composition. In my experience, many situations make much more sense to design away from inheritance for the benefit of re-usability, structure, and maintainability. This isn't to say inheritance isn't powerful or wrong, it is to say you need to think about your design from other standpoints and what you think makes sense from the standpoint of re-usability, structure, and maintainability. And to keep in mind the often cited phrase: Encapsulate what changes. In my view, your post doesn't have enough information to pose what is the 'best' design (and best is relative - you may look at your code months from now and think 'what the heck was I thinking')

What you said makes sense. Thanks a lot for the help, copeg.