Earlier quoted context omitted.
"what may be asserted without evidence, may be dismissed without evidence"
Where is your evidence for that claim? Seems like I should dismiss it out of hand.
QED.
Why general inheritance is flawed and how to finally fix it
61–70 of 104 posts
Re: Why general inheritance is flawed and how to finally fix it
#62Earlier quoted context omitted.
Spring does (and perhaps even prefers where possible) constructor-based inheritance though — which is as pluggable as it gets, making testing easy.
> Spring does (and perhaps even prefers where possible) constructor-based inheritance though OFC Spring does lots of things (too many things), but that varies project to project based on what series of Spring-related libraries are being used. More likely I'll see non Spring-core annotations like @RestController + @RequestMapping-attributes and have to figure a standard way to mock up some of what Spring does just to…
Testing REST-endpoints should be the job of integration tests, which are by definition more involved. Also, spring has really great test suits for these use cases.
Other classes/components should in the general case be written as POJOs. The dependent components can be mocked/injected simply by using the constructor.
Re: Why general inheritance is flawed and how to finally fix it
#63I think that composition is absolutely better than inheritance except for one thing: boilerplate. The issue is that boilerplate is kind of important. You don't want to litter your code with "f150.ford.car.vehicle.object.move(50, 50)". You can and should re-implement "move" so that you only have to call "f150.move(50, 50)", but that still requires boilerplate, just in the "F150" class. Often you have class containing…
Boilerplate is a solved[0] problem since a _very_ long time and is orthogonal to the inheritance vs composition problem.
Re: Why general inheritance is flawed and how to finally fix it
#64https://lwn.net/Articles/548560/ I really enjoyed the article above, which I read many years ago (before Rust 1.0!) which discusses how Golang and Rust handle polymorphism and code-reuse without classic object inheritance. My current thinking is that software objects are a general-purpose tool, but classic object inheritance should rarely be used as it is a solution to a narrow problem—classes should be "final" by de…
Arguably, subtyping in am OO language should either be signatures/interfaces only, or you should go full blown multiple inheritance for everything, as with the Fortress language.
Golang ide struggle with answering what implements this interface. The compiler obviously handles that fine
It makes it difficult to jump into an unfamiliar project
Assuming that’s what you mean by signature/ interfaces
Re: Why general inheritance is flawed and how to finally fix it
#65I think that composition is absolutely better than inheritance except for one thing: boilerplate. The issue is that boilerplate is kind of important. You don't want to litter your code with "f150.ford.car.vehicle.object.move(50, 50)". You can and should re-implement "move" so that you only have to call "f150.move(50, 50)", but that still requires boilerplate, just in the "F150" class. Often you have class containing…
COM solves this with delegation, where objects can only implement the methods that they care about and delegate everything else to the aggregated type, which provided the full interface. However, depending on which stack one is using (VB 6, .NET, MFC, ATL, WRL, WinRT), the amount of boilerplate to deal with the runtime differs.
I wish more languages (in fact, any popular languages!) had convenient syntax for this.
Re: Why general inheritance is flawed and how to finally fix it
#66Earlier quoted context omitted.
For the same reason, I'm not so absolutist about DRY. Having the most elegant codebase also often means the codebase that's hardest to work on, and it's often better to clean things up afterwards once you know how things will be structured.
This question determines if you need to be DRY or not: "If [some fact] in the code base needs to change, how many places would we have to change it in?" If the answer is > 1, you have a very good DRY case. Otherwise, when [some fact] changes, it will probably not be changed in one of the places, and the system will be broken. This often coincides with having an "elegant codebase", but that's not the most important pa…
A younger self used to be very strict about DRY.
For a living codebase, nowadays my general rule of thumb is to consciusly duplicate code until it covers 3 different cases, and only then refactor (unless the DRY way is as fast and obvious).
It takes more than that to yield spaghetti and a lot of time is saved on premature generalization. Plus the generalization is often way more straightforward once the explicit cases are already implemented.
Re: Why general inheritance is flawed and how to finally fix it
#67I think that composition is absolutely better than inheritance except for one thing: boilerplate. The issue is that boilerplate is kind of important. You don't want to litter your code with "f150.ford.car.vehicle.object.move(50, 50)". You can and should re-implement "move" so that you only have to call "f150.move(50, 50)", but that still requires boilerplate, just in the "F150" class. Often you have class containing…
In kotlin you can delegate the implementation of an interface to another object. Basically syntatic sugar for the delegation pattern.
https://kotlinlang.org/docs/delegation.html
With it, you F150 can say it implements the "movable" interface, just buy stating which field it contains that implements it, and the you can run "f150.move"
Re: Why general inheritance is flawed and how to finally fix it
#68Earlier quoted context omitted.
I mostly agree, but there's one place where it does make a lot of sense to keep the hierarchy open: exceptions. Ability raise a specific error and catch it in a generic handler is very useful.
Interfaces would work fine here as well.
As someone who is greatly in favor of composition over inheritance, I don't agree - or at least my experiences don't point that way.
Both Rust and Go have had medium sized warts and/or boilerplate around errors, especially if you need control flow to depend on the error. In Python I've never felt that way.
Not sure I can put my finger on it, because any trivial example would be fine in either paradigm. I think it has to do with the forced/unnatural upfront decision "is this error a type or an interface" that may change later on, as a type might need to be refactored to an interface. There's probably one or two other reasons I can't think of right now.
Re: Why general inheritance is flawed and how to finally fix it
#69Or you could learn to use it properly. Make no mistake, designing classes to support inheritance is much harder than just declaring everything final, and in many scenarios there is no good reason to do so
I _hate_ smart asses that do "everything final by default". It all fun and giggles until I can't mock some stupid class in some stupid library that I have no choice but to use just because someone is high on "inheritance is bad" hype. Instead of normal mocking/stubbing I now have to use stuff like PowerMock which does byte code hacking just so I can have a test.
How about you stop making decisions for me and let _me_ decide whether I want to inherit your class or not.
Re: Why general inheritance is flawed and how to finally fix it
#70Inheritance is flawed, in Java, mainly because it is the only organizing principle offered, so gets shoehorned into all kinds of problems where it is a poor fit. Inheritance is just the right thing once in a while, but Java coders are obliged to apply it well beyond its useful range.
What do you mean by "obliged to apply it"? For example, I very very rarely apply it and nobody is forcing me to create inheritance hierarchy.