对修改是封闭的，对扩展是开放的。

新需求对于已上线的系统是司空见惯的，最佳实践告诉我们对生产中的代码在扩展功能时不要直接修改，而是去重写一个新的方法，新类型或新服务去扩展它，这道理很简单，任何即有代码的变更，都可能带来灾难。（除非100%把握，或有100%把握的胆子，当然也有一个工种，测试能帮我们来挡刀）

常见的扩展方式都有什么呢？

新建方式：

对于一些独立的新需求，可能通过增加一个方法，就能实现；有时这个需求相对较大，那估计通过添加一些类型，就能实现，这是coder们最愿意看见的。比如你有个计算器，原来只有加法减，新需求是增加乘除，那就直接添加两个方法就ok了。

多态方式：

对于有复杂的扩展需求场景，就需要通过OOP特性来解决了，但前提条件是原来的实现就OOP方式来实现的，比如，想重写一个方法，首先这个方法得是虚方法或抽象方法，方便子类去重写；当然，有时重载也能起到扩展的作用。继续看例子吧，用户的新需求是原来的计算器加减法参数只有是整型，现在要支持小数类型的参数；一种方法是用重载，保留整型相加减，增加两个同名的方法，参数是小数类型，还 一种方法，继承这个计算器类，重写原来的加减法，这样达到了对原来的整型加减不修改，又增加了新的小数类型的加减，不同点在于调用的时候，重载是用原来的类型，重写是实例化新类型来调用小数参数加减。

设计模式方式：

为了更好的“对修改是封闭的，对扩展是开放的”，把设计模式引进到系统中，能帮我们很大的忙。

比如常见的简单工厂模式，可以很方便的通过“产品的类型”来扩展“车间生产线”；

    /// <summary>/// 工厂方法/// </summary>public class ProductionFactory{public static ProductionLine CreateProductionLine(int productionNo){ProductionLine productionLine = null;switch (productionNo){case 1:productionLine = new ProductionLineOnew();break;case 2:productionLine= new ProductionLineTow();break;}return ProductionLine ;}}

再比如职责链模式，可以很容易帮我们增加一种职责；例子中一次住院登记，要完成医保登记，健康平台登记，本地His登记本个操作，如果增加登记需求，可以很方便在这里扩展，而不影响原来的各种登记业务。

        static void Register(ClinicRegisterEntity clinicRegisterEntity){//医保登记var clinicRegister = new MedicalRegister();//健康平台登记var healthPlatformRegister = new HealthPlatformRegister();//本地his挂号，要么简易挂号，要么普通挂号var simpleRegister = new SimpleClinicRegister();//设置顺序，1、医保，2、健康平台 3、（简易或普通）挂号clinicRegister.Next(healthPlatformRegister);healthPlatformRegister.Next(simpleRegister);clinicRegister.Register(clinicRegisterEntity);}

所以设计模式遵循程序设计原则，反过来，又能帮我们更好的实现原则的思想，从而保障生产系统的安全稳定。