Kent Beck的《实现模式》——编程领域的智慧结晶

需积分: 9 31 浏览量更新于2024-07-29 1 收藏 998KB PDF 举报

"Implementation Patterns" 是一本由 Kent Beck 所著的专业书籍，主要探讨的是软件设计中的实现模式。这本书由 Addison-Wesley Professional 出版，第一版发行于2007年11月2日，语言为英文。书中的 ISBN-10 为 0321413091，ISBN-13 为 978-0321413093，尺寸为9.1x6.9x0.6英寸。这本书的作者 Kent Beck 是一位在创建清晰、易理解且具有可读性代码方面的大师。书中深入浅出地探讨了我们在构建高质量代码和类时，持续需要做出的那些小但至关重要的决策。Erich Gamma，IBM 的杰出工程师，对本书给予了高度评价，认为每一章都包含对这些细微但关键决策的精彩解释和见解。书中内容旨在帮助读者成为团队中的主导开发者，具备快速做出明智决策的能力，写出易于理解、修改的代码，并且让团队成员在使用时感到安全舒适。如 Russ Rufer，硅谷模式小组成员所述，无论资深程序员还是新手开发者，都能从本书中受益。资深开发者可以学习到新的技巧并改进旧的习惯，而新手开发者则能通过书中的清晰讲解，更好地入门编程世界。 "Implementation Patterns" 这本书涵盖的主题广泛，不仅包括了软件设计的基础原则，还深入到具体的技术细节。它讨论了如何通过模式来提高代码的组织结构，减少复杂性，以及如何利用良好的实现模式来增强代码的可维护性和可扩展性。书中可能涉及的实施模式包括但不限于：工厂模式、单例模式、观察者模式、装饰器模式等，这些都是软件工程中常见的设计模式，它们在解决特定问题时能提供强大的指导。此外，书中还会讲述如何在实际开发过程中有效地应用这些模式，如何与团队协作，以及如何通过持续集成和测试驱动开发来确保代码质量。读者将学习到如何通过代码的结构和命名约定来提升沟通效率，以及如何避免常见设计陷阱，从而编写出更加健壮和灵活的系统。 "Implementation Patterns" 是一本对于任何想要提升自己编程技艺，尤其是希望掌握和运用设计模式的开发者来说不可或缺的参考书籍。通过阅读此书，读者不仅能提升个人编程技能，还能更好地理解和实践软件设计的最佳实践，进而提升整个项目的质量和效率。

The rate of change principle is an application of symmetry, but temporal symmetry. In the example above, the two original fields

value and currency are symmetrical. They change at the same time. However, they are not symmetrical with the other fields in

the object. Expressing the symmetry by putting them in their own object communicates their relationship to readers and is likely to

set up further opportunities to reduce duplication and further localize consequences later.

Conclusion

This chapter has introduced the theoretical foundations of the implementation patterns. The values of communication,

simplicity, and flexibility provide wide-ranging motivation for the patterns. The principles of local consequences,

minimize repetition, logic and data together, symmetry, declarative expression, and rate of change help translate the

values into action. Now we come to the patterns, specific solutions to repeating tactical problems in programming.

The next chapter, "Motivation", describes the economic factors that make focusing on communication through code a

valuable activity.

Chapter 4. Motivation

Thirty years ago Yourdon and Constantine in Structured Design identified economics as the underlying driver of software design.

Software should be designed to reduce its overall cost. The cost of software is divided into the initial cost and the cost of

maintenance:

cost

total

= cost

develop

+ cost

maintain

Once the industry gained experience with software development, it was a big surprise to many that the cost of maintenance is

much higher than the cost of initial development. (Projects with little or no maintenance should use a very different set of

implementation patterns from those presented in the remainder of this book.)

Maintenance is expensive because understanding existing code is time-consuming and error-prone. Making changes is generally

easy when you know what needs changing. Learning what the current code does is the expensive part. Once the changes are made,

they need to be tested and deployed.

cost

maintain

= cost

understand

+ cost

change

+ cost

test

+ cost

