基本信息
- 原书名：Design Patterns Explained:A New Perspective on Object-Oriented Design (2nd Edition)
- 原出版社： Addison Wesley/Pearson
- 作者： （美）Alan Shalloway, James R.Trott
- 丛书名： 经典原版书库
- 出版社：机械工业出版社
- ISBN：9787111175698
- 上架时间：2005-11-29
- 出版日期：2006 年1月
- 开本：16开
- 页码：429
- 版次：2-1
- 所属分类：计算机 > 软件工程及软件方法学 > 设计模式
编辑推荐
第2版的新增和修订内容：
■开始“用模式的方法思考”的更好方式。
■使用极限编程和其他方法，设计模式如何使敏捷开发更加便利。
■如何使用共同性和可变性分析来设计应用程序架构。
■在模式驱动的开发过程中进行测试的关键作用。
■如何使用工厂来更有效地例示和管理对象。
■对象池 (Object-Pool) 模式－－一种未被GoF标识的新模式。
■每章*后新增思考题/练习题。
内容简介
书籍
计算机书籍
本书的最大特点之一是作者采用类比而不是编程实例的方式将概念解释得非常清楚。我正在做一套关于OOP和软件开发的音频产品，这种讲述概念的方式给予我很大的启发。－－Bruce Eckel.
希望那些仅基本了解面向对象编程和设计的读者，在完全接触设计模式之前，能够发现这本有用的书。本书是对现有的设计模式教材的补充，并可以在入门级教材 (如《UML Distilled》) 和更高级模式著作之间充当一个很好的衔接。－－James Noble..
本书是模式领域最简洁、最清晰、最实用的著作，阐述了模式如何使整个开发过程变得更加容易，解释了面向对象设计的关键原则，以及各种特定模式的概念和优势。通过采用许多最新的Java示例，本书精确地向程序员和架构师展示出如何使用模式来更有效地设计、开发和交付软件。通过分析Java示例，本书提示了为什么、为什么不以及如何应用模式，而且解释了模式的实现。
以畅销的第1版为基础，作者对本版进行了彻底更新，以反映新的软件设计趋势、模式和实现技术。根据广大读者的反馈，作者在第2版中加深了全书概念的阐述，并重新组织了全书内容，使其更易于理解。本书首先概述了模式的基础知识，以及面向对象分析和设计在当代软件开发中的重要性。随后，使用易懂的示例代码阐明了许多当今最有用的模式，包括它们的基础概念、优点、权衡取舍、实现技术以及需要避免的缺陷。另外，许多模式都附有UML图。
本书假定读者没有模式方面的经验，因此是学习模式的理想的第一本书，对于GoF的经典名著《设计模式》，本书也是一个很好的补充。本书适用于学习面向对象设计和设计模式的学生、程序员以及从事软件开发的人士。
第2版的新增和修订内容
■开始“用模式的方法思考”的更好方式。
■使用极限编程和其他方法，设计模式如何使敏捷开发更加便利。
■如何使用共同性和可变性分析来设计应用程序架构。
计算机书籍
本书的最大特点之一是作者采用类比而不是编程实例的方式将概念解释得非常清楚。我正在做一套关于OOP和软件开发的音频产品，这种讲述概念的方式给予我很大的启发。－－Bruce Eckel.
希望那些仅基本了解面向对象编程和设计的读者，在完全接触设计模式之前，能够发现这本有用的书。本书是对现有的设计模式教材的补充，并可以在入门级教材 (如《UML Distilled》) 和更高级模式著作之间充当一个很好的衔接。－－James Noble..
本书是模式领域最简洁、最清晰、最实用的著作，阐述了模式如何使整个开发过程变得更加容易，解释了面向对象设计的关键原则，以及各种特定模式的概念和优势。通过采用许多最新的Java示例，本书精确地向程序员和架构师展示出如何使用模式来更有效地设计、开发和交付软件。通过分析Java示例，本书提示了为什么、为什么不以及如何应用模式，而且解释了模式的实现。
以畅销的第1版为基础，作者对本版进行了彻底更新，以反映新的软件设计趋势、模式和实现技术。根据广大读者的反馈，作者在第2版中加深了全书概念的阐述，并重新组织了全书内容，使其更易于理解。本书首先概述了模式的基础知识，以及面向对象分析和设计在当代软件开发中的重要性。随后，使用易懂的示例代码阐明了许多当今最有用的模式，包括它们的基础概念、优点、权衡取舍、实现技术以及需要避免的缺陷。另外，许多模式都附有UML图。
本书假定读者没有模式方面的经验，因此是学习模式的理想的第一本书，对于GoF的经典名著《设计模式》，本书也是一个很好的补充。本书适用于学习面向对象设计和设计模式的学生、程序员以及从事软件开发的人士。
第2版的新增和修订内容
■开始“用模式的方法思考”的更好方式。
■使用极限编程和其他方法，设计模式如何使敏捷开发更加便利。
■如何使用共同性和可变性分析来设计应用程序架构。
作译者
Alan Shalloway NetObjectives(一家从事面向对象业务咨询／培训的公司)的创始人、CEO和首席顾问，具有20多年的从业经验，并经常受邀在重要的软件开发会议(包括SD Expro、Java One、OOP和OOPSLA)上担任演讲人。他拥有麻省理工学院计算机科学硕士学位。.
James R．Trott 目前是美国西北太平洋地区一家大型金融机构的高级顾问。20多年来，他使用面向对象和基于模式的分析技术在知识管理和知识工程领域积累了丰富的经验。他拥有应用数学科学硕士、工商管理硕士和跨文化研究文科硕士学位。...
James R．Trott 目前是美国西北太平洋地区一家大型金融机构的高级顾问。20多年来，他使用面向对象和基于模式的分析技术在知识管理和知识工程领域积累了丰富的经验。他拥有应用数学科学硕士、工商管理硕士和跨文化研究文科硕士学位。...
目录
Preface
From Object Orientation to Patterns to True Object Orientation
From Artificial Intelligence to Patterns to True Object Orientation
A Note About Conventions Used in This Book.
Feedback
New in the Second Edition
Acknowledgments
PART I An Introduction to Object-Oriented Software
Development
Chapter 1 The Object-Oriented Paradigm
Overview
Before the Object-Oriented Paradigm: Functional Decomposition
The Problem of Requirements
Dealing with Changes: Using Functional Decomposition
Dealing with Changing Requirements
The Object-Oriented Paradigm
Object-Oriented Programming in Action
Special Object Methods
Summary
Review Questions
From Object Orientation to Patterns to True Object Orientation
From Artificial Intelligence to Patterns to True Object Orientation
A Note About Conventions Used in This Book.
Feedback
New in the Second Edition
Acknowledgments
PART I An Introduction to Object-Oriented Software
Development
Chapter 1 The Object-Oriented Paradigm
Overview
Before the Object-Oriented Paradigm: Functional Decomposition
The Problem of Requirements
Dealing with Changes: Using Functional Decomposition
Dealing with Changing Requirements
The Object-Oriented Paradigm
Object-Oriented Programming in Action
Special Object Methods
Summary
Review Questions
前言
Design patterns and object-oriented programming. They hold such promise to make your life as a software designer and developer easier. Their terminology is bandied about every day in the technical and even the popular press. It can be hard to learn them, however, to become proficient with them, to understand what is really going on. .
Perhaps you have been using an object-oriented or object-based language for years. Have you learned that the true power of objects is not inheritance, but is in "encapsulating behaviors"? Perhaps you are curious about design patterns and have found the literature a bit too esoteric and high-falutin. If so, this book is for you.
It is based on years of teaching this material to software developers, both experienced and new to object orientation. It is based upon the belief--and our experience--that when you understand the basic principles and motivations that underlie these concepts, why they are doing what they do, your learning curve will be incredibly shorter. And in our discussion of design patterns, you will understand the true mindset of object orientation, which is a necessity before you can become proficient.
As you read this book, you will gain a solid understanding of 12 core design patterns and a pattern used in analysis. You will learn that design patterns do not exist in isolation, but work in concert with other design patterns to help you create more robust applications. You will gain enough of a foundation that you will be able to read the design pattern literature, if you want to, and possibly discover patterns on your own. Most importantly, you will be better equipped to create flexible and complete software that is easier to maintain.
Although the 12 patterns we teach here are not all of the patterns you should learn, an understanding of these will enable you to learn the others on your own more easily. Instead of giving you more patterns than you need to get started, we have included pattern-related issues that will be more useful.
From Object Orientation to Patterns to True Object Orientation
In many ways, this book is a retelling of my personal experience learning design patterns. This started with learning the patterns themselves and then learning the principles behind them. I expanded this understanding into the realms of analysis and testing as well as learning how patterns relate to agile coding methods. This second edition of this book includes many additional insights I have had since publication of the first edition. Prior to studying design patterns, I considered myself tobe reasonably expert in object-oriented analysis and design. My track record had included several fairly impressive designs and implementations in many industries. I knew C++ and was beginning to learn Java. The objects in my code were well-formed and tightly encapsulated. I could design excellent data abstractions for inheritance hierarchies. I thought I knew object orientation.
Now, looking back, I see that I really did not understand the full capabilities of object-oriented design, even though I was doing things the way most experts advised. It wasn't until I began to learn design patterns that my object-oriented design abilities expanded and deepened. Knowing design patterns has made me a better designer, even when I don't use these patterns directly.
I began studying design patterns in 1996. I was a C++/object-oriented design mentor at a large aerospace company in the Northwest. Several people asked me to lead a design pattern study group. That's where I met my coauthor, Jim Trott. In the study group, several interesting things happened. First, I grew fascinated with design patterns. I loved being able to compare my designs with the designs of others who had more experience than I. And second, I discovered that I was not taking full advantage of designing to interfaces and that I didn't always concern myself with seeing whether I could have an object use another object without knowing the used object's type. I also noticed that beginners in object-oriented design--those who would normally be deemed as learning design patterns too early--were benefiting as much from the study group as the experts were. The patterns presented examples of excellent object-oriented designs and illustrated basic obj ect-oriented principles, which helped to marare their designs more quickly. By the end of the study sessions, I was convinced that design patterns were the greatest thing to happen to software design since the invention of object-oriented design.
When I looked at my work at the time, however, I saw that I was not incorporating any design patterns into my code. Or, at least, not consciously. Later, after learning patterns, I realized I had incorporated many design patterns into my code just out of being a good coder. However, now that I understand patterns better, I am able to use them better.
I just figured I didn't know enough design patterns yet and needed to learn more. At the time, I only knew about six of them. Then I had an epiphany. I was working as a mentor in object-oriented design or a project and was asked to create the project's high-level design. The leader of the project was extremely sharp, but was fairly new to object-oriented design.
The problem itself wasn't that difficult, but it required a great deal of attention to make sure the code was going to be easy to maintain. Literally, after about two minutes of looking at the problem, I had developed a design based on my normal approach of data abstraction. Unfortunately, it was also dear to me this was not going to be a good design. Data abstraction alone had failed me. I had to find something better.
Two hours later, after applying every design technique I knew, I was no better off. My design was essentially the same. What was most frustrating was that I knew there was a better design. I just couldn't see it. Ironically, I also knew of four design patterns that "lived" in my problem, but I couldn't see how to use them. Here I was--a supposed expert in object-oriented design--baffled by a simple problem!
Feeling very frustrated, I took a break and started walking down the hall to clear my head, telling myself I would not think of the problem for at least 10 minutes. Well, 30 seconds later, I was thinking about it again! But I had gotten an insight that changed my view of design patterns: rather than using patterns as individual items, I should use the design patterns together. ..
Patterns are supposed to be sewn together to solve a problem.
I had heard this before, but hadn't really understood it. Because patterns in software have been introduced as design patterns, I had always labored under the assumption that they had mostly to do with design. My thoughts were that in the design world, the patterns came as pretty much well-formed relationships between classes. Then I read Christopher Alexander's amazing book, The Timeless Way of Building (Oxford University Press, 1979). I learned that patterns existed at all levels--analysis, design, and implementation. Alexander discusses using pattems to help in the understanding of the problem domain (even in describing it), not just using them to create the design after the problem domain is understood.
My mistake had been in trying to create the classes in my problem domain and then stitch them together to make a final system, a process that Alexander calls a particularly bad idea. I had never asked whether I had the right classes because they just seemed so right, so obvious; they were the classes that immediately came to mind as I started my analysis, the "nouns" in the description of the system that we had been taught to look for. But I had struggled trying to piece them together.
When I stepped back and used design patterns and Alexander's approach to guide me in the creation of my classes, a far superior solution unfolded in only a matter of minutes. It was a good design, and we put it into production. I was excited--excited to have designed a good solution and excited about the power of design patterns. It was then that I started incorporating design patterns into my development work and my teaching.
I began to discover that programmers who were new to object-oriented design could learn design patterns, and in doing so, develop a basic set of object-oriented design skills. It was true for me, and it was true for the students whom I was teaching.
Imagine my surprise! The design pattern books I had been reading and the design pattern experts I had been talking to were saying that you really needed to have a good grounding in object-oriented design before embarking on a study of design patterns. Nevertheless, I saw, with my own eyes, students who learned object-oriented design concurrently with design patterns learned object-oriented design faster than those just studying object-oriented design. They even seemed to learn design patterns at almost the same rate as experienced objectoriented practitioners.
Perhaps you have been using an object-oriented or object-based language for years. Have you learned that the true power of objects is not inheritance, but is in "encapsulating behaviors"? Perhaps you are curious about design patterns and have found the literature a bit too esoteric and high-falutin. If so, this book is for you.
It is based on years of teaching this material to software developers, both experienced and new to object orientation. It is based upon the belief--and our experience--that when you understand the basic principles and motivations that underlie these concepts, why they are doing what they do, your learning curve will be incredibly shorter. And in our discussion of design patterns, you will understand the true mindset of object orientation, which is a necessity before you can become proficient.
As you read this book, you will gain a solid understanding of 12 core design patterns and a pattern used in analysis. You will learn that design patterns do not exist in isolation, but work in concert with other design patterns to help you create more robust applications. You will gain enough of a foundation that you will be able to read the design pattern literature, if you want to, and possibly discover patterns on your own. Most importantly, you will be better equipped to create flexible and complete software that is easier to maintain.
Although the 12 patterns we teach here are not all of the patterns you should learn, an understanding of these will enable you to learn the others on your own more easily. Instead of giving you more patterns than you need to get started, we have included pattern-related issues that will be more useful.
From Object Orientation to Patterns to True Object Orientation
In many ways, this book is a retelling of my personal experience learning design patterns. This started with learning the patterns themselves and then learning the principles behind them. I expanded this understanding into the realms of analysis and testing as well as learning how patterns relate to agile coding methods. This second edition of this book includes many additional insights I have had since publication of the first edition. Prior to studying design patterns, I considered myself tobe reasonably expert in object-oriented analysis and design. My track record had included several fairly impressive designs and implementations in many industries. I knew C++ and was beginning to learn Java. The objects in my code were well-formed and tightly encapsulated. I could design excellent data abstractions for inheritance hierarchies. I thought I knew object orientation.
Now, looking back, I see that I really did not understand the full capabilities of object-oriented design, even though I was doing things the way most experts advised. It wasn't until I began to learn design patterns that my object-oriented design abilities expanded and deepened. Knowing design patterns has made me a better designer, even when I don't use these patterns directly.
I began studying design patterns in 1996. I was a C++/object-oriented design mentor at a large aerospace company in the Northwest. Several people asked me to lead a design pattern study group. That's where I met my coauthor, Jim Trott. In the study group, several interesting things happened. First, I grew fascinated with design patterns. I loved being able to compare my designs with the designs of others who had more experience than I. And second, I discovered that I was not taking full advantage of designing to interfaces and that I didn't always concern myself with seeing whether I could have an object use another object without knowing the used object's type. I also noticed that beginners in object-oriented design--those who would normally be deemed as learning design patterns too early--were benefiting as much from the study group as the experts were. The patterns presented examples of excellent object-oriented designs and illustrated basic obj ect-oriented principles, which helped to marare their designs more quickly. By the end of the study sessions, I was convinced that design patterns were the greatest thing to happen to software design since the invention of object-oriented design.
When I looked at my work at the time, however, I saw that I was not incorporating any design patterns into my code. Or, at least, not consciously. Later, after learning patterns, I realized I had incorporated many design patterns into my code just out of being a good coder. However, now that I understand patterns better, I am able to use them better.
I just figured I didn't know enough design patterns yet and needed to learn more. At the time, I only knew about six of them. Then I had an epiphany. I was working as a mentor in object-oriented design or a project and was asked to create the project's high-level design. The leader of the project was extremely sharp, but was fairly new to object-oriented design.
The problem itself wasn't that difficult, but it required a great deal of attention to make sure the code was going to be easy to maintain. Literally, after about two minutes of looking at the problem, I had developed a design based on my normal approach of data abstraction. Unfortunately, it was also dear to me this was not going to be a good design. Data abstraction alone had failed me. I had to find something better.
Two hours later, after applying every design technique I knew, I was no better off. My design was essentially the same. What was most frustrating was that I knew there was a better design. I just couldn't see it. Ironically, I also knew of four design patterns that "lived" in my problem, but I couldn't see how to use them. Here I was--a supposed expert in object-oriented design--baffled by a simple problem!
Feeling very frustrated, I took a break and started walking down the hall to clear my head, telling myself I would not think of the problem for at least 10 minutes. Well, 30 seconds later, I was thinking about it again! But I had gotten an insight that changed my view of design patterns: rather than using patterns as individual items, I should use the design patterns together. ..
Patterns are supposed to be sewn together to solve a problem.
I had heard this before, but hadn't really understood it. Because patterns in software have been introduced as design patterns, I had always labored under the assumption that they had mostly to do with design. My thoughts were that in the design world, the patterns came as pretty much well-formed relationships between classes. Then I read Christopher Alexander's amazing book, The Timeless Way of Building (Oxford University Press, 1979). I learned that patterns existed at all levels--analysis, design, and implementation. Alexander discusses using pattems to help in the understanding of the problem domain (even in describing it), not just using them to create the design after the problem domain is understood.
My mistake had been in trying to create the classes in my problem domain and then stitch them together to make a final system, a process that Alexander calls a particularly bad idea. I had never asked whether I had the right classes because they just seemed so right, so obvious; they were the classes that immediately came to mind as I started my analysis, the "nouns" in the description of the system that we had been taught to look for. But I had struggled trying to piece them together.
When I stepped back and used design patterns and Alexander's approach to guide me in the creation of my classes, a far superior solution unfolded in only a matter of minutes. It was a good design, and we put it into production. I was excited--excited to have designed a good solution and excited about the power of design patterns. It was then that I started incorporating design patterns into my development work and my teaching.
I began to discover that programmers who were new to object-oriented design could learn design patterns, and in doing so, develop a basic set of object-oriented design skills. It was true for me, and it was true for the students whom I was teaching.
Imagine my surprise! The design pattern books I had been reading and the design pattern experts I had been talking to were saying that you really needed to have a good grounding in object-oriented design before embarking on a study of design patterns. Nevertheless, I saw, with my own eyes, students who learned object-oriented design concurrently with design patterns learned object-oriented design faster than those just studying object-oriented design. They even seemed to learn design patterns at almost the same rate as experienced objectoriented practitioners.
