www.xuexi86.com
3. The solution describes the elements that make up the design,their relationships,responsibilities,and collaborations.The solution doesn't describe a particular concrete design or implementation,because a pattern is like a template that can be applied in many different situations. Instead, the pattern provides an abstract description of a design problem and how a general arrangement of elements (classes and objects in our case) solves it.
4. The consequences are the results and trade-offs of applying the pattern. Though consequences are often unvoiced when we describe design decisions,they are critical for evaluating design alternatives and for understanding the costs and benefits of applying the pattern. The consequences for software often concern space and time trade-offs. They may address language and implementation issues as well. Since reuse is often a factor in object-oriented design,the consequences of a pattern include its impact on a system's flexibility,extensibility,or portability. Listing these consequences explicitly helps you understand and evaluate them.
Point of view affects one's interpretation of what is and isn't a pattern. One person's pattern can be another person's primitive building block. For this book we have concentrated on patterns at a certain level of abstraction. Design patterns are not about designs such as linked lists and hash tables that can be encoded in classes and reused as is. Nor are they complex,domain-specific designs for an entire application or subsystem. The design patterns in this book are descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context.
A design pattern names,abstracts,and identifies the key aspects of a common design structure that make it useful for creating a reusable object-oriented design. The design pattern identifies the participating classes and instances,their roles and collaborations,and the distribution of responsibilities. Each design pattern focuses on a particular object-oriented design problem or issue. It describes when it applies,whether it can be applied in view of other design constraints,and the consequences and trade-offs of its use. Since we must eventually implement our designs,a design pattern also provides sample C++ and (sometimes) Smalltalk code to illustrate an implementation.
Although design patterns describe object-oriented designs,they are based on practical solutions that have been implemented in mainstream object-oriented programming languages like Smalltalk and C++ rather than procedural languages (Pascal,C,Ada) or more dynamic object-oriented languages (CLOS,Dylan,Self). We chose Smalltalk and C++ for pragmatic reasons: Our day-to-day experience has been in these languages,and they are increasingly popular.
The choice of programming language is important because it influences one's point of view. Our patterns assume Smalltalk/C++-level language features， and that choice determines what can and cannot be implemented easily. If we assumed procedural languages,we might have included design patterns called "Inheritance，" "Encapsulation," and "Polymorphism." Similarly,some of our patterns are supported directly by the less common object-oriented languages. CLOS has multi-methods,for example,which lessen the need for a pattern such as Visitor . In fact,there are enough differences between Smalltalk and C++ to mean that some patterns can be expressed more easily in one language than the other.
您的位置：学习中国
→ 常用工具
→ 电子书籍
→ 正文
本文章所属分类：首页
→ 常用工具
→ 电子书籍
电子书籍