CHAPTER 1: Hello, Design Patterns!
13
Ideally, there is no need to create new components to achieve reuse. It
is quite rare that you should be able to get all the functionality you
need just by assembling existing components through object
composition. In practice, the set of available components is never
quite rich enough.
Despites the cons, object composition can provide many benefits on system design.
Those cons can be counter-balanced by using class inheritance in certain areas as it
helps make it easier to make new components from old ones.
So when you favor object composition over class inheritance, it doesn’t mean that you
shouldn’t use class inheritance at all. You need to make a clear judgment on how to
reuse classes and objects in certain situations. Class inheritance and object composition
can work together if you design them properly for your systems. A natural way to think
before you design a class is more towards object composition. You can then refine the
design by looking for redundant behavior; if found, it may be a sign that’s begging for
class inheritance there. You will see object composition in the design patterns discussed
in this book.
Objects and Classes Used in this Book
I use different diagrams and graphics in the book to illustrate some important ideas of
the patterns. Sometimes I’ll use screenshots or other visual representation to showcase,
for example, the structure of a composite tree object. But I needed something more
formal and clear to denote relationships and interactions between classes and objects
alike. Most commonly used notations throughout the patterns in the book are class and
object diagrams. I borrowed the OMT (Object Modeling Technique) notation and
modified it to fit my needs. This section is going to describe the notations used for class
and object diagrams.
Class Diagram
A class diagram illustrates classes, the static relationships between them, and their
structure. In Objective-C, you can define a protocol, (abstract) class, and a category in
your applications.
Protocol, Abstract Class, Concrete Class, and Category
In general, a round rectangular box denotes a class entity with its name in bold type at
the top and operation names in the lower part of the box. If you are reading an electronic
version of this book, you’ll see that the background color of the protocol’s title bar is
pink and the other class entities’ title bars have a light blue background. Names for
abstract anything are in italics. So a protocol and an abstract class appear in bold and
italics. A protocol name is enclosed in a pair of angle brackets. Instance variables are
put in the very bottom part of the box. Samples of different class entities are illustrated
in Figure 1–2.
剩余372页未读，继续阅读
nice迪
- 粉丝: 3
- 资源: 22
我的内容管理
展开
最新资源
- AirKiss技术详解：无线传递信息与智能家居连接
- Hibernate主键生成策略详解
- 操作系统实验：位示图法管理磁盘空闲空间
- JSON详解：数据交换的主流格式
- Win7安装Ubuntu双系统详细指南
- FPGA内部结构与工作原理探索
- 信用评分模型解析：WOE、IV与ROC
- 使用LVS+Keepalived构建高可用负载均衡集群
- 微信小程序驱动餐饮与服装业创新转型：便捷管理与低成本优势
- 机器学习入门指南：从基础到进阶
- 解决Win7 IIS配置错误500.22与0x80070032
- SQL-DFS：优化HDFS小文件存储的解决方案
- Hadoop、Hbase、Spark环境部署与主机配置详解
- Kisso：加密会话Cookie实现的单点登录SSO
- OpenCV读取与拼接多幅图像教程
- QT实战：轻松生成与解析JSON数据
资源上传下载、课程学习等过程中有任何疑问或建议，欢迎提出宝贵意见哦~我们会及时处理！
点击此处反馈
