I wouldn’t say that inheritance is for avoiding code duplication. It should be used to express “is a” relationship. An example seen in one of my projects: a mixin with error-handling code for a REST service client used for more than one service has log messages tightly coupled to a particular service. That’s exactly because someone thought it was ok to reuse.
In my opinion, inheritance makes sense when you can follow Liskov’s principle. Otherwise you should be careful.
You’re not wrong but I think when you’re teaching someone just having 1 parent and 1 child class makes for a bad example I generally prefer to use something with a lot of different children.
My go-to is exporters. We have the exporter interface, the generic exporter, the accounting exporter and the payroll exporter, to explain it.
At school, the only time I used inheritance was 1 parent (booking) and 1 child (luxury) this is a terrible example imo.
Maybe that example was made terrible because the author couldn’t think of a good ways to show how great this can be. I’m obviously a fan of SOLID, and OCP is exactly why I don’t worry if I have only one class at the beginning. Because I know eventually requirements would change and I’d end up with more classes.
Some time ago I was asked by a less experienced coworker during a code review why I wrote a particularly complex piece of code instead just having a bunch of if statements. Eventually this piece got extended to do several other things, but because it was structured well, extending it was easy with minimum impact for the code-base. This is why design matters.
Above claims are based on nearly 2 decades of writing software, 3/4 of it in big companies with very complex requirements.
I wouldn’t say that inheritance is for avoiding code duplication. It should be used to express “is a” relationship. An example seen in one of my projects: a mixin with error-handling code for a REST service client used for more than one service has log messages tightly coupled to a particular service. That’s exactly because someone thought it was ok to reuse.
In my opinion, inheritance makes sense when you can follow Liskov’s principle. Otherwise you should be careful.
You’re not wrong but I think when you’re teaching someone just having 1 parent and 1 child class makes for a bad example I generally prefer to use something with a lot of different children.
My go-to is exporters. We have the exporter interface, the generic exporter, the accounting exporter and the payroll exporter, to explain it.
At school, the only time I used inheritance was 1 parent (booking) and 1 child (luxury) this is a terrible example imo.
Maybe that example was made terrible because the author couldn’t think of a good ways to show how great this can be. I’m obviously a fan of SOLID, and OCP is exactly why I don’t worry if I have only one class at the beginning. Because I know eventually requirements would change and I’d end up with more classes.
Some time ago I was asked by a less experienced coworker during a code review why I wrote a particularly complex piece of code instead just having a bunch of if statements. Eventually this piece got extended to do several other things, but because it was structured well, extending it was easy with minimum impact for the code-base. This is why design matters.
Above claims are based on nearly 2 decades of writing software, 3/4 of it in big companies with very complex requirements.