Building Maintainable Software-java篇之Keep Unit Interfaces Small

 Building Maintainable Software-java篇之Keep Unit Interfaces Small

Bunches of data that hang around together really ought to be made into their own object.
                           —Martin Fowler

Guideline:

• Limit the number of parameters per unit to at most 4.
• Do this by extracting parameters into objects.
• This improves maintainability because keeping the number of parameters lowmakes units easier to understand and reuse.


There are many situations in the daily life of a programmer where long parameter lists seem unavoidable. In the rush of getting things done, you might add a few parameters more to that one method in order to make it work for exceptional cases. In the long term, however, such a way of working will lead to methods that are hard to maintain and hard to reuse. To keep your code maintainable it is essential to avoid long parameter lists, or unit interfaces, by limiting the number of parameters they have.

Motivation

As we already discussed in the introduction, there are good reasons to keep interfaces small and to introduce suitable objects for the parameters you keep passing around in conjunction. Methods with small interfaces keep their context simple and thus are easier to understand. Furthermore, they are easier to reuse and modify because they do not depend on too much external input.

Small Interfaces Are Easier to Understand and Reuse

As the codebase grows, the core classes become the API upon which a lot of other code in the system builds. In order to keep the volume of the total codebase low (see also Chapter 9) and the speed of development high, it is important that the methods in the core classes have a clear and small interface. Suppose you want to store a ProductOrder object in the database: would you prefer a ProductOrderDao.store(ProductOrder order) method or a ProductOrderDao.store(ProductOrder order,String databaseUser, String databaseName, boolean validateBeforeStore, boolean closeDbConnection) method?

Methods with Small Interfaces Are Easier to Modify

Large interfaces do not only make your methods obscure, but in many cases also
indicate multiple responsibilities (especially when you feel that you really cannot group your objects together anymore). In this sense, interface size correlates with unit size and unit complexity. So it is pretty obvious that methods with large interfaces are hard to modify. If you have, say, a method with eight parameters and a lot is going on in the method body, it can be difficult to see where you can split your method into distinct parts. However, once you have done so, you will have several methods with
their own responsibility, and moreover, each method will have a small number of parameters! Now it will be much easier to modify each of these methods, because you can more easily locate exactly where your modification needs to be done.

How to Apply the Guideline

By the time you have read this, you should be convinced that having small interfaces is a good idea. How small should an interface be? In practice,an upper bound of four seems reasonable: a method with four parameters is still reasonably clear, but a method with five parameters is already getting difficult to read and has too many responsibilities.

So how can you ensure small interfaces? Before we show you how you can fix methods with large interfaces, keep in mind that large interfaces are not the problem, but rather are indicators of the actual problem—

a poor data model or ad hoc code modification. So, you can view interface size as a code smell, to see whether your data model needs improvement.

Large interfaces are usually not the main problem; rather, they are a code smell that indicates a deeper maintainability problem.


The examples presented in this chapter all group parameters into objects. Such objects are often calleddata transfer objects(DTO) or parameter objects.


Another way to solve this is to use the Replace Method with Method Object refactoring technique presented in Chapter 2. This refactoring technique is primarily used to make methods shorter, but it can also be used to reduce the number of method

parameters.

读书笔记：

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 [e-mail].
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