首页 > 代码库 > 设计模式学习笔记
设计模式学习笔记
1.编程一个原则：用尽可能的办法去避免重复；
2.只要在分析的过程中听到需要在不同时间应用不同的业务规则，就可以考虑使用策略模式处理这种变化的可能性；
策略模式：将不同的处理办法封装成具体的类，然后抽象一个上层的类，再建立一个方法类，此类中包含一个抽象类的对象，在方法类初始化的时候对抽象类对象进行初始化，在方法类中一个方法中通过传入不同的参数实例化不同的类型，这样就能返回不同的计算结果了，这样的好处是在客户端类中只会看到这个方法类，不会涉及到具体的计算类，实现了很好的分离，降低了耦合；
3.类设计要遵守单一职责原则，就一个类而言，应该仅有一个引起它变化的原因；
4.开放－封闭原则：面对需求，对程序的改动是通过增加代码进行的，而不是更改现有的代码，这是此原则的精神所在；
5.依赖倒转原则：
- 高层模块不应该依赖底层模块。两个都应该依赖抽象；
- 抽象不应该依赖细节。细节应该依赖抽象；
依赖转存其实可以说是面向对象设计的标志，用哪种语言来编写程序不重要，如果编写时考虑的都是如何针对抽象编程而不是针对细节编程，即程序中所有的依赖关系都是终止于抽象类或者接口，那就是面向对象的设计，反之那就是过程化的设计了。
6.代理模式：为其他对象提供一种代理以控制对这个对象的访问；
7.简单工厂模式：将实例化放在工厂中，减少了与客户端代码的耦合性；
8.工厂模式：将工厂类再抽象出一个接口，这样做的好处是再增加类型的时候不用修改简单工厂模式中的工厂，直接增加一个工厂类就可以了，这样就遵守了开放-封闭原则；
9.原型模式：用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象；
10.模板方法模式：定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤；
11.外观模式：为子系统中的一组接口提供一个一致的界面，此模式定义了一个高层接口，这个接口使得这一子系统更加容易使用；
12.建造者模式：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示；
13.观察者模式：定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态发生变化时，会通知所有观察者对象，使它们能够自动更新自己；
事件委托：委托方式可以解决观察者模式中的不足之处，因为观察者模式中可能对象的相应事件可能是不同的，这样在主题对象中就没有没有必要保存观察者对象数组了，在主题对象中放置一个委托对象，然后为委托对象分别注册不同的相应方法，这样在通知的时候调用委托对象就能分别依次调用不同对象的特定方法了，完成了不同对象对同一事件的同时响应；
14.状态模式：当一个对象的内在状态改变时允许改变其行为，这个对象看起来像是改变了其类；
状态模式主要解决的是当控制一个对象状态转换的条件表达式过于复杂的情况，把状态的判断逻辑转移到表示不同状态的一系列类当中，可以把复杂的判断逻辑简化；
考虑状态模式的时候：当一个对象的行为取决于它的状态，并且它必须在运行时刻根据状态改变它的行为时，就可以考虑使用状态模式了；
15.适配器模式：将一个类的接口转换成客户希望的另外一个接口，适配器模式使得原来由于接口不兼容而不能一起工作的那些类可以一起工作，但是不能经常的事情，在项目初期的时候还是尽量做到接口的统一，只要在真的需要的时候才使用这种模式；
16.备忘录模式：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，这样以后就可将该对象恢复到原先保存的状态；这样做的好处就是将需要保存的状态的细节封装在一个另外的类中，这样在需要修改保存状态信息的时候就不会破坏客户端代码了，封闭了实现的细节；
17.组合模式：将对象组合成树形结构以表示“部分-整体”的层次结构，组合模式使得用户对单个对象和组合对象的使用具有一致性；
当发现需求中是体现部分与整体层次的结构时，以及希望用户可以忽略组合对象与单个对象的不同，统一地使用组合结构中的所有对象时，就应该考虑用组合模式了，例如公司与分公司还有下属部分的关系；
18.单例模式：保证一个类仅有一个实例，并提供一个访问它的全局访问点，在类中声明一个静态类型的此变量，然后声明一个静态访问用于访问这个实例变量，从而判断此变量是否被定义过而判断是否要新定义一个变量，但是要将构造函数声明为private以防止外部创建对象；
饿汉式单例化是在类被加载的时候就创建了静态实例；
懒汉式单例化是在第一次被应用时才初始化，但是在多线程应用中得建立双重锁定处理才能保证安全；
19.合成/聚合复用原则：尽量使用合成/聚合，尽量不要使用类继承，类继承会造成子类和父类的高度耦合，限制了灵活性和复用性；
在使用继承的时候，一定要在是is-a的关系时再考虑使用；
桥接模式：实现系统可能有多角度的分类，每一种分类都有可能变化，那么就把这些多角度分离出来让它们独立变化，减少它们之间的耦合；例如手机品牌和手机软件，可以分开进行是实现，然后通过手机中有软件的方式进行聚合操作形成不同的手机，这样在增加手机品牌或者软件功能的时候只是添加类，而不会破坏之前的类结构，这样就很好的保证了开放-封闭原则；
20.命令模式：将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化，对请求排队或者记录请求日志，以及支持可撤销的操作；
21.职责链模式：使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系，将这个对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止；例如请假申请，每一个具体的审核者设置一个上级，这样只要把请求传递到经理级别，以后有谁处理就不用关心了，最后得到结果就可以，而且还能灵活的更换级别之间的关系，这样就解决了在一个类中大量的分支判断造成难维护、灵活性差的问题；
22.中介者模式：用一个中介对象来封装一系列的对象交互，中介者使各对象不需要显示地相互作用，从而使其耦合松散，而且可以独立地改变它们之间的交互，例如联合国处理伊拉克和美国之间问题，不需要两个国家直接进行交流，通过联合国这个中介者进行交流即可，减少了耦合度；
23.享元模式：运用共享技术有效地支持大量细粒度的对象；
应用的场景：如果一个应用程序使用了大量的对象，而大量的这些对象造成了很大的存储开销时就应该考虑使用；还有就是对象的大多数状态可以是外部状态，如果删除对象的外部状态，那么可以用相对较少的共享对象取代很多组对象，此时可以考虑使用享元模式；但是同时此模式也增加了代码的复杂度，所以如果不是非常多对象的时候没有必要使用，例如围棋游戏就适合使用这类对象，因为一局游戏需要300多个对象，但是实际上棋子就是黑色和白色的，那么这些就是内部状态，而棋子的位置就是外部状态了，用这种模式就可以只生成2个对象，然后利用外部状态完成游戏，这样就大大减少了内存的开销；
设计模式学习笔记
声明：以上内容来自用户投稿及互联网公开渠道收集整理发布，本网站不拥有所有权，未作人工编辑处理，也不承担相关法律责任，若内容有误或涉及侵权可进行投诉： 投诉/举报 工作人员会在5个工作日内联系你，一经查实，本站将立刻删除涉嫌侵权内容。