• 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
  • Paul Clapham
  • Ron McLeod
  • Tim Cooke
  • Junilu Lacar
Sheriffs:
  • Rob Spoor
  • Devaka Cooray
  • Jeanne Boyarsky
Saloon Keepers:
  • Jesse Silverman
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
  • Tim Holloway
Bartenders:
  • Jj Roberts
  • Al Hobbs
  • Piet Souris

Bruce Eckel's On Java 8 - Inheritance Example

 
Ranch Hand
Posts: 45
IntelliJ IDE Python Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi, I am reading  "On Java 8" by Bruce Eckel and he writes such thing:

Sometimes you add new interface elements to a derived type, thus extending the interface. The new type can still substitute for the base type, but the substitution isn’t perfect because your new methods are not accessible from the base type. This can be described as an is-like-a relationship (my term). The new type has the interface of the old type but it also contains other methods, so you can’t really say it’s exactly the same. For example, consider an air conditioner. Suppose your house is wired with all the controls for cooling; that is, it has an interface that to control cooling. Imagine that the air conditioner breaks down and you replace it with a heat pump, which can both heat and cool. The heat pump is-like-an air conditioner, but it can do more.
Because the control system of your house is designed only to control cooling, it is restricted to communication with the cooling part of the new object. The interface of the new object is extended, and the existing system only knows about the original interface. Once you see this design it becomes clear that the base class “cooling system” is not general enough, and should be renamed to “temperature control system” so it can also include heating—at which point the substitution principle will work. However, this diagram shows what can happen with design in the real world.
When you see the substitution principle it’s easy to feel like this approach (pure substitution) is the only way to do things, and in fact it is nice if your design works out that way. But you’ll find there are times when it’s equally clear you must add new methods to the interface of a derived class (extension). With inspection both cases should be reasonably obvious



And here is diagram of his design of the problem:

image doesn't display: here is direct link: https://imgur.com/a/KilhSBO

I am not sure but I feel like this design is kinda ugly and I came up with such idea:



Which concept is better and why?
 
Saloon Keeper
Posts: 8704
71
Eclipse IDE Firefox Browser MySQL Database VI Editor Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
No, all those classes should not be sub-classes of Thermostat, a HeatPump  is-not-a Thermostat. A HeatPump has-a Thermostat. I can't come up with a term that would embrace both an AC and a HeatPump except for HVAC (heating ventilating and air conditioning).

"HeatExchanger" ?
 
Marshal
Posts: 74341
334
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
TemperatureController?
 
Campbell Ritchie
Marshal
Posts: 74341
334
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This would appear to be the missing link:-It shows the thermostat in a HAS‑A relationship with the cooling system. I am not convinced the thermostat would have a lowerTemperature() method. What a thermostat does is turn its device on and off, and sets the temperature it activates at.
I am finding the quote from Eckel hard to understand. If you have a thermostat to turn a cooking device on when the temperature exceeds its setting, a scenario I am unfamiliar with (‍), you simply activate the cool() method. The fact that a heat pump has a heat() method too is neither here nor there. All you need in that scenario is cool(). If you are using an object declared as CoolongSystem, any heat() method will be inaccessible. I can't see what is supposed to have changed in Java8.
 
Campbell Ritchie
Marshal
Posts: 74341
334
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
 
Campbell Ritchie
Marshal
Posts: 74341
334
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You can declare the same HeatPump both as a Heater and a Cooler. You can also have a HeaterAndCooler interface, extending the other two, and declare the HeatPump as that type. I fail to see what difference the enhancements to interfaces in Java8 made to this scenario.
 
Campbell Ritchie
Marshal
Posts: 74341
334
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Note the above classes are all mutable. It should be possible to envisage a scenario where the classes are immutable.
 
Andrzej Zahorski
Ranch Hand
Posts: 45
IntelliJ IDE Python Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Campbell Ritchie wrote:Note the above classes are all mutable. It should be possible to envisage a scenario where the classes are immutable.



Thank you for your response  and examples, they provide valuable insight and I wanted to point out two especially cool things:
  • Taking into account the lowest possible temperature
  • Objects.requireNonNull() - I didn't know about this method



  • Anyway, I just thought maybe what Bruce Eckel had it mind is the idea of "patching" the solution to allow new interactions, even if the end result is not the prettiest one, because when you just look at diagram it looks like someone hadn't idea about the future of the interface and text I quoted might support that point of view.

    Thank you again for taking your time and providing  the elaborate answer, especially because I asked this question on Discord and I bumped into dead silence there, and now, I feel like thermostat of my heart turned on the heater indeed

    If you would care to take a look, I could send you my copy/fragment of the book, because I am not sure I have enough experience to value it in terms of the information content, so it would be helpful too.
     
    Campbell Ritchie
    Marshal
    Posts: 74341
    334
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Andrzej Zahorski wrote:. . . especially cool things:

  • Taking into account the lowest possible temperature
  • . . .

    That isn't cool; it is positively freezing

    What we see hwere is the difficulty of adding things to a pre𢀑existing interface. The Java® solution was to allow interface methods with default implementations, which are of course called default methods.
    Please don't send people things, but post an extract, making sure it isn't large enough to violate copyright.
     
    You showed up just in time for the waffles! And this tiny ad:
    Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
    https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
    reply
      Bookmark Topic Watch Topic
    • New Topic