《Design Patterns Java™ Workbook》实战指南

4星 · 超过85%的资源需积分: 10 170 浏览量更新于2024-07-26 收藏 4.44MB PDF 举报

"Addison Wesley - Design Patterns Java Workbook 是一本由Steven John Metsker编著的书籍，专注于帮助Java程序员理解和应用设计模式。这本书出版于2002年，由Addison Wesley出版社发行，ISBN号为0-201-74397-3，共496页。书中包含23个基础设计模式，这些模式源自经典的《Design Patterns》（Addison-Wesley, 1995）一书。" 在《Design Patterns Java Workbook》中，作者Steve Metsker采用实践学习的方法，旨在帮助读者将设计模式理论应用于实际问题，从而提升编程技能并增强在关键任务应用中有效使用设计模式的信心。本书将设计模式分为五个主要类别： 1. **接口（Interfaces）**：这部分内容可能涵盖如何使用Java的接口来实现松耦合，以及如何通过接口实现多态性，使代码更具可扩展性和可维护性。 2. **责任（Responsibility）**：这可能涉及到面向对象设计中的职责分配，如单一职责原则(SRP)，确保每个类或模块有且只有一个职责，以提高代码的可读性和可测试性。 3. **构造（Construction）**：这部分可能包括工厂模式、抽象工厂模式、建造者模式等，介绍如何在对象创建过程中控制复杂性的方法，以及如何在不暴露创建细节的情况下提供对象实例。 4. **操作（Operations）**：可能涵盖观察者模式、访问者模式等，讨论如何处理对象之间的交互和通信，以及如何在运行时动态改变对象的行为。 5. **扩展（Extensions）**：可能涉及装饰者模式、策略模式、代理模式等，介绍如何在不修改原有代码的基础上增加新功能或改变现有行为，以实现灵活的系统设计。每个类别都先从复习和挑战开始，检验读者对Java内置功能的掌握，然后通过详细的章节解释各个设计模式的原理、使用场景、优缺点以及如何在Java中实现。书中的练习和挑战题旨在让读者通过实践加深理解，提升设计和实现能力。《Design Patterns Java Workbook》是一本实用的指南，旨在帮助Java开发者熟练掌握和运用设计模式，以解决复杂软件设计问题，提升代码质量和可维护性。对于希望提升自身技术水平，特别是想在实际项目中应用设计模式的Java程序员来说，这本书是不可或缺的学习资源。

expressed as the need to go beyond the ordinary facilities that are built into Java. For

example, Java has plentiful support for defining the interfaces that a class implements.

But if you want to adapt a class's interface to meet the needs of a client, you need to

apply the ADAPTER pattern. The intent of the ADAPTER pattern goes beyond the

interface facilities built into Java.

This book places design pattern intent in five categories, as follows:

•

Interfaces

• Responsibility

• Construction

• Operations

• Extensions

These five categories account for five parts of this book. Each part begins with a chapter

that discusses and presents challenges related to features built into Java. For example,

Part I

, Interface Patterns, begins with a chapter on ordinary Java interfaces. That chapter

will challenge your understanding of the Java interface construct, especially in

comparison to abstract classes. The remaining chapters of Part I

address patterns whose

primary intent involves the definition of an interface—the set of methods that a client can

call from a service provider. Each of these patterns addresses a need that cannot be

addressed solely with Java interfaces.

Table 1.2. Categorization of Patterns by Intent

INTENT PATTERNS

INTERFACES ADAPTER, FACADE, COMPOSITE, BRIDGE

RESPONSIBILITY SINGLETON, OBSERVER, MEDIATOR, PROXY, CHAIN OF

RESPONSIBILITY, FLYWEIGHT

CONSTRUCTION BUILDER, FACTORY METHOD, ABSTRACT FACTORY,

PROTOTYPE, MEMENTO

OPERATIONS TEMPLATE METHOD, STATE, STRATEGY, COMMAND,

INTERPRETER

EXTENSIONS DECORATOR, ITERATOR, VISITOR

Categorizing patterns by intent does not mean that each pattern support only one type of

intent. A pattern that supports more than one type of intent appears as a full chapter in

the first part to which it applies and gets a brief mention in subsequent sections. Table

1.2 shows the categorization behind the organization of this book.

I hope that you will question the categorization in Table 1.2

. Do you agree that

SINGLETON is about responsibility, not construction? Do you think that COMPOSITE is an

interface pattern? Categorizing patterns is somewhat subjective. But I hope that you will

agree that thinking about the intent behind patterns and thinking about how you will

apply patterns are very useful exercises.

Welcome to Oozinoz!

The challenges in this book all cite examples from Oozinoz, a fictional company that

manufactures and sells fireworks and puts on fireworks displays. (Oozinoz takes its name

from the sounds heard at Oozinoz exhibitions.) The current code base at Oozinoz is

