1

I have an abstract class and a class which extends it and implements the methods without adding further methods of its own. Let's call the classes A and B. B extends A. should i create an instance of class B like this

A newInstance = new B();

or like this

B newInstance = new B();

Does it make any difference and which is a better practice ?

user3453833
  • 33
  • 1
  • 7
  • If the method is a method of A you may use either form. Which you use is dependent on the circumstances. If your `newInstance` variable may be assigned any of several subclasses of A you obviously must use A. And if you intend to treat your B like an A (not use any methods unique to B, eg) then you generally should call it an A. But if you everywhere regard the object as a B you should call it a B. (It's a judgment call.) – Hot Licks Mar 24 '14 at 02:48
  • @SotiriosDelimanolis - I'm not sure that this is a duplicate (at least of that thread). In some ways, programming to an abstract class is similar to programming to an interface, but in other ways it is quite a bit different. – Ted Hopp Mar 24 '14 at 02:56
  • @TedHopp In my opinion, `Interface` shouldn't be taken literally to mean Java's `interface`. It should be taken as a meaning a programming interface/contract. – Sotirios Delimanolis Mar 24 '14 at 02:57
  • Also, consider, if the choice seems arbitrary, prefer higher points in the hierarchy. You *usually* don't want to constrain types any more than you need to. For example, if you have a variable that holds a set, and you don't actually care what type of set it is it is, make it a `Set` instead of, e.g., a `HashSet`. Then you can switch to another type set later if the need arises without changing code. – Jason C Mar 24 '14 at 02:57

2 Answers2

0

Does it make any difference and which is a better practice ?

Programming to an interface rather to an implementation it's the preffered way, Read more here --> What does it mean to "program to an interface"? . The difference is that you follow a contract rather than an implementation if you have to change the implementation with the same contract you ensure that you only have to change the object creation part.

In your example if you define like this

A newInstance = new B();

You only can use methods that are visible in A contract.

And in this case:

B newInstance = new B();

You can use methods that are visible in B contract, and as B has a IS-A relationship with A you can use A methods too.

Community
  • 1
  • 1
nachokk
  • 14,363
  • 4
  • 24
  • 53
-2

For maintainability, I'd go for the second one:

B newInstance = new B();

Obviously, it doesn't matter currently, since A and B are identical in terms of fields and methods (according to what you said).

However, say your class B changes. You add a method, or a field. If you declared your new instance as A newInstance = new B(), you cannot access the change you made in B.

And just as a second point, it makes more sense from a layman's perspective, to use the second one.

ryrich
  • 2,164
  • 16
  • 24
  • -1 For maintainability the 1st one is the preferred way `A a = new B()` . – nachokk Mar 24 '14 at 03:02
  • Well, I guess what I mean is, when `B` changes, the first option will no longer be preferred. Right? – ryrich Mar 24 '14 at 03:04
  • The whole point of programming to an interface is that you don't see the changes in the implementation from the client source code. Your point is moot. – Sotirios Delimanolis Mar 24 '14 at 03:08
  • In fact, @SotiriosDelimanolis is right, you abstract about implementation details and you focus in *what* they do and not in *how*. – nachokk Mar 24 '14 at 03:11