Changes 12/22/14 - EIMACS Sets and Maps, ListQueue analysis

Today, I worked though the set and map unit of EIMACS.  It's been pretty straight forward, and mostly review.

Kevin emailed me after seeing my post about the ListQueue exercise.  He had a couple of questions about the implementation:

1. Can ListQueue be substituted polymorphically anywhere a LinkedList is used?
2. What are the implications of inheriting both interface and implementation
3. Since Java doesn't have private inheritance, should composition be used instead?
4. How does this example play with the Liskov Substitution Principle?

I wasn't familiar with some of the terminology he used, but I tried to answer his questions.  For his first question about substitution, as far as I can tell ListQueue could be substituted for any LinkedList<Object> anywhere in the code, since it is a subclass which changes no functionality.  However, it's important to note that ListQueue hard codes in the fact that it inherits from LinkedList<Object> and not LinkedList<E>, so this object could only be used when the compiler is expecting a LinkedList<Object>, and not, for example, when using a LinkedList<String>.

I'm not sure what the second question means, since LinkedList<E> is a concrete class that implements List<E>.

For question three, I'm first going to write out what private inheritance and composition are.

• Private inheritance is when a child class inherits from a base class, but does not make any of the methods of the base class (including the public ones) publicly accessible.
• Composition is when one object internally relies on other objects.  In this case, composition would make the LinkedList<E> a private object defined within ListQueue, rather than a direct inheritance.

I think composition would make more sense for the ListQueue class, although it's not really clear what the purpose/role is anyway so it's hard to say

For question four, the Liskov substitution principle states that if S is a subtype of T, any expectations for the public interface of T should also be assumed about S, and therefore S could be replaced with T.  This is only true when referring to a LinkedList of Objects.  I'm not sure if that qualifies as adhering to the principle.