This post originated from an RSS feed registered with Agile Buzz
by Keith Ray.
Original Post: Application Layering
Feed Title: MemoRanda
Feed URL: http://homepage.mac.com/1/homepage404ErrorPage.html
Feed Description: Keith Ray's notes to be remembered on agile software development, project management, oo programming, and other topics.
In large applications, just to be able find classes and functions, and to be able to comprehend the structure "in the large" (to see the forest and the trees), you want "layers". Or "modules". Or "packages". Some division of responsibilities larger than the individual classes. In the image below, I show a hypothetical ideal application with eight modules or layers, compared to a near-worst-case legacy application.
The order of the layers/modules in this diagram is arbitrary and not meant to imply the amount of connections between layers, nor the directions of those connection. (But keeping the connections between modules going one-way, even if that requires adding additional "interface" modules, is a Good Thing.)
When you are doing iterative/incremental development, as recommended by all agile methods, how do you keep to the ideal layering and avoid that legacy code scattering of responsibilities? By paying careful attention to the Single-Responsibility Principle and other principles of good design, and by cleaning up any the code smells that you notice which indicate violations of SRP and other good design principles. Decide on which layer a class belongs to, each time you create a class. (Create new layers as needed.) Each feature that you implement will likely involve several layers, so pay attention to where those layers are.
If you don't pay attention during agile development, your application structure could look like a Tetris game gone badly. Refactor every day to keep the structure clean and well-organized.
Previous Topic
