4 ms·

Forgive me, but I'm really new to programming, and I don't really understand why your example is something that shouldn't be used in real programming. Should a

Forgive me, but I'm really new to programming, and I don't really understand why your example is something that shouldn't be used in real programming. Should a Car be a Vehicle object instead of a sub-class?

driax 15y ago
The problem lies in that you never have a "Car" which should inherit "Vehicle". It's a question that never comes up in programming. The bad part of it, is that it sometimes makes new programmers look for these kind of concepts in their code, and write class-based code around them. Exactly the problem http://pyvideo.org/video/880/stop-writing-classes http://pyvideo.org/video/880/stop-writing-classes discusses. Basicly it teaches people to think in taxonomies, which is not good for object-oriented programming since it usually results in highly complicated code, with way to many classes and inheritance. Inheritance is mostly good for factoring out common code between different sub-classes. Or extending library classes in a way that wasn't thought of when they were written.
- zdw 15y ago
  Ditto on this. It's an abuse of the concept of inheritance, which teaches the wrong reasons to use the concept.
- deleted 15y ago
  [deleted]
- nikcub 15y ago
  I don't think I have ever read a programming book that teaches OO in the same way that most developers use it - that is implement top level first and then when you have commonalities between objects abstract them out into parent objects. Thinking about and mapping out class hierarchies is something that Java enterprise analysts do. A good example to teach OO would be a config parser. Write a config parsing object, then sub-class for parsing Yaml, INI, XML, etc.
- johnkchow 15y ago
  One of the very first things I learned almost immediately after college is that inheritance typically is a bad idea and that composition is a better strategy. With inheritance you have so much thinking overhead with parent to children relationships when most abstractions could easily be viewed as building it through small pieces. Its sad but during my 5 years in UCLA I have not heard the word "composition" once.
zdw 15y ago
The point is that OO isn't everything, and making the first thing people learn being class hierarchies colors their perceptions of programming in ways that sometimes are very damaging. For example, about 15 years ago I was an idiot and managed to get a job writing some text parsing code. I, of course, used what I just learned in my Comp Sci 101 "Intro to Programming" class and did a fully OO implementation in C++ with iostreams that took nearly a month to write, and never quite worked. Looking back, the solution was probably implementable in under 10 lines of a scripting language with judicious use of regex. The point is that people often fall for the first thing they're given, and OO (which incredibly useful when used properly) is an extremely enticing concept that can be very distracting from actually getting a job done.

driax 15y ago

The problem lies in that you never have a "Car" which should inherit "Vehicle". It's a question that never comes up in programming. The bad part of it, is that it sometimes makes new programmers look for these kind of concepts in their code, and write class-based code around them. Exactly the problem http://pyvideo.org/video/880/stop-writing-classes http://pyvideo.org/video/880/stop-writing-classes discusses. Basicly it teaches people to think in taxonomies, which is not good for object-oriented programming since it usually results in highly complicated code, with way to many classes and inheritance. Inheritance is mostly good for factoring out common code between different sub-classes. Or extending library classes in a way that wasn't thought of when they were written.

zdw 15y ago
Ditto on this. It's an abuse of the concept of inheritance, which teaches the wrong reasons to use the concept.
deleted 15y ago
[deleted]
nikcub 15y ago
I don't think I have ever read a programming book that teaches OO in the same way that most developers use it - that is implement top level first and then when you have commonalities between objects abstract them out into parent objects. Thinking about and mapping out class hierarchies is something that Java enterprise analysts do. A good example to teach OO would be a config parser. Write a config parsing object, then sub-class for parsing Yaml, INI, XML, etc.
johnkchow 15y ago
One of the very first things I learned almost immediately after college is that inheritance typically is a bad idea and that composition is a better strategy. With inheritance you have so much thinking overhead with parent to children relationships when most abstractions could easily be viewed as building it through small pieces. Its sad but during my 5 years in UCLA I have not heard the word "composition" once.

zdw 15y ago

The point is that OO isn't everything, and making the first thing people learn being class hierarchies colors their perceptions of programming in ways that sometimes are very damaging. For example, about 15 years ago I was an idiot and managed to get a job writing some text parsing code. I, of course, used what I just learned in my Comp Sci 101 "Intro to Programming" class and did a fully OO implementation in C++ with iostreams that took nearly a month to write, and never quite worked. Looking back, the solution was probably implementable in under 10 lines of a scripting language with judicious use of regex. The point is that people often fall for the first thing they're given, and OO (which incredibly useful when used properly) is an extremely enticing concept that can be very distracting from actually getting a job done.