How would you design the relationship between these two classes?

Say you had two classes:

Code:

---

class Adult {
    public:
        void crawl() {...}
        void run() {...}
}

class Baby {
    public:
        void crawl() {...}
}

---

method crawl() uses the same implementation in both classes. How would you 'factor out' method crawl into a base class and have the relationship make sense? I can only think of the following solutions, none of which seem very good to me.

1. I could have Adult inherit from Baby (deleting Adult's crawl() implementation), but then i would be saying that an Adult 'is-a' Baby.

2. I could compose a Baby object in Adult so as to re-use method crawl(). But again, this would imply that an Adult is composed of a Baby, which doesn't make a whole lot of sense.

3. I could have a Human base class with a concrete implementation of crawl() which both Adult and Baby extend from. However, Baby would be completely empty.

4. I could have a Human base class with a concrete implementation of method crawl(), which both Adult and Baby compose. In this case, Baby would have a crawl() method that simply calls crawl() in Human.

Is there a better way?

I think you have the right idea between 3 and 4, depending on what exactly you want the crawl() function to do. 1 and 2 don't use inheritance correctly. An example I like is the Animal class which has a makeNoise() function and then is implemented in sub-classes such as Horse which will neigh when calling makeNoise() or dog which will bark when calling makeNoise().

You could use 3. But make sure make a typedef for Baby as an alias to Human. Remember that this would be an implementation detail (hide it, hide it, hide it!).
Another way might be to create a common base class with protected or private inheritance.

Another way to go is to have both adult and baby inherit from a human baseclass where you have a member "move" (bad name i know given the std::move in c++11) which takes an enum with the mode of movement. This way you can have babys implementation of move when you send it the enum value corresponding to crawl and throw an exception for all others. Adult can have implementation for crawl, walk, run and so on.

Don't typedef Baby to Human. Make it a real class. If it's empty, so what? An empty class doesn't actually really cost you anything (maybe you have to write some forwarding constructors, but not if you have a C++11 compiler), but gains you a lot if you want to put something in there later. Typedefs are syntactically incompatible in a number of cases.

That said, I like also like Shakti's solution.

If it's really only about sharing the implementation of the crawl() method and you don't care about the actual relationship between the classes, consider writing a normal function that takes references to the relevant class members to work on, or a mixin/trait class.

The two concepts Adult and Baby fail the basic substitution principle. A baby is not a kind of adult, nor is an adult a kind of baby.

It doesn't seem to make sense for either one of them to inherit from the other.

Hmm... one thing about deriving Baby and Adult from a Human abstract base class is that if "growing up" is a possible course of action, then the Baby object will have to be replaced with an Adult object with various other data (and perhaps family relationships, etc) remaining mostly the same.

Some instance of the strategy pattern where say, a Human object has a HumanBehaviour (or something more specific) could then allow for the substitution of BabyBehaviour with AdultBehaviour when the time comes.