{"action":"created","issue":{"url":"https://api.github.com/repos/doridori/Dynamo/issues/11","labels_url":"https://api.github.com/repos/doridori/Dynamo/issues/11/labels{/name}","comments_url":"https://api.github.com/repos/doridori/Dynamo/issues/11/comments","events_url":"https://api.github.com/repos/doridori/Dynamo/issues/11/events","html_url":"https://github.com/doridori/Dynamo/issues/11","id":94928419,"number":11,"title":"Some thouhts/questions on Dynamo","user":{"login":"kmdupr33","id":5463526,"avatar_url":"https://avatars.githubusercontent.com/u/5463526?v=3","gravatar_id":"","url":"https://api.github.com/users/kmdupr33","html_url":"https://github.com/kmdupr33","followers_url":"https://api.github.com/users/kmdupr33/followers","following_url":"https://api.github.com/users/kmdupr33/following{/other_user}","gists_url":"https://api.github.com/users/kmdupr33/gists{/gist_id}","starred_url":"https://api.github.com/users/kmdupr33/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/kmdupr33/subscriptions","organizations_url":"https://api.github.com/users/kmdupr33/orgs","repos_url":"https://api.github.com/users/kmdupr33/repos","events_url":"https://api.github.com/users/kmdupr33/events{/privacy}","received_events_url":"https://api.github.com/users/kmdupr33/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/doridori/Dynamo/labels/question","name":"question","color":"cc317c"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":3,"created_at":"2015-07-14T11:47:54Z","updated_at":"2015-07-16T11:45:06Z","closed_at":null,"body":"First off, the wiki (first 5 pages) and blog posts were fantastic reads. Definitely the best I've read on this subject. I will definitely be returning to this material to think more about what you're proposed. \r\n\r\nAfter reading, I had a few questions:\r\n\r\nOn [page 5](https://github.com/doridori/Dynamo/wiki/5.-An-Implementation), you say that:\r\n\r\n>Its important that each state should be able to expose its own interface, for example ComputationFinishedState has a getResult() method. This is why we have used the Visitor pattern as it allows us to do this easily.\r\n\r\n1. I had a little trouble seeing how the Visitor pattern makes it easier for each State to expose its own interface. Why can't a simple callback do this as well as a visitor?\r\n\r\n2. I want to make sure I've understood how the objects in this architecture \"hang together,\" so I want to try to apply your approach to a scenario that didn't seem to be explicitly covered in your wiki. Suppose you want to do something when an `Activity`'s `onStop()` method is called. Suppose further that the code you want to execute has a lot of business logic in it. On your approach, that business logic wouldn't live in the `Activity`. Instead, you'd call a method on a dynamo which would then call a method on a `State` and the `State` would handle the business logic. Does that sound like the dynamo-way of handling that scenario?"},"comment":{"url":"https://api.github.com/repos/doridori/Dynamo/issues/comments/121933158","html_url":"https://github.com/doridori/Dynamo/issues/11#issuecomment-121933158","issue_url":"https://api.github.com/repos/doridori/Dynamo/issues/11","id":121933158,"user":{"login":"kmdupr33","id":5463526,"avatar_url":"https://avatars.githubusercontent.com/u/5463526?v=3","gravatar_id":"","url":"https://api.github.com/users/kmdupr33","html_url":"https://github.com/kmdupr33","followers_url":"https://api.github.com/users/kmdupr33/followers","following_url":"https://api.github.com/users/kmdupr33/following{/other_user}","gists_url":"https://api.github.com/users/kmdupr33/gists{/gist_id}","starred_url":"https://api.github.com/users/kmdupr33/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/kmdupr33/subscriptions","organizations_url":"https://api.github.com/users/kmdupr33/orgs","repos_url":"https://api.github.com/users/kmdupr33/repos","events_url":"https://api.github.com/users/kmdupr33/events{/privacy}","received_events_url":"https://api.github.com/users/kmdupr33/received_events","type":"User","site_admin":false},"created_at":"2015-07-16T11:45:06Z","updated_at":"2015-07-16T11:45:06Z","body":"This is really interesting! So, it looks like you're actually leveraging the visitor and the state design patterns to facilitate communication between the View and the Dynamo. That's brilliant!\r\n\r\n2 concerns:\r\n\r\n1. If a \"State\" has a restart method on it and other methods with real \"behavior,\" then I'm not sure the name \"State\" is really the best name for the objects that we're passing between the View and the Dynamo. I would expect a State object to be a value object with no real behavior, but maybe that's a silly expectation. Alternatively, we might keep the name \"State\" and stick to passing value objects between Views and Dynamos and move some of the methods with actual behavior to live in another object. \r\n\r\n2. Because we can't leverage constructor (dependency) injection in Activities and Fragments, its more difficult to unit test them. I'm interested in architectures that move all business logic out of Activities/Fragments. Do you think this architecture would clash at all with my desire to push all business logic out of Activities and Fragments and into Dynamos and/or States and/or some other object?"}}