The Decree Design Pattern
calebhearth.com
The Decree Design Pattern
1–10 of 17 posts
Re: The Decree Design Pattern
#2I'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.
Re: The Decree Design Pattern
#3So a Decree is… a function?
Re: The Decree Design Pattern
#4We 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.
Re: The Decree Design Pattern
#5We 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.
Sounds like you reinvented Django but in Ruby.
Feature-slicing (directory per feature) vs Component-slicing (models, views, controllers each have their own directory regardless of which feature they contribute to).
Re: The Decree Design Pattern
#6So a Decree is… a function?
Everything is a function if you untangle enough of it
Re: The Decree Design Pattern
#7That’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.
Re: The Decree Design Pattern
#8I 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?
Re: The Decree Design Pattern
#9The 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 ?