I am confused by a common situation I see in java. A new Instance is created from a derived class but uses a pointer(or is that reference?) From the superclass. For Example: List p = new LinkedList(); why not just code, LinkedList p = new LinkedList(); another Example: Set h = new HashSet(); instead of, HashSet h = new HashSet Please answer in my question with maybe an example of your own or reference my examples please. Thanks Any help is appreciated.
I am familiar with the keyword 'Set' in Visual Basic but have not as yet seen it anywhere in java. (OK, it appears I may have misunderstood your use of 'Set') A variable of some type object is a reference to that object and not the object itself. [ April 19, 2003: Message edited by: Donald R. Cossitt ]
Joined: Sep 28, 2002
Its interesting because, If I create a List reference, that would mean I am expecting to refer to a List object, however LinkedList is derived and may add to List. So how could a smaller object reference refer to a bigger object ? or more importantly why would you do such a thing ? [ April 19, 2003: Message edited by: Nick Delauney ]
The idea is to swap the objects without affecting the code where these objects are used. agree with Eugene List, Set are interfaces and not the classes... You cannot instantiate them.... you can create directly the LinkedList object or the HashSet object also.... these are the examples of OOPS... the basic three principle of OOPS encapsulation, inheritance and polymorphism
I think what everyone is trying to say is that using List or Set makes it easy to change from a LinkedList to some other List implementation. In such a case, the less code you have to change, the less chance you have of introducing defects.
Originally posted by Layne Lund: I think what everyone is trying to say is that using List or Set makes it easy to change from a LinkedList to some other List implementation. In such a case, the less code you have to change, the less chance you have of introducing defects.
that's one thing and the other one is about exposing things to the client. The client can depend on 1)the return value of Your class's method or 2)the instance variable of Your class.(not prescribed). 3)the parameter type of Your class's method 4)Your class's interface to achieve polymorphism. The less exposure will stop the "ripple effect" into the client code. Means, that if Your class is having a method f1 , returning List then client will code List l = new YourClass().f1(); But YourClass's f1 can use any implementation , for example ArrayList, LinkedList , SortedList ot whatever ... but, if f1 is returning LinkedList then client will code ArrayList l = new YourClass().f1(); when you feel ArrayList is not effecient ,then the client will also need to get change . In simple code to Spouse and not to Wife/Husband. Spouse->interface Wife/Husband-> implementation Please also note the abstraction usage here . unless the Husband want to code to a Wife like then, it's better to use the higher abstraction of Spouse. Moral of the story: go higher the abstraction to achive better polymorphism/substitutability Hope i am clear
Joined: Dec 06, 2001
Originally posted by aadhi agathi: The less exposure will stop the "ripple effect" into the client code. Means, that if Your class is having a method f1 , returning List then ... (snip)
Well, I wasn't planning on going down that road since the original question only dealt with creating an object. However, the point is well taken that this kind of programming is even more useful with return types and parameters of a method, as illustrated. [ April 23, 2003: Message edited by: Layne Lund ]