Building Maintainable Software-java篇之Couple Architecture Components Loosely

Building Maintainable Software-java篇之Couple Architecture Components Loosely

There are two ways of constructing a software design: one way is to make it so simple

that there are obviously no deficiencies, and the other way is to make it so complicated

that there are no obvious deficiencies.

                           —C.A.R. Hoare

Guideline:

• Achieve loose coupling between top-level components.

• Do this by minimizing the relative amount of code within modules that is exposed to (i.e., can receive calls from) mod‐

ules in other components.

• This improves maintainability because independent components ease isolated maintenance.

Motivation

Low Component Dependence Allows for Isolated Maintenance

A low level of dependence means that changes can be made in an isolated manner.

This applies when most of a component’s code volume is either internal or outgoing.

Isolated maintenance means less work, as coding changes do not have effects outside

the functionality that you are modifying.

Low Component Dependence Separates Maintenance Responsibilities

If all components are independent from each other, it is easier to distribute responsi‐

bilities for maintenance among separate teams. This follows from the advantage of

isolated modification. Isolation is in fact a prerequisite for efficient division of devel‐

opment work among team members or among different teams.

By contrast, if components are tightly intertwined with each other, one cannot isolate

and separate maintenance responsibilities among teams, since the effects of modifica‐

tions will spill over to other teams. Aside from that code being hard to test, the effects

of modifications may also be unpredictable. So, dependencies may lead to inconsis‐

tencies, more time spent on communication between developers, and time wasted

waiting for others to complete their modifications.

Low Component Dependence Eases Testing

Code that has a low dependence on other components (modules with mainly internal

and outgoing code) is easier to test. For internal calls, functionality can be traced and

tested within the component. For outgoing calls, you do not need to mock or stub

functionality that is provided by other components (given that functionality in that

other component is finished).

How to Apply the Guideline

The following principles help you apply the guideline of this chapter:

• Limit the size of modules that are the component’s interface.

• Define component interfaces on a high level of abstraction. This limits the types

of requests that cross component borders. That avoids requests that “know too

much” about the implementation details.

• Avoid throughput code, because it has the most serious effect on testing func‐

tionality. In other words, avoid interface modules that put through calls to other

components. If throughput code exists, analyze the concerned modules in order

to solve calls that are put through to other components

Abstract Factory Design Pattern

Component independence reflects the high-level architecture of a software system.

However, this is not a book on software architecture. In this section, we discuss only

one design pattern that we frequently see applied in practice to successfully limit the

amount of interface code exposed by a component: the Abstract Factory design pat‐

tern. A system that is loosely coupled is characterized by relying more on contracts

and less on implementation details.

Many more design patterns and software architecture styles can help in keeping your

architecture components loosely coupled. An example is using a framework for

dependency injection (which allows Inversion of Control). For elaboration on other

patterns, we kindly direct you to the many great books on design patterns and soft‐

ware architecture (see, for example, “Related Books” on page xiv).

The Abstract Factory design pattern hides (or encapsulates) the creation of specific

“products” behind a generic “product factory” interface. In this context, products are

typically entities for which more than one variant exists.

读书笔记：

Building Maintainable Software: Ten Guidelines for Future-Proof Code

by Joost Visser

Copyright © 2016 Software Improvement Group, B.V. All rights reserved.

Printed in the United States of America.

Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472.

O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are

also available for most titles (http://safaribooksonline.com). For more information, contact our corporate/

institutional sales department: 800-998-9938 or corporate@oreilly.com.

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