4 ms·

I took over the maintenance and enhancement of a customer's eCommerce site. It's written in Python, using an ancient framework - Pylons. The person who origin

I took over the maintenance and enhancement of a customer's eCommerce site. It's written in Python, using an ancient framework - Pylons. The person who originally designed and wrote it, coded large super classes and then subclassed off those. And then somtimes subclassed off those subclasses. So now I'm lost in a maze of twisty classes/subclasses, which makes maintaining and enhancing this eCommerce site much, much more of a challenge than it should have been. In a few particular cases, I've found myself having to move functions out from one subclass and into the superclass, in order for related subclasses which needed access to it, for me to be able to add more functionality to the site. I think what I'm trying to say is - from my experience, you can use Inheritance in many, many ways which can make life very difficult - nay, miserable - for your future self and especially for anyone 'inheriting' your project. In my own home-grown Python projects, I have actually yet to use Inheritance (in classes I write myself - there's no escaping it when you're using other libraries of course), even after years of Python coding, because when I'm coding a new class DoSomething(), it's for that particular task and to date I've not ever had to subclass any of my classes.

weberc2 9y ago
I agree. I never find myself with a scenario in which inheritance is useful. I actually started writing a lot of Go (which has no inheritance support) and haven't missed inheritance at all. It really seems like useless complexity.
- lostcolony 9y ago
  I've found one or two cases where "inheritance would be nice". It wasn't necessary. I've found so many cases like the OPs where it made things harder, and the fix was basically pulling apart all shared functionality, where the only thing inherited were interfaces (if even that).
m3kw9 9y ago
And you are probably in the same situation when he was in when he realized it’s too much to re write and so he continued down the path. The next person will have the same issues as you until one of you can get Managment to let you rewrite it.
m3kw9 9y ago
Inheritance was probably was a good idea for a small thing and quickly achieve certain goals until features ballooned and he keep promising to deliver more features on top promptly
- FLUX-YOU 9y ago
  OO and inheritance can be brittle when you get new features that affect a wider amount of existing code. If you're only adding stuff on incrementally, you can conceivably add new classes for all of it and not worry about working with the existing code (usually you likely have some business classes that are basically starting primitives for new features, e.g. Customer). As it gets more brittle, it gets harder to add those spanning features, especially if it's not clear what features will be asked for.
- hinkley 9y ago
  There’s a rule from XP that people still ignore at their own peril. The rule of Three is, for those who tend to overengineer, a plea to wait a little longer. But for everyone else it’s a call to action. When you hit three copies of a pattern is when you should reconsider your choices. Just because a pattern was fine ten minutes ago doesn’t mean you should keep doing it now. At some point it has become “too much and as part of the campsite rule you have to ask if the block of code is ridiculous. It may have already been ridiculous, or you might be the one who took it there, but that doesn’t matter because you’re here now and what are you gonna do about it?
raymondh 9y ago
> In a few particular cases, I've found myself having > to move functions out from one subclass and into the > superclass, in order for related subclasses which > needed access to it, for me to be able to add more > functionality to the site. That seems like a refactoring basic. Far from being miserable, it is likely the easiest way to have met the requirement to add functionality.
- scarygliders 9y ago
  The misery comes from zero documentation, no code commenting, very short variable names, and having to trace backwards from the subclass to the superclass to the ancient frameworks and libraries being used. Especially tracing backwards from a subclass and it's undocumented! :)
PaulStatezny 9y ago
> you can use Inheritance in many, many ways which can make life very difficult - nay, miserable - for your future self and especially for anyone 'inheriting' your project. The principle of “Composition Over Inheritance” is really helpful. You should google it if you’re not familiar! It’s often a better alternative than deep inheritance hierarchies.

weberc2 9y ago

I agree. I never find myself with a scenario in which inheritance is useful. I actually started writing a lot of Go (which has no inheritance support) and haven't missed inheritance at all. It really seems like useless complexity.

lostcolony 9y ago
I've found one or two cases where "inheritance would be nice". It wasn't necessary. I've found so many cases like the OPs where it made things harder, and the fix was basically pulling apart all shared functionality, where the only thing inherited were interfaces (if even that).

m3kw9 9y ago

And you are probably in the same situation when he was in when he realized it’s too much to re write and so he continued down the path. The next person will have the same issues as you until one of you can get Managment to let you rewrite it.

m3kw9 9y ago

Inheritance was probably was a good idea for a small thing and quickly achieve certain goals until features ballooned and he keep promising to deliver more features on top promptly

FLUX-YOU 9y ago
OO and inheritance can be brittle when you get new features that affect a wider amount of existing code. If you're only adding stuff on incrementally, you can conceivably add new classes for all of it and not worry about working with the existing code (usually you likely have some business classes that are basically starting primitives for new features, e.g. Customer). As it gets more brittle, it gets harder to add those spanning features, especially if it's not clear what features will be asked for.
hinkley 9y ago
There’s a rule from XP that people still ignore at their own peril. The rule of Three is, for those who tend to overengineer, a plea to wait a little longer. But for everyone else it’s a call to action. When you hit three copies of a pattern is when you should reconsider your choices. Just because a pattern was fine ten minutes ago doesn’t mean you should keep doing it now. At some point it has become “too much and as part of the campsite rule you have to ask if the block of code is ridiculous. It may have already been ridiculous, or you might be the one who took it there, but that doesn’t matter because you’re here now and what are you gonna do about it?

raymondh 9y ago

> In a few particular cases, I've found myself having > to move functions out from one subclass and into the > superclass, in order for related subclasses which > needed access to it, for me to be able to add more > functionality to the site. That seems like a refactoring basic. Far from being miserable, it is likely the easiest way to have met the requirement to add functionality.

scarygliders 9y ago
The misery comes from zero documentation, no code commenting, very short variable names, and having to trace backwards from the subclass to the superclass to the ancient frameworks and libraries being used. Especially tracing backwards from a subclass and it's undocumented! :)

PaulStatezny 9y ago

> you can use Inheritance in many, many ways which can make life very difficult - nay, miserable - for your future self and especially for anyone 'inheriting' your project. The principle of “Composition Over Inheritance” is really helpful. You should google it if you’re not familiar! It’s often a better alternative than deep inheritance hierarchies.