设计原则A:找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起【封装变化】
设计原则B:针对接口编程，而不是针对实现编程
设计原则C:多用组合，少用继承
设计原则D:为了交互对象之间的松耦合设计而努力
设计原则E:类应该对扩展开放，对修改关闭
依赖倒置原则(Dependency Inversion Principle):要依赖抽象，不要依赖具体类
最少知识法则(的米特法则):只和你的密友谈话[减少对象之间的交互]
好莱坞法则:别调用(大电话)我们，我们会调用你【防止依赖太多，造成依赖腐败】
区分:依赖倒置要我们尽量避免使用具体类，多使用抽象。好莱坞法则则是用在创建框架或组件上的一种技巧，让底层组件挂进系统但由不让高层组件(接口使用者)依赖底层组件
单一责任原则:一个类应该只有一个引起变化的原因
类的每个责任都有改变的潜在区域。超过一个责任，意味着超过一个改变的区域。
1.Strategy-策略模式:定义了算法族，分别封装起来，让它们之间可以相互替换，此模式算法的变化独立于使用算法的客户
2.Visitor-观察者模式:定义对象之间的一对多依赖，这样一来，当一个对象改变状态时，它的所有依赖者都会收到通知自动更新
3.Decorator-装饰者模式:动态地将责任附加到对象上。若要扩展功能，装饰者提供了比继承更有弹性的替代方案
4.Factory Method-工厂方法模式:定义了一个创建对象的接口，但由子类决定要实例化的类是那一个。工厂方法让类的实例化推迟到子类
5.Abstract Factory-抽象工厂模式:提供一个接口，用于创建相关或依赖对象的家族，而不需要明确指定具体类
区别:工厂方法创建一个产品(一个方法接口)，抽象工厂创建一个产品相关的所有信息(多个方法接口)
6.Singleton Pattern-单例模式:确保一个类只有一个实例，并提供一个全局访问点
7.Command-命令模式:将"请求"封装成对象，以便于使用不同的请求、队列或者日志来参数化其他对象。命令模式也支持可撤销的操作
8.Adapter-适配器模式:将一个类的接口，转换成客户期望的另一个接口，适配器让原本不兼容的类可以合作无间
[适配器主要为了将一个接口转换成另一个]，对象适配器通过对象组合和继承实现，类适配则通过多继承实现
[与装饰者模式区分]装饰者不改变接口，添加责任，适配器将一个接口转换成另一个接口，外观模式让接口更简单(用户体验)
9.Facade-外观模式:提供一个统一的接口，用来访问子系统中的一群接口。外观定义了一个高层接口，让子系统更容易使用
10.Template Method-模板方法模式:在一个方法中定义一个算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以在不改变算法结构的情况下，
重新定义算法中的某些步骤【工厂方法是模板模式的一种特殊版本】
11.Iterator-迭代器模式:提供一种方法顺序访问一个聚合对象中的各个元素，而又不暴露其内部的表示
【把游走的任务放在迭代器上，而不是聚合上。这样简化了聚合的接口和实现，也让责任各得起所】
12.Composite-组合模式:允许你将对象组合成树状结构来表现"整体/部分"层次结构。组合能让客户以一致的方式处理个别对象以及对象组合
13.State-状态模式:允许对象在内部状态改变时改变它的行为，对象看起来好像修改了它的类
[大部分对象根据状态实施不同的行为,状态模式将行为封装到状态对象中,对象通过切换不同的状态对象实现行为的切换]
14.Proxy-代理模式:为另一个对象提供一个替身或占位符以控制对这个对象的访问
[使用代理模式创建代表对象,让代表对象控制对某对象的访问，被代理的对象可以是远程的对象，创建开销大的对象或需要安全控制的对象]
模式:是在某种情境下，针对某问题的某种解决方案【解决问题的一些方案，包含问题，解决方案以及该方案的名称，以及实现思路】
1.一切以简单实现为目标，不要为了模式而使用模式
2推荐《设计模式》、《the timeless way of building》、《a pattern language》、hillside.net
反模式:告诉你如何采用一个不好的解决方案解决一个问题
3.Bridge-桥接模式、Builder-生成器模式、Chain of Responsibility-责任链、Flyweight-蝇量模式、
Interpreter-解释器模式、Mediator-中介者模式、Memento-备忘录模式、Prototype-原型模式、Visitor-访问者
转载于:https://my.oschina.net/686991/blog/537552
3278
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
