Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update Machinery DSL, decoupling it from the Struct itself #10

Merged
merged 3 commits into from
Dec 17, 2017

Conversation

joaomdmoura
Copy link
Owner

Relate to issue #9

By forcing people to send the module where the machinery was imported, as an
argument of `transition_to/2`, we make sure we are enforcing an architecture
where the State Machine logic doesn't needs to be on the Struct module itself
(what in most Web framewokrs end up being the model).
This helps ppl to avoind having a bunch o logic in their models, an old issue
known as Fat Models, while also enbaling ppl to have multiple and reusable
State Machines for different Structs.
@joaomdmoura joaomdmoura self-assigned this Dec 17, 2017
@coveralls
Copy link

Coverage Status

Coverage remained the same at 100.0% when pulling 4769999 on decouple-struct into a34eb06 on master.

@coveralls
Copy link

Coverage Status

Coverage remained the same at 100.0% when pulling 4769999 on decouple-struct into a34eb06 on master.

@joaomdmoura joaomdmoura merged commit 3c51046 into master Dec 17, 2017
@joaomdmoura joaomdmoura deleted the decouple-struct branch December 17, 2017 05:22
@rawkode
Copy link

rawkode commented Jun 3, 2018

Hey,

It's a shame to see this reversal in API. I don't believe that one should decouple the model and business logic. What is a model, if not the business logic?

@joaomdmoura
Copy link
Owner Author

Hey @rawkode thanks for expressing your concerns. I do believe in decoupling business logic from models in some cases. In this case I do think it makes sense, also because it feels more functional.
The main reasons why I believe its worth to have your state machine logic into its own modules are:

  1. Avoid the usual anti-pattern known as fat model.
  2. Otherwise this logic wouldn't only live in the model but could easily leak to other modules as well.
  3. That also would allow you to have multiple state machines for the same model. (that's an edge case, I know and probably not okay for most cases)

@rawkode
Copy link

rawkode commented Jun 5, 2018

Avoid the usual anti-pattern known as fat model.

I don't believe this is considered an anti-pattern, but that's not important.

Otherwise this logic wouldn't only live in the model but could easily leak to other modules as well.

Can you elaborate on this?

When I define a module / model for a TrafficLight and store the state machine in it's own module, TrafficLightStateMachine, what would even exist inside the TrafficLight module? What is it's purpose?

I appreciate your library and only ask questions so that I can understand the direction your library is headed. I hope you do not mind these questions.

Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants