On 3/19/12 5:11 PM, deadalnix wrote:
Le 19/03/2012 21:39, F i L a écrit :
deadalnix wrote:
That is totally broken design. The fact that mothership inherit from
ship is a pretty good example of misusing inheritance. The fireMissle
is useless unless you KNOW that you are manipulating a MotherShip, so
you totally break all the abstraction the OOP could provide.
Other objects can contain references to MotherShip types directly, while
the main update loop works with the base type. Or, perhaps more
relevant, an object could execute "fire()" on a list of Ships, which
MotherShip can be a part of because it IS a Ship, regardless if weather
it can overwrite Ship's functions or not. I can't imagine a different
way of defining this relationship short of inheriting from a common
interface which would require duplicating the fire() function in both
types (given that fire() is designed to ensure common behavior among all
Ship types).
As all functionnality of a Ship are final, you basically ends up with a
mother ship that is a ship and then have some other function that are de
facto separated and unreachable from ship. Separation of concerns tells
us that this should be 2 different objects.
This is not a broken concept at all. I'm always open to different ideas,
but I'm fairly surprised you're arguing this case. Being able to extend
a type, even when the extensions are entirely additive, is a fundamental
principle of OOP design.
As teha ddition of MotherShip to Ship are orthogonal, I would argue that
mothership functionality is better suited for its own
class/struct/whatever, and agregated with a ship.
The whole « is a » thing is largely misunderstood. See
http://www.objectmentor.com/resources/articles/lsp.pdf for example.
I agree 100%. Inheriting to extend is borderline fallacious.
Regarding the matter at hand, it's true that the interplay of final
class with final methods has an odd and less useful corner case, but I
don't think it's worth worrying about it.
Andrei
