We're coming to a milestone in our current project at work, and it's had some real eye-openers. In one project, I've seen the effects that traditional, heavy-handed development can have and the freedom that can be bought through the exercise of best-practices.
Of all the areas that I've grown these past few months, the one I want to focus on tonight is my appreciation of Manager and Factory objects and lighter-weight entities. Coming into the project, I had an academic understanding of factories, and had used them in the past because they were part of the overall project architecture. However, on this project, we were teamed with several developers who preferred to code with heavy entities. Now, the project is coming to a close, and we have discovered the following:
1) Entities can get too big. When you have an entity that has all of it's properties and methods in one object, it tries to do too much. Changing any part of it has risk for every consumer of that entity, and the bigger the entity, the larger the risk (because the size is probably a reflection of the amount of use).
2) An entity's properties should be limited to the core properties that define what that entity is. Period. An automobile object should not have a property of "stereo". That's just clutter.
3) Property getters and setters should be very simple and basic. We have run into more than one case where the setter of a core property had too much purpose-specific logic in it that prevented the property from being used in any other purpose or context. Corrections were done, but in a fashion that is less readable and understandable than it should be (why does a manager class have to call a method called SetPropertyValue on the entity instead of the Property setter itself?). The technical debt keeps piling up.
4) Manager classes are not limited in the number of methods and the manner in which they operate on entities. Care should be taken to make sure that duplicate code is not written, but even if it is, the refactor is easy and the impact on other code is much lighter. If a Manager class starts to serve too many purposes, break off another one: PersonManager works great for basic Person functions, but you may need a CarpenterManager or DeveloperManager to operate on a person in a different capacity.
5) Factory classes are also flexible for returning the very "properties" that you've resisted putting on the entity. The AutomobileFactory can have a "GetCarStereo" method, but can also repurpose to have a "GetCDPlayer" method as well - both of which work with the same Automobile entity.
I know that a lot of this is really basic stuff, and most developers who've been coding TDD and Agile-design for some time are wondering why this should even be part of a post. Well, there's a difference between knowing something from a book or because you're told to do it, and learning it first-hand through experience. I am much better able to defend these ideas today than I was a couple of months ago, and am a better programmer for it.
Working through the basics as you learn to develop can be extremely beneficial. This is part of the growth process I spoke about in my first post- the difference between acting on faith and trust and actually owning what you're doing.
No comments:
Post a Comment