Groups of states #170
paulhennell
started this conversation in
Ideas
Replies: 1 comment
-
It seems like a good solution if it fits your needs. Personally I'd code something like this in the model class and I wouldn't mind having to manually make changes if my state classes change. But if this works better for you, I'd say it's fine. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Increasingly realising a lot of my projects would work far clearer with a state pattern, but hitting a repeated position where I want to filter on groups of states.
For an invoice style example you might want something like 'get all invoices that are payable' which might include DUE, OVERDUE and FAILED states. Obviously I can supply those to the whereState scope manually, but then adding a new invoice state (e.g. UPCOMING) means updating all queries to include the new class.
My first fix was just a quick array of classes available on the abstract state class - but that means the abstract state has to know what classes are payable, and it gives the abstract class a level of responsibility / knowledge of states.
My current system is instead to add a property to states like
public static bool $payable = true;
then add some helper functions to the abstract class:Then the scope can be filtered with
PaymentState::Payable()
which reads pretty nicely, and new states simply decide to override the payable property or not.I'm curious if this is
A) Missing a much simpler solution that I'll facepalm on when someone points it out (or I notice 3 mins after posting this ;))
B) An indication that
$payable
is it's own state or other kind of entityC) Something that others also see a need for that could be assisted with something like
getTrue
on the state model / a trait etcInterested to hear any thoughts!
Beta Was this translation helpful? Give feedback.
All reactions