pretty well designed, but many challenges remain for you to make the code stronger by

applying design patterns.

Source Code Disclaimer

The source code used in this book is available at www.oozinoz.com. The code is free. You

may use it as you wish, with the sole restriction that you may not claim that you wrote it.

On the other hand, neither I nor the publisher of this book warrant the code to be useful

for any particular purpose. If you use the oozinoz code, I hope that you will thoroughly

test that it works properly with your application. And if you find a defect in my code,

please let me know! I can be contacted at Steve.Metsker@acm.org

Summary

Patterns are distillations of accumulated wisdom, providing a standard jargon and

naming the concepts that experienced practitioners apply. The patterns in Design

Patterns are among the most useful class-level patterns and are certainly worth learning.

This book complements Design Patterns providing challenges to exercise your

understanding of the patterns. This book uses Java in its examples and challenges

because of Java's popularity and its future prospects. By working through the challenges

in this book, you will learn to recognize and to apply a large portion of the accumulated

wisdom of the software community.

Part I: Interface Patterns

Chapter 2. Introducing Interfaces

Chapter 3. Adapter

Chapter 4. Facade

Chapter 5. Composite

Chapter 6. Bridge

Chapter 2. Introducing Interfaces

Speaking abstractly, a class's interface is the collection of methods and fields that a

class permits objects of other classes to access. This interface usually represents a

commitment that the methods will perform the operation implied by their names and as

specified by code comments and other documentation. A class's implementation

is the

code that lies within its methods.

Java elevates the notion of interface to be a separate construct, expressly separating

interface—what an object must do—from implementation—how an object fulfills this

commitment. Java interfaces allow several classes to provide the same functionality, and

they open the possibility that a class can implement more than one interface.

The Java interface construct is a powerful tool worth studying in its own right, but your

design intent will sometimes go beyond the simple definition of an interface. For

example, you might use an interface to adapt a class's interface to meet a client's needs,

applying the ADAPTER pattern. You might also create an interface to a collection of

classes, applying the FACADE pattern. In this case, you create a new interface by

creating a new class rather than a new interface. In these circumstances and others you

can apply design patterns to go beyond the ordinary use of interfaces.

Ordinary Interfaces

Design Patterns (Gamma et al. 1990) frequently mentions the use of abstract classes but

does not describe the use of interfaces. The reason is that the languages C++ and

Smalltalk, which Design Patterns uses for its examples, do not have an interface

construct. This omission has a minor impact on the utility of the book for Java

developers, because Java interfaces are quite similar to abstract classes.

CHALLENGE

2.1

Write down three differences between abstract

classes and interfaces in Java.

The basic definition of Java interfaces is not complex. However, you should be aware of a

few subtle points when using them.

Consider the definition of an Oozinoz interface that rocket simulation classes must

implement. Engineers design many different rockets, including solid- and liquid-fueled

rockets, with completely different ballistics. Regardless of how a rocket is composed, a

simulation for the rocket must provide figures for the rocket's expected thrust and

apogee

, or the greatest height the rocket will achieve. Here is the exact code, minus the

code comments, that Oozinoz uses to define the rocket simulation interface:

package com.oozinoz.simulation;

import com.oozinoz.units.*;

interface RocketSim

{

abstract Length apogee();

public Force thrust();

}

Classes that provide rocket simulations implement the RocketSim interface. A rocket's

apogee and thrust are quantities that combine a magnitude with the physical dimensions

of length and force, respectively. (Chapter 3

, Adapter, has more information about the

units package, on page 24.

CHALLENGE

2.2

Which of the following statements are true?

A. Both methods of the RocketSim

interface are abstract, although

only

apogee() declares this

explicitly.

B. Both methods of the interface are

public, although only thrust()

declares this explicitly.

C. All interfaces are public, so

RocketSim is public, although it

does not declare this explicitly.

D. It is possible to create another

interface, say,

RocketSimSolid

, that

剩余352页未读，继续阅读

洛神夫

粉丝: 125
资源: 10

《Design Patterns Java™ Workbook》实战指南

vc编程系列之Addison Wesley - Design Patterns Explained

Addison Wesley - .NET Patterns--Architecture, Design, and Process

Addison Wesley - Design Patterns

Addison Wesley - Design Patterns.pdf

vc编程系列之Addison Wesley - Design Patterns

Addison Wesley - Implementation Patterns.pdf

十大经典java书籍之Addison Wesley - Gamma, Helm, Johnson, Vlissides - Design Patterns, Elements Of Reusable Object Oriented Software, 1998

Design Patterns Java Workbook - Addison Wesley

Addison Wesley - Algorithms in Java Parts 1-4 3rd Edition

Addison Wesley - Algorithms in Java Parts 1-5 3rd Edition 完整版

最新资源