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 threadJamie LawrenceJun 11, 2024

@davetron5000 stateless is nice and clean but inevitably requirements evolve and it no longer need to do “just one thing” or doing the one thing involves a series of internal methods and having internal state would clean up their parameters.

I think “best” probably changes over time (usually evolving from stateless to stateful)

Show threadPeter SolnicaJun 11, 2024
@jamie @davetron5000 when complexity grows, you extract things into new objects and use them as collaborators; internal state doesn't clean up anything, it just makes things hidden and less obvious, it's the OO lie so many people are used to
Show threadEmma (has_many_books of old)
@solnic @jamie @davetron5000 but you can also end up with a hundred tiny, neat -- and completely unnavigable classes. so there be dragons on that approach too
Jun 11, 2024 at 2:05pmWeb
Show threadPeter SolnicaJun 11, 2024
@emma @jamie @davetron5000 not in my experience, functionality shouldn't be split in a too granular way, you extract things only when something is hard to understand. Lack of state make things easier to extract into smaller pieces too. It's also easier to reorganize and move things around when you don't have state hidden in a bunch of objects.
Show threadEmma (has_many_books of old)Jun 11, 2024
@solnic @jamie @davetron5000 but you know that my experience has been otherwise, cos I just said so. so it's something that can happen if someone's sense of whether something is hard to understand and therefore extractable differs from someone else's.
Show threadPeter SolnicaJun 11, 2024
@emma @jamie @davetron5000 premature extraction and/or too granular extraction is a problem of its own though. It's not like stateful objects will shield you from it :) I'd even say they make things worse as what may happen is that lots of objects will be coupled to a lot of state without a good reason
Show threadEmma (has_many_books of old)Jun 11, 2024
@solnic @jamie @davetron5000 "let's not prematurely abstract" is my mantra at work!