I've started working on an application to allow people to manage their Facebook groups from outside of Facebook, as a hobby project to keep my skills fresh while I am between roles.
This morning as I was writing some tests and expanding the application to the point where it would be ready to start interacting with Facebook, I found myself feeling uneasy about the structure of a Service.
The method needed to know about a few fields that I have already encapsulated elsewhere. I found myself wondering, do I pass in the entire object or should the object actually be responsible for calling the method and passing its member fields as parameters?
After a few minutes of umming and aahing, the penny dropped and I renamed my "Service" class to be a Gateway. The way that the call gets processed should have made it stick out like a flashing neon sign that this is a gateway.
Having an organisation object make calls on the gateway, rather than being passed as a parameter into the gateway seems cleaner, but I expect another aspect of the domain that I have yet to uncover will move the responsibility out of the organisation object. Of course day 1 of the project is probably a bit early on to get concerned about this sort of detail.
This is yet another reason why Martin Fowler's Patterns of Enterprise Application Architecture lives on my table, rather than my bookshelf.
No comments:
Post a Comment