I've been using this pattern of naming and structuring service objects over the past ~year. It's initially been greeted with some uncertainty and skepticism when I introduce it to new developers, but it tends to grow on folks as they give it a shot and look at how it's already been used.<p>I wrote this up partially to codify some of how I've been explaining it to folks ad-hoc, but also to share with the broader community and get input on this way of extracting processes in Ruby/Rails projects.
This seems similar to an itch I've had for a while on many languages.<p>I have quite often wanted the ability to easily collect the arguments to a function call together in a structure with the function itself, and defer the execution of the method. I want a closure essentially but with the ability to reflect and inspect the arguments and function, potentially make changes, and execute it later.<p>Of course the only real way to do this in most languages is to make every single thing i want to do a single-function class with public "argument" members. But that messes with the structure of the code.<p>It would be really nice to have some syntactic sugar for extracting a class for function calls and their arguments.<p>The decree pattern seems similar the solution I've described above but avoided implementing because it sounds crazy.
We use a similar pattern and have a strict namespace.<p>Player would be a namespace. It would be a module with no or limited code. Within it would be Controller, Model or the agent noun modules that take call: Creator, Inporter, Mailer - the “er” words indicate there will be a single call function.<p>We broke from the standard Rails directory structure. All the code for Player would be in one directory - including views.
I thought this was a sarcastic description of an antipattern to start with. Whenever I see classes with verbs in their name I see it as a bad smell.<p>In the ProcessPayment example he says the pattern is good because it lets you split the construction of the payment from its execution.<p>Soooo why not have a Payment class with a process method? Am I missing something?
That’s a design pattern I used in the early ‘90s. I called it “False Objects” (I think that I even wrote up a pattern doc on it). I got the idea from QuickDraw GX (about the only good I got from that tech).<p>I used it to leverage OOP from non-OOP languages (like C).<p>An SDK that I wrote in 1994, using it, was still in use, when I left the company, in 2017.
The most confusing things about OOP is inheritance vs subtyping vs union.<p>You have a dequeue class, the stack and queue inherit dequeue. But dequeue is a subtype of stack and queue.<p>About union, could i say an abstract class is a union (implicitly) of all its subclasses ?