云时代架构”经典文章阅读感想十一
（谈谈架构层级的“开闭原则”）
在上学期的设计模式学习中，我学到了六大设计原则，开闭原则便是这六个设计原则之一。在类的层级，开闭原则（the-Open-Closed-Principle，简称OCP原则）的含义是：一个类对扩展是“开”放的，而对变更是封“闭”的，意思是说，应该在不改变类的前提下扩展一个类的行为。而通常的方式是继承和多态。
针对与软件质量属性中的可测试性就是应该遵循开闭原则、高内聚、低耦合。
在设计模式中有六大设计原则之开闭原则
单一职责原则告诉我们实现类要职责单一；
里氏替换原则告诉我们不要破坏继承关系；
依赖倒置原则告诉我们要面向接口编程；
接口隔离原则告诉我们在设计接口的时候要精简单一；
迪米特法则告诉我们要降低耦合
开闭原则告诉我们要对扩展开发，对修改关闭；
定义：一个软件实体。如类/模块/函都应该对扩展开放，对修改关闭。
问题由来：在软件的生命周期内，因为变化，升级和维护等原因需要对软件原有代码进行修改，可能会给旧代码引入错误，也有可能会使我们不得不对整个功能进行重构，并且需要原有代码经过重新测试。
开闭原则是面向对象设计中最基础的设计原则，它指导我们如何建立稳定灵活的系统，开闭原则只定义了对修改关闭，对扩展开放。其实只要遵循前面5种设计模式，设计出来的软件就是符合开闭原则的。
用抽象构建架构，用实现扩展细节。因为抽象灵活性好，适应性广，只要抽象的合理，可以基本保证架构的稳定。而软件中易变的细节，我们用从抽象派生的实现类来进行扩展，当软件需要发生变化时，我们只需要根据需求重新派生一个实现类来扩展就可以了，当然前提是抽象要合理，要对需求的变更有前瞻性和预见性。
总结：
1、事件驱动系统给了我们很好的机会来在架构层级应用开闭原则。我们可以重用已有的代码，并且在未知的方向上实现功能的扩展。
2、然而，需要谨慎的设计事件的内容，同时警惕糟糕的设计可能引入的耦合的可能性。
3、要根据系统的目标来指导架构设计，为某一目标设计某种适用的架构（如，为大数据系统设计的流式数据）很可能对于另一目标来说是糟糕的设计（不适用于表征事实发生的事件驱动系统）。
4、领域驱动设计的有界上下文可以为事件内容的设计提供一些指导。
5、架构是关于决策和权衡，最大化应用开闭原则很可能意味着对“迪米特法则”的最小化遵循，必须谨小慎微地寻找一个平衡点。
无论是在上学期的设计模式学习中，还是在这学期的软件体系架构这门课程的学习中，都有关于“高内聚、低耦合”、“六大设计原则”等概念。可见在大学的学习过程中是一个整体的学习过程，每门课之间都有联系，软件工程这一专业中的课程也是需要融会贯通的。无论在变成学习上还是在架构设计上都应该注意这些原则。