deploy

One strategy for reducing overall cost is to invest more in initial development in hope of reducing or eliminating the need for

maintenance. Such efforts have generally failed to reduce overall costs. When code needs to change in unanticipated ways, no

amount of forethought can perfectly prepare the code for change. The premature attempts to make the code general enough to

meet future needs often interfere with the unanticipated changes that turn out to be necessary.

Substantially increasing the up-front investment in software runs counter to two important economic principles: the time value of

money and the uncertainty of the future. Since a dollar today is worth more than a dollar tomorrow, in principle an implementation

strategy should generally encourage deferring costs. Also, because of uncertainty an implementation strategy should generally take

immediate benefits in preference over possible long-term benefits. While this may sound like a license to hack without regard for

the future, the implementation patterns are focused on ways to gain immediate benefit while setting up clean code for ease of

future development.

My strategy for reducing overall costs is to ask all programmers to address the cost of understanding code during the maintenance

phase by focusing on communicating, programmer-to-programmer. The immediate benefits of clear code are fewer defects, easier

sharing of code, and smoother development.

Once a set of implementation patterns has become habitual, I program faster and with fewer distracting thoughts. When I began

writing my first set of implementation patterns (The Smalltalk Best Practice Patterns, Prentice Hall 1996) I thought I was a

proficient programmer. To encourage myself to focus on patterns, I refused to type a character of code unless I had first written

down the pattern I was following. It was frustrating, like I was coding with my fingers glued together. For the first week every

minute of coding was preceded by an hour of writing. The second week I found I had most of the basic patterns in place and most

of the time I was following existing patterns. By the third week I was coding much faster than I had before, because I had carefully

looked at my own style and I wasn't nagged by doubts.

The implementation patterns that I wrote down were only partly my own invention. Most of my style was copied from earlier

generations of programmers. They were the habits that resulted in code that was easier to read, understand, and modify, and by

codifying them I was able to code more quickly and fluidly than I had before. I could prepare for the future and get today's code

done faster at the same time.

For the implementation patterns in this book I looked at existing code as well as my own habits for inspiration. I read and

compared code from the JDK, from Eclipse, and from my experience of development. The resulting patterns are intended to be a

coherent view of how to write code people can understand. Other points of view or sets of values would result in different patterns.

For example, I sketch the implementation patterns for framework development in "Evolving Frameworks". These are based on a

different set of priorities and so vary from my basic implementation style.

The implementation patterns serve human as well as economic needs. Code is by people and for people. Programmers can use the

implementation patterns to help satisfy human needs, like the need to take pride in work well done or the need to be a trustworthy

member of a community. I discuss the human and economic impact of the patterns as we go in the following chapters.

Chapter 5. Class

The idea of classes goes back long before Plato. The platonic solids were classes, instances of which could be seen in the world.

The platonic sphere was absolutely perfect but insubstantial. The spheres around us we could touch, but they were all imperfect in

some way.

Object-oriented programming picked up on this idea by way of later western philosophers, dividing programs into classes, which

are general descriptions of a whole set of similar things, and objects, which are the things themselves.

Classes are important for communication because they describe, potentially, many specific things. Class-level patterns have the

largest span of any of the implementation patterns. Design patterns, by contrast, generally talk about the relationships between

classes.

The following patterns appear in this chapter:

 Class— Use a class to say, "This data goes together and this logic goes with it."

 Simple Superclass Name— Name the roots of class hierarchies with simple names drawn from the same metaphor.

 Qualified Subclass Name— Name subclasses to communicate the similarities and differences with a superclass.

 Abstract Interface— Separate the interface from the implementation.

 Interface— Specify an abstract interface which doesn't change often with a Java interface.

 Versioned Interface— Extend interfaces safely by introducing a new sub-interface.

 Abstract Class— Specify an abstract interface which will likely change with an abstract class.

 Value Object— Write an object that acts like a mathematical value.

 Specialization— Clearly express the similarities and differences of related computations.

 Subclass— Express one-dimensional variation with a subclass.

 Implementor— Override a method to express a variant of a computation.

 Inner Class— Bundle locally useful code in a private class.

 Instance-specific Behavior— Vary logic by instance.

 Conditional— Vary logic by explicit conditionals.

 Delegation— Vary logic by delegating to one of several types of objects.

 Pluggable Selector— Vary logic by reflectively executing a method.

 Anonymous Inner Class— Vary logic by overriding one or two methods right in the method that is creating a new object.

 Library Class— Represent a bundle of functionality that doesn't fit into any object as a set of static methods.

