Win a copy of Microservices Testing (Live Project) this week in the Spring forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Liutauras Vilda
  • Henry Wong
  • Devaka Cooray
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Al Hobbs
  • Carey Brown
Bartenders:
  • Piet Souris
  • Mikalai Zaikin
  • Himai Minh

Please help understand this from Effective Java book by Joshua Bloch

 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Page 93 of the book says:

"If you want to have two classes extend the same abstract class, you have to place the the abstract class high up in the type hierarchy where it subclasses an ancestor of both the classes. Unfortunately, this causes great collateral damage to the type hierarchy, forcing all descendants of the common ancestor to extend the new abstract class whether or not it is appropriate for them to do so."

But , I dont think it would force all descendants of the common ancestor to extend the new abstract class. The descendants can continue to extend the ancestor class itself right? Please help me understand this.

 
Ranch Hand
Posts: 1376
Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Since Java is object oriented, let us consider it in object oriented way.
Consider this example
We have Car and Bike.

Both vehicles runs on Petrol. So I can make an abstract class PetrolVehicle and let Car and Bike extends it.
Now code becomes

So far it is fine .. there is no problem with code.
Problem may arise as soon as you start adding subclasses to Car. Now Car can run on Petrol, Diesel, CNG etc.
Let us say we want to extend Car class to make one subclass - CNGCar

Now the problem is CNGCar has accessor - PetrolVehicle which contradicts....
That's what author means - "Unfortunately, this causes great collateral damage to the type hierarchy, forcing all descendants of the common ancestor to extend the new abstract class whether or not it is appropriate for them to do so."
Hope I have made myelf clear.
 
Abhay Agarwal
Ranch Hand
Posts: 1376
Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Btw . Welcome to Javaranch !!
 
Rancher
Posts: 43028
76
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Having PetrolVehicle is a good example of what one should probably not have in an object hierarchy - it supposes the single most important thing about different vehicles is the type fuel it uses. While that may be true for some specialized applications, more generally we would be in trouble if later it emerges that differentiating based on the number of wheels is much more important? We'd have to recreate the object model fundamentally.

So since the fuel type is only one aspect of a vehicle, it's better to make that an interface instead of its own class. That way the object model can even accommodate if a car is available in both petrol and natural gas variants (by implementing both interfaces).
 
Abhay Agarwal
Ranch Hand
Posts: 1376
Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Agreed with Ulf .. Having PetrolVechicle is not good design .. I just created this whole [ supposedly bad design] scenario to explain what is written in Effective Java book...
 
Abhay Agarwal
Ranch Hand
Posts: 1376
Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

So since the fuel type is only one aspect of a vehicle, it's better to make that an interface instead of its own class. That way the object model can even accommodate if a car is available in both petrol and natural gas variants (by implementing both interfaces).


I think we can even define Fuel Type as Enum and have Petrol Natural Gas etc inside it. And class can have Enum array type instance variable to store Fuel Type

 
Marshal
Posts: 76061
362
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Favour composition over inheritance

You have an Engine interface like here. Then you can have a hierarchy of Engines, even one powered by squirrels.

Not only does that solve the problem you are having, but it does not create diamond inheritance.
 
Ulf Dittmer
Rancher
Posts: 43028
76
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Abhay Agarwal wrote:I think we can even define Fuel Type as Enum and have Petrol Natural Gas etc inside it. And class can have Enum array type instance variable to store Fuel Type


Good point. That works as long as each car has just one single fuel type. So it would be OK if by "car" we refer to a specific instance of a car, like "your car". It wouldn't work if by "car" we mean a model, like "BMW X 1", because that can have either a petrol or a diesel engine. So it depends on what we'll be using the object model for.
 
Shankhararaman Subramanian
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Abhay, Ulf Dittmer and Champbell. Now I understand what those lines mean exactly.
 
Campbell Ritchie
Marshal
Posts: 76061
362
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You're welcome
 
reply
    Bookmark Topic Watch Topic
  • New Topic