Functional decomposition in an OO world.
Some thoughts on functional decomposition in an OO world. I have LOTS of experience with this: https://sourcemaking.com/antipatterns/functional-decomposition
Another part of the solution to the "impedence mismatch" between functional and object decomposition. http://unity.codeplex.com/documentation
Also, a book review of Pro ASP.NET MVC 5 by Adam Freeman.
It's a good book and Adam is a good technical author. But, as the material above (on functional decomposition in an OO world) explains, his volume on MVC 5 is good - but not great. Maybe I'm just too demanding and some things are out of scope on the topic of MVC, but some things are not. Nor am I singling out Mr. Freeman. He really did a good job with this book. However...
This is another example where another author fails completely to properly abstract his classes and arrives at a FUNCTIONAL DECOMPOSITION where his classes end up with gerund names that describe actions such as "EmailSender" instead of an object name like "email" which would have a method/behavior named "send" or a "PasswordResetHelper" class/object instead of "password" with a "ResetHelper" method that describes a behavior of the "password" object. This lack of an object decomposition, resulting from the omission of an up-front Object Oriented Analysis is ignored in favor of "Test-Driven Development" which only affirms UNSTATED, undocumented, inferred requirements - showing that such functionality is indeed working - but which is void of context in terms of the business requirements, business and software objects, with properly-encapsulated attributes and behaviors.
This approach actually fails to capture the REQUIREMENTS of a system from which the system's objects and object attributes and behaviors may be indentified and instead relies on classes with gerund names which are more properly applied to methods/behaviors, thus confirming a functional decomposition that inevitably results in poor encapsulation (of objects with requisite attributes and behaviors) that can be applied to an object-oriented world of discrete objects that have state and can do things. So, although the functionality is implied and captured by these functionally-decomposed and named classes, the system requirements are only inferred by these function-named classes and only the functionality confirmed in the test project and nowhere in this process are actual system requirements and objects captured, defined and documented for the future. As the documentation to the Unity dependency injection package reminds us (linked above), this is an architectural level consideration that is only revealed through planning and a proper object decomposition.
This means that this author - along with the vast majority of others - still fails to truly grasp OBJECT-ORIENTATION which is about the OBJECTS of a system and how they interact. This approach continues to promote software development practices that fail to "line up" system requirements with system objects and a planned object-oriented architecture, even though the basic design pattern, MVC, provides a proper Object-Oriented architectural platform which was intended to set up the average programmer who is unfamiliar with OOA/OOD and who remains largely unaware of any planned architecture in terms of a system's objects - with a properly encapsulated architectural foundation. Of course, this foundation only goes so far towards creating a complete object-oriented architecture.
Since object-orientation IS a major topic in this book, I would expect to find proper OO practices from analysis through design, architecture and implementation and although UML IS beyond the scope of this book - in terms of teaching the reader how to do OO modeling - I would still recommend that the book be brought in line with OO standards, starting with the simplest which suggests that if your classes have names that are more descriptive of behaviors rather than being descriptive of objects, you are not properly identifying system objects, but are instead identifying system behaviors and you have arrived at a functional decomposition and architecture that is at cross-purposes with Object-Orientation and will therefore MISS the opportunities presented therewith. The addition of requirements captured in Use Case (and detailed flows), activity and class diagrams would go a long way toward the identification of actual system objects and would eliminate confusion about the design of the example project - which ends up being a hybrid object/functional architecture and design rather than as a straight OO architecture/design.
See pages 164-165 of Grady Booch's Object-Oriented Analysis and Design With Applications. Also see pg. 174 of "UML for the IT Business Analyst" by Howard Podeswa.