今题那站在这里和大家一起分享最近在一本书上看到的关于设计模式的内容,接下来要讲的设计模式有:
- 单例模式
- 简单工厂模式
- 工厂方法和抽象工厂
- 代理模式
- 命令模式
- 策略模式
- 门面模式
- 桥接模式
- 观察者模式
接下来详细介绍灭一种设计模式(注意:下面的讲解都是基于java语言)
1.单例模式
定义:Java中单例模式定义:“一个类有且仅有一个实例,并且自行实例化向整个系统提供。”
java单例模式代码片段:
public class SingletonClass{
private static SingletonClass instance=null;
public static SingletonClass getInstance(){
if(instance==null){
synchronized(SingletonClass.class){
if(instance==null){
instance=new SingletonClass();
}
}
}
return instance;
}
private SingletonClass(){}
}
为什么需要单例模式?
- 对于系统中的某些类来说,只有一个实例很重要,例如,一个系统中可以存在多个打印任务,但是只能有一个正在工作的任务;一个系统只能有一个窗口管理器或文件系统;一个系统只能有一个计时工具或ID(序号)生成器。如在Windows中就只能打开一个任务管理器。如果不使用机制对窗口对象进行唯一化,将弹出多个窗口,如果这些窗口显示的内容完全一致,则是重复对象,浪费内存资源;如果这些窗口显示的内容不一致,则意味着在某一瞬间系统有多个状态,与实际不符,也会给用户带来误解,不知道哪一个才是真实的状态。因此有时确保系统中某个对象的唯一性即一个类只能有一个实例非常重要
- 如何保证一个类只有一个实例并且这个实例易于被访问呢?定义一个全局变量可以确保对象随时都可以被访问,但不能防止我们实例化多个对象。一个更好的解决办法是让类自身负责保存它的唯一实例。这个类可以保证没有其他实例被创建,并且它可以提供一个访问该实例的方法。这就是单例模式的模式动机
单例模式的要点
- 显然单例模式的要点有三个;一是某个类只能有一个实例;二是它必须自行创建这个实例;三是它必须自行向整个系统提供这个实例。
设计单例模式通常有三种形式:
第一种:懒汉模式(常用的)
public class SingletonClass{
private static SingletonClass instance=null;
public static synchronized SingletonClass getInstance()
{
if(instance==null)
{
instance=new SingletonClass();
}
return instance;
}
private SingletonClass(){
}
}
第二种:饿汉式
//对第一行static的一些解释
// java允许我们在一个类里面定义静态类。比如内部类(nested class)。
//把nested class封闭起来的类叫外部类。
//在java中,我们不能用static修饰顶级类(top level class)。
//只有内部类可以为static。
public class Singleton{
//在自己内部定义自己的一个实例,只供内部调用
private static final Singleton instance = new Singleton();
private Singleton(){
//do something
}
//这里提供了一个供外部访问本class的静态方法,可以直接访问
public static Singleton getInstance(){
return instance;
}
}
第三种:
public class Singleton{
private static Singleton instance=null;
private Singleton(){
//do something
}
public static synchronized Singleton getInstance(){
if(instance==null){
synchronized(Singleton.class){
if(instance==null) {
instance=new Singleton();
}
}
}
return instance;
}
}内容下方到if内部,提高了执行的效率,不必每次获取对象时都进行同步,只有第一次才同步,创建了以后就没必要了
2.简单工厂模式
为什么会有简单工厂模式?
- 对于java应用而言,应用之中各实例之间存在复杂的调用关系。当A对象需要调用B对象的方法时,许多人会选择new一个B对象实例,然后通过B对象实例调用相应的方法。这种做法的坏处在于:A类的方法实现直接调用了B类的类名(这种方式也被称为硬编码耦合),一旦系统需要重构:需啊哟使用C类来代替B类的时候,程序不得不更改A类代码。
- 为了解决需要重写A类代码的问题,我们需要重新定义一个工厂类BFactory,专门用来创建B对象实例,而A类只需要调用BFactory工厂的方法来得到B对象实例
简单工厂模式深入分析:
- 简单工厂模式解决的问题是如何去实例化一个合适的对象。
- 简单工厂模式的核心思想就是:有一个专门的类来负责创建实例的过程。
- 具体来说,把产品看着是一系列的类的集合,这些类是由某个抽象类或者接口派生出来的一个对象树。而工厂类用来产生一个合适的对象来满足客户的要求。
- 如果简单工厂模式所涉及到的具体产品之间没有共同的逻辑,那么我们就可以使用接口来扮演抽象产品的角色;如果具体产品之间有功能的逻辑或,我们就必须把这些共同的东西提取出来,放在一个抽象类中,然后让具体产品继承抽象类。为实现更好复用的目的,共同的东西总是应该抽象出来的。
在实际的的使用中,抽闲产品和具体产品之间往往是多层次的产品结构,如下图所示:
简单工厂模式使用场景分析及代码实现:
GG请自己的女朋友和众多美女吃饭,但是GG自己是不会做饭的或者做的饭很不好,这说明GG不用自己去创建各种食物的对象;各个美女都有各自的爱好,到麦当劳后她们喜欢吃什么直接去点就行了,麦当劳就是生产各种食物的工厂,这时候GG不用自己动手,也可以请这么多美女吃饭,所要做的就是买单O(∩_∩)O哈哈~,其UML图如下所示:
产品的抽象接口
/*
1. 产品的抽象接口
*/
public interface Food {
/*
* 获得相应的食物
*/
public void get();
}
麦香鸡对抽象产品接口的实现
/*
2. 麦香鸡对抽象产品接口的实现
*/
public class McChicken implements Food{
/*
* 获取一份麦香鸡
*/
public void get(){
System.out.println("我要一份麦香鸡");
}
}
薯条对抽象产品接口的实现
/*
3. 薯条对抽象产品接口的实现
*/
public class Chips implements Food{
/*
* 获取一份薯条
*/
public void get(){
System.out.println("我要一份薯条");
}
}
现在建立一个食物加工工厂:
public class FoodFactory {
public static Food getFood(String type) throws InstantiationException, IllegalAccessException, ClassNotFoundException {
if(type.equalsIgnoreCase("mcchicken")) {
return McChicken.class.newInstance();
} else if(type.equalsIgnoreCase("chips")) {
return Chips.class.newInstance();
} else {
System.out.println("哎呀!找不到相应的实例化类啦!");
return null;
}
}
}
简单工厂模式的优缺点分析:
优点:
- 工厂类是整个模式的关键所在。它包含必要的判断逻辑,能够根据外界给定的信息,决定究竟应该创建哪个具体类的对象。用户在使用时可以直接根据工厂类去创建所需的实例,而无需了解这些对象是如何创建以及如何组织的。有利于整个软件体系结构的优化。
缺点:
- 由于工厂类集中了所有实例的创建逻辑,这就直接导致一旦这个工厂出了问题,所有的客户端都会受到牵连;而且由于简单工厂模式的产品室基于一个共同的抽象类或者接口,这样一来,但产品的种类增加的时候,即有不同的产品接口或者抽象类的时候,工厂类就需要判断何时创建何种种类的产品,这就和创建何种种类产品的产品相互混淆在了一起,违背了单一职责,导致系统丧失灵活性和可维护性。而且更重要的是,简单工厂模式违背了“开放封闭原则”,就是违背了“系统对扩展开放,对修改关闭”的原则,因为当我新增加一个产品的时候必须修改工厂类,相应的工厂类就需要重新编译一遍。
总结一下:简单工厂模式分离产品的创建者和消费者,有利于软件系统结构的优化;但是由于一切逻辑都集中在一个工厂类中,导致了没有很高的内聚性,同时也违背了“开放封闭原则”。另外,简单工厂模式的方法一般都是静态的,而静态工厂方法是无法让子类继承的,因此,简单工厂模式无法形成基于基类的继承树结构。