Class

Data changes more frequently than logic. That is the observation that makes classes work. Each class is a declaration, "This logic

goes together and changes more slowly than the data values on which it operates. These data values also go together, changing at

similar rates and being operated on by related logic." This strict separation between data-that-changes and

logic-that-does-not-change isn't absolute. Sometimes the logic will be a little different based on data values; sometimes the logic

varies considerably. Sometimes data doesn't change in the course of a computation. Learning how to bundle logic in classes and

express variations in that logic is part of programming effectively with objects.

Organizing classes into hierarchies is a form of compression, taking the superclass and including it textually in all the subclasses.

As with all compression techniques, it leaves the code more difficult to read. You have to understand the context of the superclass

to be able to understand the subclass.

Using inheritance judiciously is another aspect of programming effectively with objects. Creating a subclass says, "I'm like that

superclass, only different." (Isn't it strange that we speak of overriding a method in a subclass? How much better programmers

would we be if we had thoughtfully selected our metaphors?)

Classes are relatively expensive design elements in programs built from objects. A class should do something significant.

Reducing the number of classes in a system is an improvement, as long as the remaining classes do not become bloated.

The patterns that follow explain how to communicate by declaring classes.

Simple Superclass Name

Finding just the right name is one of the most satisfying moments in programming. You're struggling with an idea. Oftentimes, the

code has gotten complicated and it doesn't seem like it needs to be. Then, often in conversation, someone says, "Oh, I see! This is

really a Scheduler." Everyone sits back and lets out a breath. The right name results in a cascade of further simplifications and

improvements.

Some of the most important names to choose well are those of classes. Classes are the central anchoring concept in the design.

Once classes have been named, the names of operations follow. It is rare for the reverse to be true, except if the class was poorly

named in the first place.

In naming classes there is a tension between brevity and expressiveness. You'll be using class names in conversation: "Did you

remember to rotate the Figure before translating it?" The names should be short and punchy. However, to make the names precise

sometimes seems to require several words.

A way out of this dilemma is picking a strong metaphor for the computation. With a metaphor in mind, even single words bring

with them a rich web of associations, connections, and implications. For example, in the HotDraw drawing framework, my first

name for an object in a drawing was DrawingObject. Ward Cunningham came along with the typography metaphor: a drawing is

like a printed, laid-out page. Graphical items on a page are figures, so the class became Figure. In the context of the metaphor,

Figure is simultaneously shorter, richer, and more precise than DrawingObject.

Sometimes, good names take time to find. You may have code "done" and working for weeks, months, or (in one notable case for

me) years when you discover a better name for a class. Sometimes you need to push a little harder to find a name: pull out a

thesaurus, write down a list of the least-suitable names you can think of, take a walk. Sometimes you need to forge ahead with new

functionality, trusting time, frustration, and your subconscious to supply a better name.

Conversation is a tool that consistently helps me find better names. Explaining the purpose of an object to another person leads me

to look for rich and evocative images to describe it. These images can lead in turn to new names.

Look for one-word names for important classes.

Qualified Subclass Name

The names of subclasses have two jobs. They need to communicate what class they are like and how they are different. Again, the

balance to be struck is between length and expressiveness. Unlike the names at the roots of hierarchies, subclass names aren't used

nearly as often in conversation, so they can be expressive at the cost of being concise. Prepend one or more modifiers to the

superclass name to form a subclass name.

One exception to this rule is when subclassing is used strictly as an implementation sharing mechanism and the subclass is an

