4 ms·
> In good OO programming, we don’t make class hierarchies in order to satisfy our inner Linnaeus I wish someone had told me this when I first started coding. I
by alangibson 4y ago
> In good OO programming, we don’t make class hierarchies in order to satisfy our inner Linnaeus
I wish someone had told me this when I first started coding. I wasted so much time building pointless hierarchies based on ontology rather than DRY.
- bborud 4y agoDRY is also not the goal.
- rkangel 4y agoIt's not a million miles from it though. If you start from DRY as an approach to OO design you'll produce something vaguely reasonable and be close enough to where you want to be that you can learn the differences.
- bborud 4y agoI should have been a bit more precise. There are essentialy two ways to approach DRY in OO. One is to inherit implementation, which isn't the best way to go about things since it leads to more brittle code. The other way is to make sensible use of polymorphism and composition. There are aspects of DRY that are worth pursuing (like reducing the number of places you need to get things right) and some that aren't worth pursuing (thinking you reduce the amount of work by re-using code heavily). For code to be reusable you have to be sure that developers only have to care about its interface. Implementation inheritance often doesn't do that. I've worked on projects with people who were obsessed with DRY and made heavy use of implementation inheritance, and the projects inevitably needed extra work to untangle a brittle mess with lots of surprising behaviors.
- rkangel 4y agoYes, to be fair the simplest advice to new programmers about how to use inheritance should be "don't". Aggregation good, polymorphism good, inheritance bad more often than not.
- a4isms 4y agoThe thing about the natural world is that “Nature does not practice OOP.” Our nice hierarchies of animals reflect our desire to build hierarchies. Those hierarchies are tools that are useful for many purposes, but they weren’t blueprints for constructing life. I speculate that if we think of our hierarchies as tools, they say at least as much about our own brains and the problems we’re trying to solve as the do about the domain. Which is fine, tools exist as levers for the mind. But we shouldn’t confuse them with reality. The map is not the terrain.
- jhbadger 4y agoI disagree. Nature does practice OOP and taxonomic hierarchies are real things in nature if they are based on their evolutionary history. People say penguins are "flightless birds", but look how they swim. They don't swim like fishes. They basically are flying in water because they share the same genetic programming as other birds, just slightly modified to use a different medium. Nature doesn't re-implement things from scratch but is great at code reuse.
- igouy 4y agoNature doesn't do design, period.
- jhbadger 4y agoTrue but irrelevant. The fact is nature "subclasses" (in the OOP sense) animals all the time in evolution even if it is an unintelligent process ultimately due to chance modification.
- Jcowell 4y agoI think I understand what your saying. In this context a penguin is implementing a quality it’s inherited from the gene it has as a bird. A Penguin may not be a bird in the same way we may thing a fly method should work , but it’s fly method derived from the fact that it’s genetically a bird.
- 4y ago
- legulere 4y agoDRY comes from a time where you had people not using abstractions at all. I have seen code from the 80s where code for printing forms were one function each writing directly what gets sent to the printer for each form with no abstraction at all. DRY was meant for people that wrote that kind of code. If all you have ever come into contact with is normal modern code, than DRY goes overboard: you start to abstract too much and make the code harder to read and maintain. The real art is maintaining the balance between abstraction and pragmatic simple code.