面向对象OO和设计模式心得和笔记
面向对象三大特点：
封装：
封装，也就是把客观事物封装成抽象的类，并且类可以把自己的数据和方法只让可信的类或者对象操作，对不可信的进行信息隐藏。
不关注处理过程了，只有对象和其职能。
只允许设定的对象访问自身信息，其余私人信息隐藏。
作用：封装可以隐藏实现细节，使得代码模块化，局域化，简单；
继承：
继承的父类最好是接口，最好连属性都没有。
少用实现继承（库内使用较多），多用组合。
忘了多重继承，除非实现多接口。
作用：扩展已有代码模块；代码重用（库内使用较多），多态的基础
多态：
静态--编程时采用父类型-针对接口编程
动态--执行时才实际映射成具体的子类
作用：静态时针对接口编程，执行时才体现实际的效果
面向对象设计原则：
单一职责原则（SRP）：
就一个类而言，应该仅有一个引起它变化的原因；当职责越多，耦合越多，易遭破坏
软件设计真正要做的就是发现职责并将这些职责相互分离
把职责分离到单独的类中,因为每一个类都是变化的轴线，当需求变化时,该变化会反映为类的职责的变化，如果一个类承担了多余一个的职责,那么引起他变化的原因就会有多个。职责定义为“变化的原因”。
如果一个类承担的职责过多,就等于把这些职责耦合在了一起,一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力，这种耦合会导致脆弱的设计，当变化发生时，设计会受到意想不到的破坏。
另一方面，如果应用程序的变化方式总是导致这两个职责同时变化，那么就不必分离它们，实际分离它们就会导致不必要的复杂性的臭味。
SRP是所有原则中最简单的也是最难以正确应用的原则之一。
开放封闭职责：
软件实体应该可以扩展，但是不可修改。
软件要容易维护又不容易出问题的最好方法是多扩展，少修改。
无论模块多么封闭，都会有无法封闭的变化，事先构造抽象隔离这些变化。
面对新需求，对程序的改动是通过增加新代码进行的，而不是更改现有的代码。
OCP的关键是抽象，对于代码的改动是通过增加新代码进行的，而不是更改现有代码，因此他就不会引起像不遵循OCP原则那样的连锁改动。
通常，我们更愿意一直等到确实需要那些抽象时再把他放进去，“我们愿意被第一颗子弹射中，但是我们不会再被同一支枪射得其他子弹射中”。
可以按照以下的一些方法完成这项工作:
我们首先编写测试.测试描绘了系统的一种使用方法,通过首先编写测试,我们迫使系统成为可测试的,在一个具有可测试的.在一个具有可测试性的系统中发生变化时,我们可以坦然对之,因为我们已经构建了使用系统可测试的抽象,并且通常这些抽象中的许多都会隔离以后发生的其他种类的变化.
在许多方面,OCP都是面向对象设计的核心所在,遵循这个原则可以带来面向对象技术所声称的巨大好处(灵活,可重用,可维护性),然而,并不是说只要使用一种面向对象的语言就是遵循了这个原则,对于程序中的每个部分都肆意进行抽象同样不是一个好主意,正确的做法是,开发人员应该仅仅对程序中呈现出频繁变化的那部分作出抽象.拒绝不成熟的抽象和抽象本身一样重要.
依赖倒转原则
高层模块不应该依赖低层模块，两个都应该依赖于抽象
抽象不应该依赖于细节，细节应该依赖于抽象
即要针对接口编程，不要对实现编程
本应该是高层的策略设置模块去影响低层细节实现的模块的，包含高层业务规则的模块应该优先并独立于包含实现细节的模块，无论如何高层模块都不应该依赖于低层模块。
我们更希望能够重用的是高层策略模块，如果高层模块独立于底层模块，那么高层模块就能更容易的被重用，该原则是框架的设计核心原则。
所有结构良好的面向对象的架构都具有清晰的层次定义，每个层次通过一个定义良好的、受控制的接口向外提供一组内聚的服务。
每个较高的层次都为它所需要服务声明一个抽象接口，较低层次实现了这些抽象接口，每个高层类都通过接口使用下一层，这样高层就不依赖于低层。低层反而依赖于在高层中声明的抽象服务接口。
这种倒置不仅仅是依赖关系的倒置。它也是接口所有权的倒置。
依赖倒置可以应用于任何一个类向另一个类发送消息的地方。
违反DIP，高层策略没有和底层实现分离，抽象没有和具体细节分离，没有这种分离，高层策略就自动的依赖于低层模块，抽象就自动的依赖于具体细节。
里氏代换原则（LSP）
子类型必须替换掉它们的父类型。
适用于父类的一定适用于子类
LSP让我们得到一个非常重要的结论:一个模型，如果孤立的看，并不具有真正意义上的有效性，模型的有效性必须通过他的客户程序来表现。
如果一组类都支持一个公共的职责，那么它们就应该从一个公共的超类继承该职责。如果公共的超类还不存在，那么就创建一个，并把公共的职责放入其中，毕竟这样一个类的有用性是确定无疑的。
有一些简单的启发规则可以提供一些有关违反LSP的提示，这些规则都和以某种方式从其基类中去除某功能的派生类有关，完成的功能少于其基类的派生类通常是不能替换其基类的，因此就违反了LSP。
另外一种违反LSP的规则形式是在派生类的方法中添加了其基类不会抛出的异常，如果基类的使用者不期望这些异常，那么把它们添加到派生类的方法中就会导致不可替代性，此时要遵循LSP，要么就必须改变使用者的期望，要么派生类就不应该抛出这些异常。
OCP是OOD中很多说法的核心。如果这个原则应用的有效，应用程序就会具有更多的可维护性，可重用性以及健壮性，LSP是使用OCP成为可能的主要原则之一。
迪米特法则（LoD）
如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。
法则强调类之间的松耦合。
接口隔离原则ISP
这个原则用来处理“胖”接口所具有的缺点。如果类的接口不是内聚的，就表示该类具有胖的接口。换句话说，类的胖接口可以分解成多组方法，每一组方法服务于一组不同的客户端程序。
不应该强迫客户依赖于它们不用的方法。
如果一个客户端程序依赖于一个含有它不使用的方法的类，但其他客户端缺要使用该方法，那当其他客户端对这个类改变时，就会影响到这
创建模式
抽象工厂模式（Abstract Factory）
提供一个创建一系列相关或相互依赖对象的接口，而无需指定他们具体的类。
################################
一个抽象工厂多个方法，每个方法创建一个（抽象）对象；
不同工厂实例可得到不同风格对象集；
-----优缺点-----
创建操作和实际的产品对象集都独立出来
更换产品对象集很方便
接口已定义好能创建的集中对象个数，难扩展--通过参数传入创建不同类（返回对象类型很难定，需要向下类型转换不安全）
-----关联-----
具体的工厂通常是单件
通常用工厂方法或原型来实现抽象工厂中的各方法
建造者模式（Builder）
将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。
################################
定义一个有创建各子部件方法（不返回）和返回组合好的父部件的接口，从而封装内部子对象创建的细节
实现子类，以不同的创建方式实现这些方法，每个子类就是一种创建子部分方法
外部通过创建导向器Director配置创建子部件的方式（顺序和约束），并得到组合好的父部件。
最终产品不需要是抽象类，直接具体的复合类即可
-----关联-----
Builder着重于一步步创建复杂对象，最后返回
Abstract Factory创建一系列多个对象，创建一个返回一个
Composite通常是用Builder生成的
工厂方法模式（Factory Method）
定义一个用于创建对象的接口，让子类决定实例化哪一个类。
################################
一个接口一个方法创建一个抽象对象，子类确定实现那个具体类。
通过传入参数生成不同对象避免为已确定的类型生成不同子类（写在父类中）
-----关联-----
通常在Template Method中被调用
原型模式（Prototype）
用原型实例指定创建对象的种类，并通过拷贝这些原型创建新的对象。
################################
用来Clone一个自身的对象，包含一个Clone的操作。
从一个对象再创建另外一个可定制的对象，而不需要知道任何创建的细节。
注意Clone过程中的浅拷贝和深拷贝的问题
-----优缺点-----
运行时刻增加删除新原型
定制新的原型并加入到系统中很方便
原型需要有Clone操作，已有类无Clone操作时，不能被原型化。
-----关联-----
Composite和Decorator模式也常用到Prototype模式
单件模式（SingleTon）
保证一个类仅有一个实例，并提供一个访问它的全局访问点
################################
只有一个实例，全局可访问
类构造函数为保护类型，不允许直接构建，但允许子类化
简单工厂模式(StaticFactory Method)
由一个工厂对象决定创建出哪一种产品类的实例。
################################
一个创建类一个创建方法
传入不同参数创建不同对象
-----关联-----
Factory Method模式将实例化那个具体类放到了工厂的子类来实现。
简单工厂新加一个类需要修改代码，而工厂方法只需要扩展一个子类。
结构模式
适配器模式（Adapter）
将一个类的接口转换成客户希望的另外一个接口。
################################
类适配-多重继承实现适配
对象适配-组合实现适配
-----关联-----
Bridge实现抽象与实现的分离可独立改变
桥接模式（Bridge）
将抽象部分与它的实现部分分离，使它们都可以独立的变化
################################
抽象和实现部分都可以独立的扩展
解决了继承机制的父子绑带关系
-----优缺点-----
分离接口及其实现部分
抽象也可扩充，提高可扩充性
-----关联-----
Abstract Factory可用于创建和配置一个特定的Bridge模式
Adapter在已有系统但要升级时使用，Bridge在系统设计的时候就使用
组合模式（Composite）
将对象组合成树形结构以表示“部分-整体”的层次结构。
################################
使组合体和单体具有同一抽象类型，从而可以统一处理
每个子部件保留父部件的显示引用有利于遍历和消息传递
共享子部件涉及FlyWeight模式以及多个父部件的定位
特别关注父子部件的引用排序遍历传递定位等
-----关联-----
父子部件连接采用Responsibility of Chain
FlyWeight模式共享子部件，但不再能引用父部件
装饰模式（Decorator）
动态的给一个对象添加一些额外的职责，就增加功能来说，装饰模式比生成子类更为灵活
################################
在不影响已有的对象的情况下动态透明的添加额外职责，需要共用一个接口
原有类集不能通过子类进行扩充时用装饰者
-----优缺点-----
被装饰的组件类的接口尽可能的简单
避免多个功能组合时可能产生的很多子类，通过每个子功能一个类，动态去组合。
-----关联-----
Decorator可以改变对象的外表，Strategy可以改变对象的内核
外观模式（Facade）
为子系统中的一组接口提供一个一致的界面。
################################
为复杂的子系统提供一个简单接口
-----优缺点-----
有利于分层系统；有利于重用旧有的代码；减少接口，降低耦合
-----关联-----
Mediator在内部同事间进行通信，Facade对外
享元模式（Flyweight）
运用共享技术有效地支持大量细粒度的对象
################################
通过一个抽象工厂来生成享元
不保存对象存引用节约内存
对象不能保存外部环境状态（通过方法处理外部状态），否则无法共享
模式可引申出引用计数和垃圾回收
-----关联-----
用Flyweight来实现State/Strategy模式
代理模式（Proxy）
为其他对象提供一种代理以控制对这个对象的访问
################################
代理在客户与实现之间提供了间接性
远程代理--为一个对象在不同地址空间提供局部代表
虚拟代理--接管对开销大的对象的操作，优化性能（如打开图片多的网站）
安全代理--控制对真实对象的访问权限
智能指引--指当调用真实的对象时，代理处理另外的一些事。如智能指针
行为模式
职责链模式(Chain of Responsibility)
使多个对象都有机会处理请求，避免请求的发送者和接收者之间的耦合关系。
################################
串起一个消息链
发请求消息的人不管谁接收，只管丢到链上，降低耦合，简化连接
链的设置分静态和动态的
请求表示为(直接用方法调用/用编码参数Code后if处理/封装成对象用getkey方法)
子类只捕获自己的消息
-----关联-----
常与Composite一块使用，父构件作为其后继
命令模式(Command)
将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化
################################
接收Command的接收者有操作相关状态信息
Command是回调函数机制的一个OO替代品
支持取消操作，只要在执行前保存原状态-与Memento合作
支持修改日志，在动作时保存修改
通过Command在原语操作上构件新的高层操作层，如DB事务处理
将调用操作的对象与知道如何实现该操作的对象解耦
命令粒度大可不要接收者，大部分要传入
解释器模式(Interpreter)
给定一个语言，定义它的文法的一种表示，并定义一个解释器使用该表示来解释语言中的句子
################################
划分为终结符表达式和非终结符表达式
递归的解析非终结符表达式
迭代器模式(Iterator)
提供一种方法顺序访问一个聚合对象中各个元素，而不需要暴露该对象内部表示。
################################
将遍历访问等操作独立于内部对象
要求对象为同类型或有共同接口
根据控制迭代的人不同分为内部迭代器和外部迭代器
中介者模式(Mediator)
用一个中介对象来封装一系列的对象交互（双向）
################################
中介者包含多个内部对象的引用
各内部对象可见且仅见中介者，降低耦合
将各成员交互的复杂性转化为中介者复杂性
成员与中介者通信：观察者模式/中介者定义接口，成员将自身作为参数传入
-----关联-----
Facade为单向且对外提供接口
Mediator为内部协同各对象交互
通信可用观察者模式
备忘录模式(Memento
在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态
################################
状态操作只对触发者可见确保封装性
观察者模式（Observer/Publish-Subscribe）
定义对象间的一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并自动更新
################################
让多个观察者对象同时监听某一个主题对象，当状态变化时自动通知所有观察者对象。
实质是为了解除耦合
创建目标到观察者的映射(直接保存观察者的引用/建立关联查找机制如hash)
同时观察多个目标(扩展Update函数传入目标自身)
谁触发更新：
状态变-自动更新-无缓冲重复操作可能效率低
状态变不更新客户手动更新-客户可能忘记更新
目标和观察者关系复杂时可以使用更改管理器
委托方式-委托可以看作对函数的抽象
进一步的抽象，用事件机制解决观察者的方法不可统一为Update名称的问题
定义一个事件委托update（EventHandler）
将具体观察者的操作绑定到事件中。
当主题者状态变更时，调用Update事件，触发操作。
-----优缺点-----
目标观察者解耦
支持广播通信
可能导致意外的Update
-----关联-----
更改管理器其实是个中介者，可用单件实现
状态模式（State）
允许一个对象在其内部状态改变时改变它的行为
################################
封装特定状态下对应的行为
谁来定义状态转换(固定的接口方法/子状态类自己确定转换)
状态机着重于状态转换/State着重于状态对应行为的抽象
-----关联-----
状态对象通常是Singleton
策略模式(Strategy)
定义一系列的算法，把它们一个个封装起来，并且使它们可相互替换。
################################
定义算法家族，分别封装起来，让它们之间可互相替换；让算法的变化，不会影响到使用算法的客户。
-----关联-----
与State结构相同
算法的创建可以结合创建模式
模版方法模式(Template Methed)
定义一个操作中算法的骨架，而将一些步骤延迟到子类中。
################################
使子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
重要的代码复用技术，在类库中尤为重要。
-----关联-----
模版方法使用继承来改变算法的一部分。Strategy使用委托来改变整个算法。
访问者模式(Visitor)
表示一个作用于某对象结构中的各元素的操作。使你可以在不改变各元素类的前提下定义作用于这些元素的新操作。
################################
给整个对象结构增加一个新方法。
要求原有的对象结构有Accept机制
在对象结构稳定，会涉及到增加操作时适用
采用了双分派的技术
-----关联-----
访问者可以用于Interpreter
看了感觉怎么样？来说说吧。。。
喜欢记得关注起来！赶紧的。
