几种软件设计模式简述以及示例

本文介绍了软件设计模式中的工厂模式、抽象工厂模式、适配器模式、装饰器模式、代理模式、迭代器模式、备忘录模式、观察者模式、状态模式、策略模式和模板模式,阐述了每种模式的核心思想、优缺点及适用场景,帮助开发者更好地理解和运用这些设计模式。
摘要由CSDN通过智能技术生成

工厂模式(Factory Pattern)
定义一个创建对象的接口,让其子类自己决定实例化哪一个工厂类,工厂模式使其创建过程延迟到子类进行。创建过程在其子类执行。
优点: 1、一个调用者想创建一个对象,要知道其名称。 2、扩展性高,如果想增加一个产品,只要扩展一个工厂类就可以。 3、屏蔽产品的具体实现,调用者只关心产品的接口,对内部实现产生保护,提升安全性。
缺点:每次增加一个产品时,都需要增加一个具体类和对象实现工厂,使得系统中类的个数成倍增加,在一定程度上增加了系统的复杂度,同时也增加了系统具体类的依赖。这并不是什么好事。

抽象工厂模式(Abstract Factory Pattern)
提供一个创建一系列相关或相互依赖对象的接口,而无需指定它们具体的类。在一个工厂里聚合多个同类产品。
优点:当一个产品族中的多个对象被设计成一起工作时,它能保证客户端始终只使用同一个产品族中的对象。
缺点:产品族扩展非常困难,要增加一个系列的某一产品,既要在抽象的 Creator 里加代码,又要在具体的里面加代码。
示例

public interface Shape {
   
   void draw();
}

public class Rectangle implements Shape {
   
 
   @Override
   public void draw() {
   
      System.out.println("Inside Rectangle::draw() method.");
   }
}

public class Square implements Shape {
   
 
   @Override
   public void draw() {
   
      System.out.println("Inside Square::draw() method.");
   }
}

public class Circle implements Shape {
   
 
   @Override
   public void draw() {
   
      System.out.println("Inside Circle::draw() method.");
   }
}

public interface Color {
   
   void fill();
}

public class Red implements Color {
   
 
   @Override
   public void fill() {
   
      System.out.println("Inside Red::fill() method.");
   }
}

public class Green implements Color {
   
 
   @Override
   public void fill() {
   
      System.out.println("Inside Green::fill() method.");
   }
}

public abstract class AbstractFactory {
   
   public abstract Color getColor(String color);
   public abstract Shape getShape(String shape) ;
}

public class ShapeFactory extends AbstractFactory {
   
    
   @Override
   public Shape getShape(String shapeType){
   
      if(shapeType == null){
   
         return null;
      }        
      if(shapeType.equalsIgnoreCase("CIRCLE")){
   
         return new Circle();
      } else if(shapeType.equalsIgnoreCase("RECTANGLE")){
   
         return new Rectangle();
      } else if(shapeType.equalsIgnoreCase("SQUARE")){
   
         return new Square();
      }
      return null;
   }
   
   @Override
   public Color getColor(String color) {
   
      return null;
   }
}


public class ColorFactory extends AbstractFactory {
   
    
   @Override
   public Shape getShape(String shapeType){
   
      return null;
   }
   
   @Override
   public Color getColor(String color) {
   
      if(color == null){
   
         return null;
      }        
      if(color.equalsIgnoreCase("RED")){
   
         return new 
/* * 原始需求背景: * 网宿CDN要按月收取客户的服务费用,根据流量的大小、 * 服务的类型等,收取不同的费用,收费规则如下: * web应用:1000元/M * 流媒体应用:1000元/M*0.7 * 下载应用:1000元/M*0.5 * 月末打印报表时,要罗列每个用户每个频道的费用、客户总费用, * 还要打印该客户的重要性指数,重要性指数=网页流/100+下载流量/600; * * 需求变更场景: * 系统已经开发出来了,接下来,运维部门现在希望对系统做一点修改, * 首先,他们希望能够输出xml,这样可以被其它系统读取和处理,但是, * 这段代码根本不可能在输出xml的代码中复用report()的任何行为,唯一 * 可以做的就是重写一个xmlReport(),大量重复report()中的行为,当然, * 现在这个修改还不费劲,拷贝一份report()直接修改就是了。 * 不久,成本中心又要求修改计费规则,于是我们必须同时修改xmlReport() * 和report(),并确保其一致性,当后续还要修改的时候,复制-黏贴的问题就 * 浮现出来了,这造成了潜在的威胁。 * 再后来,客服部门希望修改服务类型和用户重要性指数的计算规则, * 但还没决定怎么改,他们设想了几种方案,这些方案会影响用户的计费规则, * 程序必须再次同时修改xmlReport()和report(),随着各种规则变得越来越复杂, * 适当的修改点越 来越难找,不犯错误的机会越来越少。 * 现在,我们运用所学的OO原则和方法开始进行改写吧。 */
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值