有哪个网站有免费视频素材,做机械设备销售的那个网站好,恩施做网站的公司,建立企业网站选什么好“你这个人怎么这么轴#xff1f;让你改改以前的代码怎么和要了你命似的#xff1f;难道你的能力仅限于此吗#xff1f;” “你懂什么#xff1f;我有我的原则#xff01;我有我的信仰#xff01;” 一言
开闭原则即#xff1a;对扩展开放#xff0c;对修改关闭#… “你这个人怎么这么轴让你改改以前的代码怎么和要了你命似的难道你的能力仅限于此吗” “你懂什么我有我的原则我有我的信仰” 一言
开闭原则即对扩展开放对修改关闭它是所有设计的核心。 概述
大家潜意识里普遍遵循的原则往往是最关键、最重要的原则。法律或许偶有狂徒触碰但雷池从不放走一个活人。 科幻小说《三体》中有这样一个桥段面壁者比尔·希恩斯为了“坚定”地球人抵抗三体人侵略的决心发明了可以改变人类潜意识的机器并取名思想钢印。甚至当在机器中输入“水是有毒的”这样的理论也可以灌注到人类的基本意志中比尔希尔斯本人也险些因此拒绝喝水脱水而亡。 小说的描述颇具浪漫主义气质事实上开闭原则就是软件设计中难以推翻的“思想钢印”。 如果单说开闭原则或许有些同学会一时发懵不知道是在说什么。但如果换种通俗的说法之前的需求要你实现了30个工具方法随着项目的丰满这30个工具方法在各个实现中调用了差不多100次。现在有个狼人过来悄咪咪告诉你“兄弟这30个工具方法你把实现细节全改一改我有大用” 你会有什么反应 相信大多数同学都能心领神会的口径一致“GUN” “呀还会说英文呢” “拼音或者英文都可以表达我的态度具体看你理解” 狼人不理解了为什么这么大反应其实广大程序员这种刻在骨子里的反应就是开闭原则的思想钢印大多数人潜意识里都在恪守。 何为开闭原则
一个软件实体模块和函数应该对扩展开放对修改关闭。用抽象构建框架用实现扩展细节。当软件需要变化时尽量通过扩展软件实体的行为来实现变化而不是通过修改已有的代码来实现优化。
对扩展开放 对提供功能的一方扩展开放可以添加功能或类对修改关闭 对使用方而言修改是关闭的比如新增了一个类不会修改之前使用方的代码/功能 三寸反骨
碰了璧的狼人黑夜化身反骨仔挑灯加班决定突破开闭原则的思想钢印在不遵守开闭原则的前提下写了一段代码。 需求很简单实现一个画图形的工具类。 反例代码
public class Graph {class Editor{public void draw(Shape shape){if (shape.type1)drawCircle(shape);else if (shape.type2)drawBlock(shape);}public void drawCircle(Shape shape){System.out.println(绘制圆形具体实现);}public void drawBlock(Shape shape){System.out.println(绘制方形具体实现);}}class Shape{int type;}class Circle extends Shape{Circle(){super.type 1;}}class Block extends Shape{Block(){super.type 2;}}
}反骨仔开始志得意满这也太简单了丝毫没有压力啊。于是此方法投入使用了半年借助这个工具类同事们搭建了一个又一个“完美且稳定”的系统牵扯调用三百多次。 然后好消息来了绘图工具需求增加要求在原有基础上支持对三角形、平行四边形、梯形、五角星、六芒星、小波浪、大波浪等等一百二十多个图形的绘制。 反骨仔凌乱了因为他的绘制方法实现要做大量修改姑且不论同事们调用这个方法高达三百余处现在底层方法修改了上下文逻辑是不是都需要再推敲回归测试的工作量有多少。这一些列操作下来的成本又由谁来承担 所以说雷池就是雷池轻易不要头铁开闭原则能被广大同学在潜意识中遵守一定有他的道理。在软件开发的过程中也许我不比所有人聪明但是我一定要是最稳的那个。 优化设计
打开时光机反骨仔脱胎换骨回到了半年前那个倔强的夜晚默默捧起了《程序员的自我修养》开始遵循OCP原则对那个“简单的需求”进行设计。 优化代码
public class Ocp {public static void main(String[] args) {//使用看看存在的问题GraphEditor graphEditor new GraphEditor();graphEditor.drawShape(new Block());graphEditor.drawShape(new Circle());graphEditor.drawShape(new Star());}
}//绘图类
class GraphEditor{//接收Shape对象根据type绘制不同图形public void drawShape(Shape s){s.draw();}
}//图形基类
abstract class Shape{public abstract void draw();//抽象方法
}//矩形类
class Block extends Shape{Overridepublic void draw() {System.out.println(绘制方块);}
}//圆形类
class Circle extends Shape{Overridepublic void draw() {System.out.println(绘制圆形);}
}//圆形类
class Star extends Shape{Overridepublic void draw() {System.out.println(绘制五角星);}
}把创建Shape类做成抽象类并提供一个抽象的draw方法让子类实现即可这样我们有新的图形种类时只需要新的图形类继承Shape,并实现draw方法即可使用的代码就不需要修改这就满足了OCP原则。 果然命运的齿轮在半年后再一次转到了曾经的至暗时刻海量的图形扩展需求蜂拥而至而此时的那个少年成竹在胸微微一笑说到 “大家放心已经在用的方法不会有任何变更。扩展的问题交给我相关模块的回归测试理论上可以不用做当然具体的施行还是看各部门的落地要求。” 结
开闭原则是所有设计的核心更是所有优雅扩展的集中表现形式。从广义上讲它其实是在寻求一种变中求不变的平衡。开闭原则并不是拒绝需求的扩张相反它恰恰是为了以最小代价满足需求扩张而形成的捷径。从另一个角度看它恰恰印证了软件开发生命周期中设计阶段的重要性。 在上文的论述中为了更好的表述OCP原则我们一直尝试着从正向解决问题。其实我们忽略了一个角度“反骨仔”遇到的难题一方面是由于他没有遵循OCP原则那么其他同事有没有问题呢一个工具类牵扯到几百个模块的调用是否真的合理呢 这里其实就又牵出了耦合度的问题当然这是另外一个话题了。 笔者认为软件设计的本质之一在于对耦合关系的优化处理通常我们讲“高内聚、低耦合”的系统架构是值得学习和借鉴的比如springframework中的IOC理论就极大的降低了体系内的耦合度。 那么在软件设计中是否有一个原则描述了耦合关系呢 有的那就是是 迪米特法则 下篇博客我们再展开聊聊耦合处理的二三事。 关注我共同进步每周至少一更。——Wayne
