3 ms·

> No inheritence. Yup. Prefer composition over inheritance. Such a hard sell during the heyday of OOAD. UML, Fusion, RUP, blahblahblah. Having previous exper

> No inheritence. Yup. Prefer composition over inheritance. Such a hard sell during the heyday of OOAD. UML, Fusion, RUP, blahblahblah. Having previous experience with LISP, it just seemed obvious, barely worth mentioning. Definitely set me apart from my colleagues. FWIW: Our local design pattern study group tackled Arthur J. Riel's Object-Oriented Design Heuristics [1996] https://archive.org/details/objectorientedde0000riel https://archive.org/details/objectorientedde0000riel https://www.amazon.com/Object-Oriented-Design-Heuristics-Arthur-Riel/dp/020163385X https://www.amazon.com/Object-Oriented-Design-Heuristics-Art... Which might be the earliest published pushback against all that overwrought enterprisey ThoughtWorks-style brainrot. > No ... dependency injection Yes and: Mocks (mocking?) is a code stench. Just flip the ownership relationship(s). As Riel, and surely many others, have laboriously explained, to a mostly uncaring world.

kazinator 1y ago
Prefer inheritance if the first thing you're gonna have to do under composition is to crank out a bunch of delegate methods from the parent object to the contained child, to make the parent substitutable for the child, and the child won't be replaced at run time.
- specialist 1y ago
  Probably. I personally haven't done anything like that. Though I'm not sure I follow. I've mostly done ASTs and (scene) graphs. I prefer dumb objects, stuffing most behavior and logic in an Interpreter (design pattern) implementation. Being a very simple bear, my working memory can't keep track of all the smarts scattered all about. My current example is processing SQL statements; think expression evaluator (subset) for a very specific use case. I tend to use so called "External" Iterators for walking trees, to keeping all the logic in one place. Versus Visitor, Listeners, or even Active Objects. Which is feasible for this use case, because its bounded and unlikely to change (eg extension points). YMMV of course. Now I'm just babbling, apologies, and probably went too far off topic.

kazinator 1y ago

Prefer inheritance if the first thing you're gonna have to do under composition is to crank out a bunch of delegate methods from the parent object to the contained child, to make the parent substitutable for the child, and the child won't be replaced at run time.

specialist 1y ago
Probably. I personally haven't done anything like that. Though I'm not sure I follow. I've mostly done ASTs and (scene) graphs. I prefer dumb objects, stuffing most behavior and logic in an Interpreter (design pattern) implementation. Being a very simple bear, my working memory can't keep track of all the smarts scattered all about. My current example is processing SQL statements; think expression evaluator (subset) for a very specific use case. I tend to use so called "External" Iterators for walking trees, to keeping all the logic in one place. Versus Visitor, Listeners, or even Active Objects. Which is feasible for this use case, because its bounded and unlikely to change (eg extension points). YMMV of course. Now I'm just babbling, apologies, and probably went too far off topic.