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 threadNoel Rappin

@davetron5000 We're assuming in the first version that the "some logic" is stateless or idempotent?

I find that more developers are likely to understand the stateful version, and while I may decry the lack of genuine OO design skills, that's still a factor.

I've basically written the stateful version a lot but I do like the stateless version where it's feasible.

Jun 11, 2024 at 4:29pmWeb
Show threadNoel RappinJun 11, 2024
@davetron5000 In most of these cases that I write, the object isn't reused, so calling it multiple times is rarely a problem in practice.
Show threadDave Copeland Jun 11, 2024
@noelrap yeah the core logic’s only “state” is to leave behind a structured explanation of what it did when called.
Show threadNoel RappinJun 11, 2024
@davetron5000 I think generically it's better for the class to return a value rather than own the value as state, but I've written the "own the value" enough times that I clearly don't think it's that much of a win in practice.
Show threadNoel RappinJun 11, 2024
@davetron5000 The second version is something that I sometimes call “syntactic" OO -- it's a very generic pattern that works in almost any domain, so if you are a consultant going from project to project, it's a very easy way to get a plausible system design quickly. (I guess that's true of both of these, but the custom result object makes me think there's more domain design going on in the first case)