Building maintainable Software-java article separate concerns in Modules
in a system, which is both complex and tightly coupled, accidents is inevitable.
-charles Perrow ' s Normal accidents
Theory in one sentence
guideline:? Avoid large modules in order to
achieve loose coupling between them.
? Do the
assigning responsibilities to separate modules and hiding implementation details behind interfaces
? This improves maintainability because changes in a loosely coupled codebase is much easier to oversee and execute than CH Anges in a tightly coupled codebase.
Remember the concept of a module translates to a class in object-oriented languages such as Java.
Motivation
The biggest advantage of keeping classes small is that it provides a direct path toward loose coupling between classes. Loose coupling means that your class-level design would be is much more flexible to facilitate the future changes. By "flexibility" we mean so you can do changes while limiting unexpected effects of those changes. Thus, loose coupling allows developers to work on isolated parts of the codebase without creating change ripples that Affe CT the rest of the codebase. A third advantage, which cannot be underestimated, was that the codebase as a whole would be much more open to less experien CED developers.
Small, loosely coupled Modules allow developers to work on Isolated Parts of the CodebaseWhen a class was tightly coupled with other classes, changes to the implementation of the class tend to create ripple effec TS through the codebase. For example, changing the interface of a public method leads to code changes everywhere the method is called. Besides the increased development effort, this also increases the risk that class modifications leads to bugs or inconsiste Ncies in remote parts of the codebase.
Small, loosely coupled Modules Ease Navigation Through the CodebaseDoes a good separation of concerns keep the codebase flexible to facilitate future changes, it also improves the Analyzability of the CODEBASE since classes encapsulate data and implement logic to perform a single task. Just as it is easier to name methods this only does one thing, classes also become easier to name and understand when they h Ave one responsibility. Making sure classes has only one responsibility are also known as the single
responsibility principle.
Small, loosely coupled Modules Prevent no-go areas for NEW developersClasses that violate the single responsibility principle become tightly coupled and accumulate a lot of code over time. As with the UserService example in the introduction of this chapter, these classes become intimidating to less experienced Developers, and
Even experienced developers is hesitant to make changes to their implementation. A codebase that have a large number of classes that lack a good separation of concerns are very difficult to adapt to new re Quirements.
How to Apply the guidelineGuideline prescribes
Keeping your classes small (by addressing only one concern) and
limiting The number of places where a class is called by code outside the class itself. Following is three development best practices, help to prevent tight coupling between classes in a codebase.
Split Classes to separate concernsDesigning classes that collectively implement functionality of a software system are the most essential step in modeling an D Designing object-oriented systems. In typical software projects we see this classes start out as logical entities that implement a single functionality but O Ver time gain more responsibilities. To prevent classes from getting a large class smell, it's crucial that developers take action
if a class have more tha n One responsibility by splittingup the class.
Hide Specialized implementations Behind InterfacesWe can also achieve loose coupling by
hiding specific and detailed implementations behind a high-level interface.
replace Custom Code with Third-party libraries/frameworks A third situation that typically leads to tight module coupling is classes that provide generic or utility functionality. Classic examples is classes called StringUtils and FileUtils. Since These classes provide generic functionality, they is obviously called
From many places in the codebase. In many cases a occurrence of tight coupling. A best practice, though, was to keep the class sizes limited and to periodically review (open source) libraries and Framewo Rks to check if they
Can replace the custom implementation. Apache Commons and Google Guava is widespread libraries with frequently used utility functionality. In some cases, utility code can is replaced with new Java language features or a company-wide shared
Library.
Reading notes:
Building maintainable Software:ten guidelines for Future-proof Code
by Joost Visser
Copyright? Software improvement Group, B.V. All rights reserved.
Printed in the states of America.
Published by O ' Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472.
O ' Reilly Books is purchased for educational, business, or sales promotional use. Online Editions is
Also available for most titles (http://safaribooksonline.com). For more information, contact our corporate/
Institutional sales department:800-998-9938 or [email protected]
Acquisitions Editor:rachel Roumeliotis
Editor:nan Barber
Production Editor:matthew Hacker
Copyeditor:rachel Monaghan
Proofreader:marta Justak
Indexer:wordco Indexing Services, Inc.
Interior Designer:david Futato
Cover Designer:randy Comer
Illustrator:rebecca Demarest
February 2016:first Edition
Revision history for the first Edition
2016-01-25:first Release
See Http://shop.oreilly.com/product/0636920049159.do
Building maintainable Software-java separate concerns in Modules