important concept in its own right. Give subclasses that serve as the roots of hierarchies their own simple names. For example,

HotDraw has a class Handle which presents figure-editing operations when a figure is selected. It is called, simply, Handle in

spite of extending Figure. There is a whole family of handles and they most appropriately have names like StretchyHandle and

TransparencyHandle. Because Handle is the root of its own hierarchy, it deserves a simple superclass name more than a

qualified subclass name.

Another wrinkle in subclass naming is multiple-level hierarchies. Multi-level hierarchies are usually delegation waiting to happen,

but while they exist they need good names. Rather than blindly prepend the modifiers to the immediate superclass, think about the

name from the reader's perspective. What class does he need to know this class is like? Use that superclass as the basis for the

subclass name.

Communication with people is the purpose of class names. As far as the computer is concerned, classes could simply be numbered.

Class names that are too long are hard to read and format. Class names that are too short tax the reader's short-term memory.

Clusters of classes whose names don't relate to each other will be difficult to comprehend and recall. Use class names to tell the

story of your code.

Abstract Interface

The old adage in software development is to code to interfaces, not implementations. This is another way of suggesting that a

design decision should not be visible in more places than necessary. If most of my code only knows that I am dealing with a

collection I am free to change the concrete class later. However, at some point you actually have to commit to a concrete class so

the computer can perform a calculation.

By "interface" here I mean "a set of operations without implementations". This can be represented in Java either as an interface or

as a superclass. Patterns below will suggest when each is appropriate.

Every layer of interface has costs. It is one more thing to learn, understand, document, debug, organize, browse, and name.

Maximizing the number of interfaces doesn't minimize the cost of software. Pay for interfaces only where you will need the

flexibility they create. Since you can't often know in advance where you will need the flexibility of an interface, to minimize cost,

combine speculating about where to introduce interfaces with adding them when flexibility is required.

Much as we complain about the inflexibility of software, there are a very large number of ways we don't need any given system to

flex. From fundamental changes like the number of bits in an integer to large-scale changes like new business models, most

software doesn't need to be flexible in most of the ways it could be.

Another economic factor in introducing interfaces is the unpredictability of software. Our industry seems addicted to the idea that

if only we designed software right we would not have to change our systems. I recently read a list of reasons software changes. On

the list were programmers doing a bad job of eliciting requirements, sponsors changing their mind, and on and on. The one factor

that was missing from the list was legitimate change. The list assumed change was always a mistake. Why won't one weather

forecast do for all time? Because the weather changes in unpredictable ways. Why can't we list once and for all the ways a system

needs to be flexible? Because the requirements change in unpredictable ways and technology changes in unpredictable ways. This

doesn't relieve us from the responsibility to do our best to develop the system customers need right now, but it suggests that there

are limits to the value of "future-proofing" software through speculation.

Putting all of these factors together—the need for flexibility, the cost of flexibility, the unpredictability of where flexibility is

needed—leads me to the belief that the time to introduce flexibility is when it is definitely needed. Introducing flexibility costs

because of the changes you need to make to existing software. If you can't personally change all the software that needs to change,

the costs rise further, a topic taken up in detail in the chapter on evolving frameworks.

Java's two mechanisms for abstract interfaces, superclasses and interfaces, have different cost profiles for such changes.

Interface

One way of saying "Here's what I want to accomplish and beyond that are details that shouldn't concern me" is to declare a Java

interface. Interfaces are one of the important innovations first put in a mass-market language in Java. Interfaces are a nice balance.

They have some of the flexibility of multiple inheritance without the complexity and ambiguity. One class can declare itself as

participating in multiple interfaces. Interfaces reveal only operations, not fields, so they can effectively protect users of an

interface from changes in implementation.

If interfaces enable changes to their implementations, they discourage changes to the interface itself. Any addition or change to an

interface requires modifying all implementors. If you can't modify the implementations, widespread use of interfaces provides

significant drag on further design evolution.

One quirk of interfaces that limits their value as a way to communicate is that all operations are required to be public. I have often

wished for package-visible operations in interfaces. Making design elements a little too public isn't a problem when they are for

