Difference:
Consider the scenario:
There exists a abstract implementation (say 'AbstractImpl' ) of a interface (say 'InterfaceA'). Concrete implementaion (say 'ConcreteImpl') extends 'AbstractImpl'. (This is sometimes called Template Design Pattern).
What is the difference between:
1.
AbstractImpl a=new ConcreteImpl();
2.
InterfaceA b =new ConcreteImpl();
Does it makes a difference on either way of instantiation? What is a better approach? and Why?
> Does it makes a difference on either way of> instantiation?There is no difference in the instantiation. The instantion is 'new ConcreteImpl()' in both cases.> What is a better approach? and Why?Which is a better vehicle, a plane or a submarine?
Whatever results in more reusable code is the better approach.
Code relying on AbstractImpl (in method arguments, member fields) will not be able to work with another (perhaps at this moment unconceivable) alternative abstract implementation. So if that code doesn't rely on details of AbstractImpl (which I suspect it doesn't), it's more flexible to refer to the interface.
Lokoa at 2007-7-16 23:54:06 >
> Which is a better vehicle, a plane or a submarine?Plane. It's easier to get a plane underwater than it is to get a submarine into the air.
If it -can- be either one then do Abstract. I don't agree that it's "either-or, who cares", because the goal is to make robust, reusable software using good design practices.
For example, if a Bird is an interface and a FlyingBird is an abstract, which defines the method fly(). Anytime you have a bird that flies, you want to put them under FlyingBird so they get the fly method. But if you have a penguin, you can't put them under FlyingBird, you have to put them under Bird, or create a new abstract class for them to be under.
Hope this helps.
- Amber
> For example, if a Bird is an interface and a
> FlyingBird is an abstract, which defines the method
> fly().
I can't think of a reason why you would want a FlyingBird abstract class. FlyingBird would be an interface. Or even better, Flier would be the interface. Consider if you create another abstract class SwimmingBird. Then you can't create a Duck as ducks fly and swim.
In any event this has nothing to do with the OPs question. the question was about the common practice of creating an interface and then creating an default abstract version of that class (see AbstractList).
Also, the more I learn the less useful 'Bird, FlyingBird' type example seem. They really don't have anything to do with good real-world design and I think they get a lot of people way off track, at least in Java.
Abstract classes are for the birds. They are an 80's way of OO design.
> Consider the scenario:
>
> There exists a abstract implementation (say
> 'AbstractImpl' ) of a interface (say 'InterfaceA').
> Concrete implementaion (say 'ConcreteImpl') extends
> 'AbstractImpl'. (This is sometimes called Template
> Design Pattern).
>
> What is the difference between:
> 1.
> AbstractImpl a=new ConcreteImpl();
>
> 2.
> InterfaceA b = new ConcreteImpl();
>
> Does it makes a difference on either way of
> instantiation? What is a better approach? and Why?
No. They are the same.
I suspect the implicit question is about the declaration. This really depends on the use, but generally it's a good idea to declare types by interface rather than an implementation. If your code operates off of a "InteraceA" as the type rather than "AbstractImpl" as the type then you can swap out any InterfaceA without having to modify code. Once again, I am speaking in generalities and this does not apply to all scenarios.
> In any event this has nothing to do with the OPs
> question. the question was about the common practice
> of creating an interface and then creating an default
> abstract version of that class (see AbstractList).
Based upon the example I believe the OP's confusion, if not their explicit question, is over how type should be declared. For example, whether or not you declare a List<String> or an ArrayList<String>.
Also, as a bit of further explanation to the OP it's not so much the declaration that is important as it is your method signatures. If your method specifies it returns an InterfaceA then you can have it return any InterfaceA, if the method returns an AbstractImpl you can never change it to a different InterfaceA that's not necessarily an AbstractImpl. The declaration can still be important, but that's only going to affect the class it's delared in (assuming external classes don't access it directly). The method signature will get you into trouble as every client will be affected.
