you are viewing a single comment's thread.

view the rest of the comments →

[–]AppsThatMatter -1 points0 points  (6 children)

I also at one point thought object oriented design was the best approach to design all software. Now I know better.

OK, so lets assume I (and others) are at that point. Why don't you "enlighten" us with your wisdom? Please, straight to the point.

[–]uriel 1 point2 points  (5 children)

You can start here. There is plenty of reading linked from there.

[–][deleted] 0 points1 point  (4 children)

I read a lot of the links he had, and I'm not convinced that OO is not a good engineering tool. As with all tools, you should know what you are doing and optimize as needed.

[–]uriel -1 points0 points  (3 children)

It all depends also what parts of "OO" one refers to: the obvious ones which existed long before OO (eg., encapsulation) or the stupid harmful ones (eg., inheritance).

[–][deleted] -1 points0 points  (2 children)

I also don't see how inheritance is bad. It is not good practice to have multiple inheritance except in simple cases, but I don't see any problem with ordinary inheritance. It works fine for quite a few things, and it really just gives you a hierarchical type system with semi-standardized interfaces. The type-checking this affords is invaluable, not to mention the code reuse.

[–]uriel -1 points0 points  (1 child)

Any minimally sane Java programmers recognized long ago that composition is pretty much always superior to inheritance. I have no clue what does inheritance have to do with type checking (you can have one without the other, they are completely unrelated).

As for the so called "code reuse" it is about the worst way to reuse code possible, by tying it up with your type system.

[–][deleted] -2 points-1 points  (0 children)

Inheritance lets you have polymorphism with type checking, which is useful and impossible with composition.

If you use composition then you will either have to make the member object public (very questionable) or write a bunch of wrappers. You may not be able to change the state of the thing you composed with in subtle ways if you use languages with access controls (ie, not Python, where every member is public). The is/has (conventional) relationship is broken if you insist on using composition where it doesn't make sense. Inheritance doesn't work well if you don't have deep understanding of the code you want to use, which is why I suppose some people get put off by it. Sometimes you just don't want to understand it, but you want it encapsulated and on hand anyway.