private use, but when publishing interfaces to a large audience it would be better to be able to be precise rather than build up

inertia against future change.

Two styles of naming interfaces depend on how you are thinking of the interfaces. Interfaces as classes without implementations

should be named as if they were classes (Simple Superclass Name, Qualified Subclass Name). One problem with this style of

naming is that the good names are used up before you get to naming classes. An interface called File needs an implementation

class called something like ActualFile, ConcreteFile, or (yuck!) FileImpl (both a suffix and an abbreviation). In general,

communicating whether one is dealing with a concrete or abstract object is important, whether the abstract object is implemented

as an interface or a superclass is less important. Deferring the distinction between interfaces and superclasses is well supported by

this style of naming, leaving you free to change your mind later if that becomes necessary.

Sometimes, naming concrete classes simply is more important to communication than hiding the use of interfaces. In this case,

prefix interface names with "I". If the interface is called IFile, the class can be simply called File.

Abstract Class

The other way to express the distinction between abstract interface and concrete implementation in Java is to use a superclass. The

superclass is abstract in the sense that it can be replaced at runtime with any subclass, whether it is abstract in the Java sense or

not.

The trade-offs for when to use an abstract class versus an interface boil down to two issues: changes to the interface and the need

for a single class to support multiple interfaces simultaneously. Abstract interfaces need to support two kinds of change: change in

the implementation and change of the interface itself. Java interfaces do a poor job of supporting the latter. Every change to an

interface requires changes to all implementations. With a widely implemented interface, this can easily lead to paralysis of existing

designs, with further evolution only available through versioned interfaces.

Abstract classes do not suffer this limitation. As long as a default implementation can be specified, new operations can be added to

an abstract class without disrupting existing implementors.

One limitation of abstract classes is that implementors can only declare their allegiance to one superclass. If other views of the

same class are necessary, they must be implementated by Java interfaces.

Using the keyword abstract with a class tells readers that they will have to do some implementation work if they want to use the

class. If there is any chance to make the root of a class hierarchy useful and instantiable on its own, do so. Once on the path of

abstraction, it is easy to go too far and create abstractions that never pay off. Striving to make root classes instantiable encourages

you to eliminate abstractions that are unlikely to pull their weight.

Interfaces and class hierarchies are not mutually exclusive. You can provide an interface which says, "Here's how to access this

kind of functionality," and a superclass which says, "Here's one way to implement this functionality." In this case, variables should

be declared with the interface as their type so future maintainers are free to substitute new implementations as necessary.

Versioned Interface

What do you do when you need to change an interface but you can't? Typically this happens when you want to add operations.

Since adding an operation will break all existing implementors, you can't do that. However, you can declare a new interface that

extends the original interface and add the operation there. Users who want the new functionality use the extended interface while

existing users remain oblivious to the existence of the new interface. Anywhere you want to access the new operation you must

explicitly check the type of your object and downcast to the new type.

For example, consider a simple command:

interface Command {

void run();

}

Once this interface has been published and extended a thousand times, changing it becomes expensive. However, to support

undoing of commands you need a new operation. The versioned interface style of solution is this:

interface ReversibleCommand extends Command {

void undo();

}

Existing instances of Command work as before. Instances of ReversibleCommand work anywhere a Command works. To use the new

operation, downcast:

...

剩余90页未读，继续阅读

海豚的翅膀

粉丝: 0
资源: 158

Kent Beck的《实现模式》——编程领域的智慧结晶

Addison Wesley - Implementation Patterns.pdf

Addison.Wesley.Implementation.Patterns.Nov.2007.pdf

language-implementation-patterns.zip_matlab例程_MultiPlatform_

Implementation.pdf

Language.Implementation.Patterns BOOK Pragmatic

Applying UML and Patterns－use.pdf

language-implementation-patterns

AkkaScala.pdf

Addison.Wesley.C++.by.Dissection.2002.pdf

Language Implementation Patterns Create Your Own Domain-Specific and 无水印原版pdf

最新资源