设计模式-读书笔记-on Head First Design Pattern

冷不防 2021-11-17 12:50 241阅读 0赞

**1，策略模式(Strategy Pattern)**

> 设计原则：
> 
>  *  找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起。
>  *  针对接口编程，而不是针对实现编程。
> 
> 这些设计原则使得对象之间的扩展和修改非常灵活，代码复用率高。  
> 定义：

> > 策略模式定义了算法族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化独立于使用算法的客户。

**2，观察者模式 (Observer Pattern)**

> 定义：

> > 观察者模式定义了对象之间的一对多依赖，这样一来，当一个对象改变状态时，它所有依赖者都会受到通知并自动更新。
> > 
> > 这个是在JAVA API中有内置支持的
> 
> 范例：QQ群和QQ用户就很好地说明了这一关系；

> > 还有报纸发行社，和报纸订阅用户之间也可以描述为这一模式；
> 
> > 邮件列表
> 
> > Java API，Swing JButton，Button的点击，会触发一些列ActionListener进行相应的相应。
> 
> 设计原则：

>  *  为了交互对象之间的松耦合设计而努力，两个对象之间松耦合，他们依然可以交互，但是不太清楚彼此的细节。观察者和主题之间就是这种关系。
>  *  松耦合的设计之所以能让我们建立有弹性的OO系统，能够应对变化，是因为对象之间的互相依赖性降到了最低。

**3****，装饰者模式（****Decorator Pattern****）**

> 定义：
> 
> 装饰着模式动态地将责任附加到对象上。若要扩展功能，装饰着提供了比继承更有弹性的替代方案。
> 
> 设计原则：
> 
> ·         类应该对扩展开发，对修改关闭。
> 
> o    我们的目标是允许类容易扩展，在不修改现有代码的情况下，就可搭配新的行为。如能实现这样的目标，有什么好处呢？这样的设计具有弹性可以应对改变，可以接受新的功能来应对改变的需求。
> 
> o    在选择需要被扩展的代码部分时需要小心。每个地方都采用开发\-关闭原则，是一种浪费，也没必要，还会导致代码变得复杂难以理解
> 
> ·         通过委托的方式将对象的行为委托给另一个包装的对象，有点像一个递归的过程，根据包装的层级关系，从外向内调用，从内向外返回。
> 
> 范例：
> 
> ·         Java API中的I/O类的结构设计都遵循了装饰着模式的设计规范，例如BufferedInputStream包装了FileInputStream，而LineNumberInputStream又包装了BufferedInputStream，FileInputStream如同StringBufferInputStream、ByteArrayInputStream一样都提供了最基本的字节读取能力,而这些这三个类又共同继承了一个超类InputStream。输出流的设计也是类似的
> 
>   
>

**4，工厂方法模式 （Factory Method Pattern）**

> 定义：

> > 工厂方法模式定义了一个创建对象的借口，但由子类决定要实例化的类是哪一个。工厂方法让类把实例化推迟到子类。从实现中解耦合。
> 
> 简单工厂和工厂模式：

>  *  简单工厂把全部的事情在一个地方都处理完了，然后工厂方法却是创建一个框架，让子类决定要如何实现。
>  *  简单工厂的做法，可以将对象的创建封装起来，但是简单工厂不具备工厂方法的弹性，因为简单工厂不能变更正在创建的产品。

> 设计原则：

>  *  将创建对象的代码集中在一个对象或方法中，可以避免代码中的重复，并且方便以后的维护。这也意味着客户在实例化对象时，只会依赖于接口，而不是具体类。我们在学习中发现，这可以帮助我针对接口编程，而不是针对实现编程。这让代码更具有弹性，可应对未来的扩展。
>  *  依赖倒置原则（Dependency Inversion Principle）：要依赖抽象，不要依赖具体类。

> 抽象工厂方法：提供了一个接口，用于创建相关或依赖对象的家族，而不需要明确指出具体类。而每一个产品的创建都依赖工厂方法来创建。

**5，单件模式（Singleton Pattern）**

> 定义：确保一个类只有一个实例，并提供全局访问点。
> 
> 设计原则：
> 
>  *  单件模式确保程序在一个类最多只有一个实例
>  *  单件模式也提供访问这个实例的全局点。
>  *  在Java中实现单件模式需要似有的构造器、一个静态方法和一个静态变量。
>  *  确定在性能和资源上的限制，然后小心地选择适当的方案来实现单件，以解决多线程问题（我们必须认定所有的程序都是多线程的）
>  *  如果不是采用第五版的Java 2，双重检查加锁实现会失效。
>  *  如果使用多个类加载器，可能会导致单件失效而产生多个实例。
>  *  如果使用JVM 1.2或之前的版本，你必须建立单件注册表，以免垃圾收集器将单件回收。
> 
> 类图：
> 
> 1，最简单的实现（不是多线程安全的）
> 
> public class Singleton\{

> > private static Singleton sl;
> > 
> > private Singleton()\{\}
> > 
> > public static Singleton getInstance()\{

> > > if(sl==null)

> > > > return new Singleton();
> > > 
> > > else

> > > > return sl;

> > \}

> \}
> 
> 2，可以保证多线程安全的方法（不过这个方法在有许多线程实例时，效率并不高，因为一旦一个线程调用getInstance，其它线程就得必须等待，即便sl已经被实例化了也是这样，这样效率会比较低）
> 
> > public class Singleton\{ 
> 
> > > private static Singleton sl;
> > > 
> > > private Singleton()\{\}
> > > 
> > > public static synchronized Singleton getInstance()\{ 
> 
> > > > if(sl==null)
> 
> > > > > return new Singleton();
> > > > 
> > > > else
> 
> > > > > return sl;
> 
> > > \}
> 
> > \}
> 
> 3，使用“急切”实例化（这个不能将类的实例延迟到运行时）
> 
> > public class Singleton\{ 
> 
> > > private static Singleton sl=new Singleton();
> > > 
> > > private Singleton()\{\}
> > > 
> > > public static Singleton getInstance()\{ 
> 
> > > > return sl;
> 
> > > \}
> 
> > \}
> 
> 4,使用Java中的双重加锁来提高线程访问效率（只在Java 5之后的版本才支持，这个方法的优点在于一旦实例被创建，后面多线程访问的效率就会很高，线程就不会独占getInstance()方法了。）
> 
> > public class Singleton\{ 
> 
> > > private volatile static Singleton sl;
> > > 
> > > private Singleton()\{\}
> > > 
> > > public static Singleton getInstance()\{ 
> 
> > > > if(sl==null)\{

> > > > > synchronized(Singleton.class)\{

> > > > > > if(sl== null)\{  //这步判断是非常必要的，如果没有这步就不是多线程安全的了

> > > > > > > sl=new Singleton();

> > > > > > \}

> > > > > \}

> > > > \}
> 
> > > > return sl;
> 
> > > \}
> 
> > \}

转载于:https://www.cnblogs.com/kevinLee-xjtu/archive/2011/11/29/2299108.html