Dave Copeland Jun 11, 2024

Two OO ways to design something, curious what everyone's thoughts are? This is w/out context of a framework, just purely OO perspective.

Option 1 - Stateless object w/ Rich Result

Option 2 - Stateful object (e.g. command pattern + internal state to store results)

https://gist.github.com/davetron5000/19aa850df641be6c334e9b64a944b6c8

My thoughts follow, but I am not sure which is the "best" pattern - again all things being equal/not in Rails/etc.

stateful.rb

GitHub Gist: instantly share code, notes, and snippets.

Gist
Show threadPeter SolnicaJun 11, 2024
@davetron5000 stateless are...objectively better, lack of mutable state gives you simpler reusability and less code paths that can go wrong 🙂
Show threadDave Copeland Jun 11, 2024
@solnic You are not worried about coupling between "doit" objects and "result" objects? Or the extra effort needed to create structured result classes separate from the "doit" class?
Show threadPeter SolnicaJun 11, 2024
@davetron5000 oh and I don't create result classes, I just use plain data or stuff from dry-monads
Show threadDave Copeland Jun 11, 2024

@solnic How do you capture why an operation could not be completed in order to advise the user of the problem and how to fix it? I find "validations attached to a record" insufficient in a lot of cases.

For example, draft blog post -> validate title, publish blog post -> validate title + body & require approvals, e.g.

Show threadJan Dudulski
@davetron5000 @solnic just return Failure monad with all the details
Jun 18, 2024 at 11:05amWeb
Show threadDave Copeland Jun 18, 2024
@jandudulski @solnic the structure of the errors is use case specific however. So it cannot be generalized beyond “yes it’s an object with attributes” but Monad lays no claim to that.
Show threadJan DudulskiJun 18, 2024
@davetron5000 @solnic true, but it doesnt differ much from designing api of stateful approach - you still have to agree on a format, codes, messages, methods/field names etc