OOP program, Pure substitution vs extending types

[mirhagk]

I am reading a book for a course on OOP right now, and it suggests that you should try to have every object be a pure substitute. What it means by that is derived types should only change implementation, not interface. ie don't add any new public functions or variables. Personally I think that extending types, and having types support multiple interfaces is much better than having an object with potentially useless functions. For instance they showed a control system, where you have a thermostat control the air conditioner. Then the air conditioner breaks and you replace it with a heat pump, that can cool and heat. See below:

code:

Cooling System ------------------ cool() Air Conditioner isa Cooling System ----------------- cool() Heat Pump isa Cooling System ------------ cool() heat()

They suggest that the original cooling system is a flawed class, and instead should have had both heat() and cool(), and that the air conditioner should have simply done nothing for heat(). I see an obvious flaw in this in that the thermostat will keep telling the air conditioner to heat up the room, and it'd keep doing nothing. I'd rather see a separate interface for heating and cooling, and have the air conditioner implement one, and the heat pump implement both. That way the thermostat could have a separate object for each, and could for instance have a gas heater for the heating system, and the air conditioner for the cooling system. It also has the benefit of without a heating system the pointer would just be null, so the thermostat could know that the room can't be heated.

What do you guys think, would you rather see the book's version, or my version?

[wtd]

I see absolutely no problem with extending types. A well-designed program should never say "I expect SuperType, but want to do something that only SubType can do."

[mirhagk]

alright good, this book seems really strange. It sucks, I'm using this for a course right now, and the book talks about how things in C++ literally just got standardized. First version was released in '96, and the 2nd released in 2000 I believe.

[2goto1]

mirhagk @ Sat Apr 20, 2013 12:44 pm wrote:

What it means by that is derived types should only change implementation, not interface

This is a good general practice, particularly in larger systems. This allows systems to scale much easier to a greater degree. Particularly if you favour composition over inheritance. Using approaches such as inversion of control, http://martinfowler.com/articles/injection.html, and other strategies, allows you to accomplish this.

It's hard to say whether the book is bad or good. Perhaps the example that they cite is bad, but it's difficult to say based on your abbreviated summary of their example and purpose of the example. Seeing it in the greater context of the chapter or book might help to decide.

[wtd]

To be fair, in terms of compiler implementation of standards, C++ might as well have just been standardized.

Also... using C++ to teach OOP? Ouch.

[mirhagk]

Yeah, and since it's such an old book, all the examples seem very dated. The languages they as other competing languages are Fortran, Lisp, and assembly.

I do wish there was a different language to teach OOP. C# would be amazing, but even Java would be easier. But it's a simple course, and there's 5 assignments, and an exam, then it's all over, and it's work at my own pace (which means it'll be done in like a week).

[Insectoid]

There's plenty of good languages to learn OOP from. Ruby is especially good, since literally everything in it is an object, and it has none of the syntax bloat of C++ or Java.