4 ms·

>Or: OOP theory essentially says that classes should never be "subclassed." As in, the code isn't supposed to evolve that way; you're Doing It Wrong. Got a ref

>Or: OOP theory essentially says that classes should never be "subclassed." As in, the code isn't supposed to evolve that way; you're Doing It Wrong. Got a reference for that? I've heard "prefer composition over inheritance" (GoF) but never have I heard that classes should never be subclassed.

avinium 8y ago
The cleanliness and "refactorability" of my code improved significantly when I drastically reduced the amount of subclassing I was doing. I wouldn't go so far to say "never subclass", but I'd say most of the time, you won't need to subclass.
- hackits 8y ago
  I would say you `never never subclass` most of the time its just proves your design is turning into a taxonomy. You really don't need classes for a OOP language, its just simply a convention that developers use that is convenient.
- rhapsodic 8y ago
  >The cleanliness and "refactorability" of my code improved significantly when I drastically reduced the amount of subclassing I was doing. >I wouldn't go so far to say "never subclass", but I'd say most of the time, you won't need to subclass. Yeah, I would agree with that. A lot of OOP mechanisms like inheritance, or design patterns, get overused a lot. I'm not saying it's what you were doing, but I've seen it mostly in code written by newish programmers. It seems that once the concepts of OOP click in their mind, they get excited and eager to put them to work, so they use them where they're not really appropriate. I was definitely guilty of that, way back in the day. But once the novelty wore off, and I realized that I was just creating over-architected messes, I quit doing it.
  - avinium 8y ago
    Learning Clojure was, IMO, the best thing I could have done to improve my development skills. It helps you realize that programming is simply about data, and how you manipulate it. Design patterns, OOP, conventions, etc are all just secondary tools that sometimes help you do that.
Nition 8y ago
They're not saying never create subclasses, so much as never start with a base class and then create subclasses from it. The idea presented is that you should instead be starting with the specific classes you need, and if they have common operations, possibly creating a base class out of those.
- rhapsodic 8y ago
  >They're not saying never create subclasses, so much as never start with a base class and then create subclasses from it. Well, whatever they said, they started off with "OOP theory essentially says that..." So, if it's OO theory, I'd appreciate if someone could provide me a reference that shows that it's OO theory, and not just someone's personal opinion.

avinium 8y ago

The cleanliness and "refactorability" of my code improved significantly when I drastically reduced the amount of subclassing I was doing. I wouldn't go so far to say "never subclass", but I'd say most of the time, you won't need to subclass.

hackits 8y ago
I would say you `never never subclass` most of the time its just proves your design is turning into a taxonomy. You really don't need classes for a OOP language, its just simply a convention that developers use that is convenient.
rhapsodic 8y ago
>The cleanliness and "refactorability" of my code improved significantly when I drastically reduced the amount of subclassing I was doing. >I wouldn't go so far to say "never subclass", but I'd say most of the time, you won't need to subclass. Yeah, I would agree with that. A lot of OOP mechanisms like inheritance, or design patterns, get overused a lot. I'm not saying it's what you were doing, but I've seen it mostly in code written by newish programmers. It seems that once the concepts of OOP click in their mind, they get excited and eager to put them to work, so they use them where they're not really appropriate. I was definitely guilty of that, way back in the day. But once the novelty wore off, and I realized that I was just creating over-architected messes, I quit doing it.
- avinium 8y ago
  Learning Clojure was, IMO, the best thing I could have done to improve my development skills. It helps you realize that programming is simply about data, and how you manipulate it. Design patterns, OOP, conventions, etc are all just secondary tools that sometimes help you do that.

Nition 8y ago

They're not saying never create subclasses, so much as never start with a base class and then create subclasses from it. The idea presented is that you should instead be starting with the specific classes you need, and if they have common operations, possibly creating a base class out of those.

rhapsodic 8y ago
>They're not saying never create subclasses, so much as never start with a base class and then create subclasses from it. Well, whatever they said, they started off with "OOP theory essentially says that..." So, if it's OO theory, I'd appreciate if someone could provide me a reference that shows that it's OO theory, and not just someone's personal opinion.