vijaya sankarj,
I will say you have a bit confuse concept on REUSE according to the affirmation of Way 1 from you.
"vijaya sankarj" wrote:
Way 1 : i can instantiate an object for class InterfaceTest at my class .
DISADVANTAGE : if you instantiate another object means its implicitly tells that you create an copy of InterfaceTest class. So it wont come under the category REUSE..
Way 2 : i can extend InterfaceTest in my class .......well done good but
DISADVANTAGE : If interfaceTest contains lot of methods other than m1 and m2 means you have to allocate memory for that methods also(waste na) in your class
Way 3 : USING INTERFACE >>>>>>
make m1 and m2 methods inside an interface (now see above program once again completely)
so you can accesses it from another class like extend but one small difference you are not pointing the unwanted method m3.....good luck.......
When one day you go through Thinking In Java, you might consider edit your post to change the
word "DISADVANTAGE".
REUSE, we have two ways in general, composition (your Way 1) and inheritance (your Way 2).
One should consider first using composition (mostly use in the way of delegation) if one is not trying to create a more specific class.
One should not just use inheritance simply because they want
polymorphism, only use inheritance when one need a more specific class.
One will use inheritance when create a specific class, but should consider interface inheritance (this is the good practice of coding to interface which repeated in a lot of design post) instead of class inheritance(i.e. implementation inheritance)
So, composition is one of the way of REUSE, and this will be used often in practice by good programmer with the concept of delegation.
Before I continue, I try to demonstrate with a Wrong (in term of concept and design) way of using inheritance, and a Correct (in term of concept and design) of using composition.
Now for your Way 2, you claim that the m3 method was not allocate to memory when using the interface without the m3, do you know that the class is loaded by class loader when you instantiate it (even you using interface type reference, because you still created the object of class that implement the interface). So, can you prove your so called memory saving with Java Profiler ? and show the result.
From your code, you need to purposely perform casting just to access method m3 ... now come to another point design, pure substitution on initial design ? one will only give up pure substitution when in that case where you are force to (e.g. when changing a legacy code). However, adapter design
pattern might help you on this.
When one day you go through GOF design pattern, you might consider edit your post to change it.
Now, I try to demonstrate using the above example with strategy design pattern, and you will see the combination of composition and inheritance, both use with coding to interface (or said interface inheritance is so important) brings the benefits.
In GOF design pattern, interface inheritance is the concept that use most.