对修改是封闭的，对扩展是开放的。
新需求对于已上线的系统是司空见惯的，最佳实践告诉我们对生产中的代码在扩展功能时不要直接修改，而是去重写一个新的方法，新类型或新服务去扩展它，这道理很简单，任何即有代码的变更，都可能带来灾难。（除非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);
}
所以设计模式遵循程序设计原则，反过来，又能帮我们更好的实现原则的思想，从而保障生产系统的安全稳定。
