《模式 工程化实现及扩展 (设计模式 C#版)》 - 书摘精要

(P3)

面向对象的典型原则可以划分为两类 ―― “面向类”的和“面向包”的；

“面向类”的，包括：
SRP ―― 单一职责原则；
OCP ―― 开放封闭原则；
LSP ―― 里氏替换原则；
DIP ―― 依赖倒置原则；
ISP ―― 接口隔离原则；

“面向包”的，包括：
REP ―― 重用发布等价原则；
CCP ―― 共同封装原则；
CRP ―― 共同重用原则；
ADP ―― 无环依赖原则；
SDP ―― 稳定依赖原则；
SAP ―― 稳定抽象原则；

“面向包”的6个原则可以再划分为两类：REP、CCP、CRP 强调的是包的内聚性设计要求，而 ADP、SDP、SAP针对的是包间耦合性要求；

(P7)

里氏替换原则是站在模式对象这一方，依赖倒置原则是站在客户程序这一方。模式对象这一方将“相对多变的”子类视同它的接口(或父类)，而客户程序依赖的内容不是“相对多变”的子类，而是“相对稳定”的接口；

(P10)

迪米特法则不希望与非“友”的类型建立直接联系，即便联系的都是“友”也要和“最近的密友”联系，并且联系的时候最好不要谈“隐私”(即专门类型)，要用一些相对广为人知的知识进行交互；

迪米特法则在生活中最直观的表现就是“人脉”，不过不同点在于迪米特法则希望的是人脉窄，而现实中我们希望的是人脉宽、路子广；

(P15)

开发软件的主要目的是满足用户的需要，同时获得收益；

工程化软件的特点不仅仅是看上去很“面向对象”，关键是能够用简洁、必要的面向对象手段解决问题，少投入、多产出；

(P18)

好的命名空间规划是工程化代码与非工程化代码一个最直观的区别；

(P21)

在.Net中委托也是一个抽象手段，它是对方法的抽象；

(P22)

委托是对具体方法的抽象，它屏蔽了委托的调用者与实际执行方法间的关联关系；

(P25)

方法，就是一小段可以重用的处理过程；

事件是委托的特例，“特”表现在如下4个方面：
―― 返回值为 void；
―― 第一个参数 sender 是 System.Object；
―― 第二个参数继承自 EventArgs 或其子类；
―― 仅限两个参数；

(P29)

C# 为我们提供了5种抽象能力：
Class ―― 对现实世界的抽象；
Interface ―― 对 Class 行为的抽象；
Delegate ―― 对方法的抽象；
Attribute ―― 对类型元数据的抽象；
Generics ―― 给上述因素进一步、进两步、直至进N步抽象的机会；

(P33)

接口和参数更明确，而且不仅仅停留在 UML 的图纸上，在编码和调用过程中都起到刚性的检查作用；

(P34)

如果代码将被反复重用，只要进度允许，尽量泛型；

(P49)

不建议在 .Net 2.0 版本以前的项目中采用接口注入的方式；

(P76)

工厂方法模式是 GOF 23个设计模式中最具启发效果的，它告诉我们可以通过增加新的对象专门管理“变化”；

(P78)

静态类不能被继承，所以看起来静态类更像以前的 API 集合，有点不那么“面向对象”的味道；

(P93)

单件模式要做的就是通过控制类型实例的创建过程，确保客户程序使用的都是创建好的同一个实例；

(P105)

Singleton 模式在 .Net 平台一个最简洁但又相对线程安全的实现方式：

sealed class Singleton
{
   Singleton() {}
   public static readonly Singleton Instance = new Singleton();
}

(P115)

使用时可以把工厂方法、静态工厂、简单工厂和抽象工厂混合起来：

静态工厂可以作为最底层的一个“泵”，它提供最原始但最粗颗粒度对象的创建，甚至仅仅返回弱类型的 object 也可以，后绑定调用(或被称为晚绑定)可以通过一个集中的静态工厂完成。之所以把它放在最下面，主要是因为它不能被继承和进一步扩展，所以让它做最基本但又最通用的工作。实际项目中可以用 Activator 类充当这个角色；

简单工厂的适用范围很广，根据应用的需要在某些需要隔绝抽象与具体的位置上使用；

工厂方法应用在具有一套较纵深层次的对象上，可以通过具体工厂类型选择继承层次上一个合适的具体产品来构造，而客户程序则把握住抽象的工厂类型和抽象的产品类型即可；

抽象工厂方法则用在某些特定领域上，面向某些应用子系统或专业领域的对象创建工作，相对而言，我们可以把它更多地用于项目的中、高层设计中；

(P142)

项目中，使用原型模式的关键不在于定义一个 IPrototype 接口，而在于如何又好又快地完成克隆过程；

(P148)

适配器主要有3个作用：
―― 完成旧接口到新接口的转换；
―― 将“既有系统”进行封装，逻辑上客户程序应该不知道“既有系统”的存在，将变化隔离在适配器部分；
―― 如果客户程序需要迁移，仅需要在适配器部分做修改；

适配器模式配合代理模式，它们能起到“稳定性边界”的作用，即当一个范围内的对象相对稳定，而与之交互范围内的对象相对不稳定(或不确定能否稳定)时，我们可以考虑在边界上增加适配器和代理；

(P166)

桥模式解决的是对抽象中正交变化因素的进一步分解及衔接；

(P206)

在实际项目中，装饰模式的应用比例不高，主要是因为追踪和调试相对困难，多数情况下项目中更愿意采用多接口组合的方式；

(P216)

值类型要么是堆栈分配的，要么是在结构中以内联方式分配的，值类型包括简单类型、枚举类型和结构类型；

引用类型是堆分配的，操作它们的时候我们是基于引用完成的，引用类型包括类类型、接口类型、委托类型和数组类型；

(P224)

外观模式是屏蔽复杂性的，很多时候代理模式的控制本身也就是对各种复杂性的屏蔽，只不过外观处理的是一个逻辑上的“子系统”，而且其封装后的结果并没有具体抽象接口的要求，但在代理模式中客户程序需要的接口事先是明确的。外观模式往往会生成一个更易于使用的新接口，而代理模式保持接口一致；

(P226)

代理模式既以设计模式出现，用时也是很重要的架构模式；

(P237)

CoR 模式广泛应用于架构模式、大型项目的基础平台及 SOA 环境下的企业服务总线(Enterprise Service Bus, ESB)，其交互过程中往往涉及分布式事务性链式操作，消息队列、数据库、外部服务及云计算环境都可以针对一个 Request 内容用“链式”方法连接；

(P242)

模板方法模式的概念虽然简单，但它却充斥在软件架构的方方面面；

(P245)

模板方法模式主要采用继承(或接口实现)完成，而策略模式更多通过委托解决；

模板方法模式关注点在于算法中的每个步骤的差异及可替换性，而策略模式则是对整个算法进行替换；

(P273)

从工程角度看，命令模式最大的优势在于它为应用的扩展性、高可用性提供了基础；

(P284)

“依赖于抽象” ―― 如果客户程序使用一个继承体系上的某个具体类型的时候，就从这个体系上抽象出一个接口，然后通过创建型模式让客户程序按照接口要求向客户程序提供实例；

(P295)

备忘录模式是为了给应用一个 Undo() 的机会；

(P317)

ABC (Address、Binding、Contract) 组合常被称为 (ServiceEndpoint)；

(P333)

命令模式解决的是“做什么”，它把到底需要做什么的问题延迟到子类中定义；

策略模式关注于“怎么做”，也就是为了完成一个既定的处理，算法上怎么实现的问题；

(P351)

如果对象的不确定性来自于构造过程，那么借助“创建型模式”，控制目标对象的数量或者把创建工作交给一个独立的对象完成。这样，业务对象自身不会为了构造其他对象产生直接依赖。当然，实现该目标有一个前提，那就是待构造的对象先被抽象；

如果对象的不确定性来自结构，则可以考虑“结构型模式”，用一个相对抽象的对象协调结构上的依赖关系；

如果不确定性来自执行过程，则可以考虑“行为型模式”，行为型模式多数时候是对执行逻辑复杂性的进一步分解，比如某些操作、交互过程过于复杂，这时就需要对它们分解。行为型的思维方法就是把这些复杂而且易变操作和交互对象化，同时抽象它们的行为，确保这些对象后续可以被替换；

(P381)

视野决定高度；