from Hacker News

The Decree Design Pattern

by caleb_thompson on 2/3/23, 4:36 PM with 16 comments

• by caleb_thompson on 2/3/23, 4:36 PM

  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.

  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.

• by nesarkvechnep on 2/5/23, 6:12 AM

  So a Decree is… a function?

• by arcbyte on 2/5/23, 3:15 PM

  This seems similar to an itch I've had for a while on many languages.

  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.

  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.

  It would be really nice to have some syntactic sugar for extracting a class for function calls and their arguments.

  The decree pattern seems similar the solution I've described above but avoided implementing because it sounds crazy.

• by jweir on 2/5/23, 6:14 AM

  We use a similar pattern and have a strict namespace.

  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.

  We broke from the standard Rails directory structure. All the code for Player would be in one directory - including views.

• by pydry on 2/5/23, 11:01 AM

  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.

  In the ProcessPayment example he says the pattern is good because it lets you split the construction of the payment from its execution.

  Soooo why not have a Payment class with a process method? Am I missing something?

• by ChrisMarshallNY on 2/5/23, 10:44 AM

  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).

  I used it to leverage OOP from non-OOP languages (like C).

  An SDK that I wrote in 1994, using it, was still in use, when I left the company, in 2017.

• by revskill on 2/5/23, 11:32 AM

  The most confusing things about OOP is inheritance vs subtyping vs union.

  You have a dequeue class, the stack and queue inherit dequeue. But dequeue is a subtype of stack and queue.

  About union, could i say an abstract class is a union (implicitly) of all its subclasses ?