Hacker News new | ask | show | jobs
by Draiken 820 days ago
> If you prefer inheritance over composition

That's not what this boils down to.

These are procedures. OOP is generally about objects sending messages to each other. So this solution is all about executing procedural calls, which has nothing to do with inheritance/composition.

You can very easily have OO code with composition without having to rely on everything having one single interface "call/run/execute".

1 comments

Perhaps I phrased this badly. I don't think the entire article boils down to inheritance vs composition. But in discussing these patterns elsewhere, some of the pushback has been that many Ruby devs prefer to decompose problems via sub-classing instead of composition of command objects, so I tried to cater to that objection with that line.

Pipeline steps are command objects (a pretty standard OO pattern), so they have a single entry point / public method. But they can still fully leverage any other OO pattern in their implementation. The more complex ones I use may instantiate other objects, pass messages between them, etc.

But the single-method #call API is what makes composition easy. See Rack, or any number of middleware-style designs, for other common uses of this in Ruby.

Yeah, my main gripe is with the phrasing. It gives the impression that if you like composition over inheritance (which people mostly take as true without even thinking about it), you should use this.

I feel like that's the kind of over-simplification that then makes people pick a style like this without fully considering the implications.

Every single place that I've seen use these "command pattern" systems devolved into a complete utter mess of procedures. People forget the basics of OO and write everything into "steps" because that's now the hammer and everything is a nail.

If they stuck to the outer layers as the orchestrator for everything, that'd be great. But that never happens in my experience.

Good observations, thank you. I take the point about properly delimiting the boundaries of the orchestration layer in a system.

I think you're right about how that line comes across, I'll try and improve it.