Re: Interfaces Question - I am missing something

I think what you're missing about interfaces is the scenario where
you want to use them.

The code you posted above already knows that there are three objects
and that they are different types. It knows that one is a Dog, one
is a Cat, and one is a Truck. It doesn't need interfaces because it
is already aware of what class every object is. After all, it is the
one who has created the objects, so of course it knows what class
they are.

But that is not always how it works. Let me flesh out your example.
I'm going to say there's a guy named Bob, and he manages his life
all on his own. The class that represents Bob looks like this:

    class Bob {
        Dog d;
        Cat c;
        Truck t;

        void obtainWorldlyPossessions() {
            d = new Dog();
            c = new Cat();
            t = new Truck();
        }

        void saturdayChores() {
            d.wash();
            c.wash();
            t.wash();
        }
    }

When Bob is doing his chores on Saturday, he can wash his dog and
cat and truck, and he doesn't need an interface because he knows
all about his possessions.

Now suppose Bob wants to go out of town and he wants to hire someone
to take care of his pets while he's gone. You could certainly
create a custom pet sitter class that knows how to deal with Bob's
stuff specifically:

    class BobPetSitter {
        void watchBobsPets(Bob bob) {
            bob.d.wash();
            bob.c.wash();
        }
    }

Then Bob can arrange to have his pets cared for like this:

    // (a method in class Bob...)
    void prepForVacation() {
        BobPetSitter sitter = new BobPetSitter();
        sitter.watchBobsPets(this);
    }

But you can see this class is only useful for Bob's pets. Maybe
you want to go into business and create a PetSitter that can
wash anyone's pets. Your PetSitter class wants to be able to get
as much business as possible, so if the pets contain their own
wash() method, you'd like to be able to support washing any kind
of pet, without special knowledge for each one. If you get a
potential customer who has a pet emu, you want to be able to wash
that emu, not throw up your hands and say, "I can't wash emus,
so I can't take this job. I could learn to wash emus, but that's
complicated." No, you want to be able to say, "If it's a pet,
I can handle it."

So, let's change the scenario and say that Cat and Dog and Emu all
implement the Pet interface:

    interface Pet {
        void wash();
    }

Then we can make a PetSitter than can wash any type of pet (and
multiple ones):

    class PetSitter {
        List<Pet> pets = new ArrayList<Pet>();

        void addPet(Pet pet) {
            pets.add(pet);
        }

        void washAllPets() {
            for (Pet p : pets) {
                p.wash();
            }
        }
    }

Now Bob can arrange a pet sitter like this instead:

    // (a method in class Bob...)
    void prepForVacation() {
        PetSitter sitter = new PetSitter();
        sitter.addPet(d);
        sitter.addPet(c);
    }

The great thing about PetSitter class is that now it can take any
customer. It doesn't need any knowledge at all of what kind of
pets it's washing. It doesn't need to know how many. It can wash
a new type of pet it has never heard of before.

The reason that this matters is that PetSitter is not very closely
associated with Bob. It has a casual, loose relationship. Bob
might like to hire a different PetSitter next time that has a
better price. And somebody who owns an Emu can hire this same
PetSitter to wash it, even though the PetSitter washes different
types of Pets for Bob.

The point is that the Pet interface has allowed the PetSitter
to see all pets as equivalent, because there is no reason that
the PetSitter needs to know the difference. Bob needs to know
the differences because he created the pet objects, and he knows
what kinds of pets he wants and why, but the PetSitter doesn't
need to know this stuff just to wash the pets. The interface
allows PetSitter to ignore the difference it doesn't care about
(that it would be wasteful and pointless to care about) and focus
on the commonalities that it does care about.

Side notes:
(1) Yes, pets need to be fed too. Ignored for simplicity.
(2) Even though Truck has a wash() method, I didn't call it
a pet. I assumed its meaning of wash() might be different
somehow. But you could take it a step further and generalize
and create an interface called Washable.