i can make a collection (an arraylist, for example) of Person objects - the interface.
I can then iterate over the collection, calling the printBirthday() method for them, since the printBirthday method is required by the Person interface.
Now, it doesn't matter if i stick in an Employee, a Manager, a Bum, or an Infant, since they all implement Person, and my code works.
Two years from now, someone wants to write a CollegeStudent class. As long as they implement my Person interface, i don't need to touch my code for it to work.
That's pretty cool. Somebody is writing a class i never DREAMED of, two years after I wrote my code, and my code can handle it. I get to sit on the beach reading "Harry Potter", while THEY write new code, and I know my code is rock-solid.
There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors
Unable to create an instance of the superclass or interface. Well, sometimes, but not always.
What you do is to specify a set of methods you are going to use. In the examples you posted you tell the compiler you are going to use the methods in the Person class in the foo package. Obviously Employee is a subclass of Person, so it has all the same methods. You are telling the compiler to use a "Person" and give it an "Employee" object to deal with.
Imagine I had some children around and asked them, "Would you like a biscuit?" [This analogy won't work in America.] "Yes, Campbell, we would, thank you." "There you go, Dave, there's a chocolate biscuit." "Thank you." "There you go, Alan, there's a wafer biscuit." "Thank you." "There you go, Simon, there's a caramel biscuit." "Thank you."
Now, each of them has the same (a biscuit) and each has something different, but each biscuit has an "eatMe()" method.
This will not work for methods declared in the subclasses; you cannot expect them to invoke the biscuit's "dunkIncoffee()" method because that is only implemented for the GingerBiscuit subclass.