开放－封闭原则（OCP：The Open-Closed Principle）
很早就买了“敏捷软件开发――原则、模式与实践”这本很经典的书籍，觉得自己以前没有好好看，脑袋中都没有太多的印象。最近又有兴趣随便翻翻，记录一下自己的一些感受。
开放－封闭原则：软件实体（类，模块，函数等等）应该是可以扩展的，但是不可修改的。
第一次看到这个原则时觉得比较吃惊，既要做到“对于扩展是开放的”，模块的行为可以扩展，又要“对于更改是封闭的”，不允许修改现有的代码；这能做到吗？
大家可能都有这样的体会，要满足各种各样的客户，并且客户的需求经常变化，程序员就是这样的辛苦命，整天改过来改过去，特别用一些非面向对象的语言写的代码，函数的参数变得越来越长，里面的Case情况慢慢增加，函数变得很大。软件几年之后就变得难于理解和维护，软件的生命周期好像就要终止。如果能够扩展模块的功能，同时又不修改原来已经测试通过的代码，那多好啊！
这完全是可以实现的，关键是抽象。把可能的变化用抽象来隔离它。面向接口编程，而不是面向对象编程，能增强程序的灵活性；如Client类调用Server类，如果我们希望Client对象使用另外一个不通的Server对象，就必须修改Client中使用Server类的地方；如果Client调用Server的接口就可以避免这种修改，只要生成新的接口实现类，修改Main等初次使用新子类的地方而不需要修改Client类；使用Strategy模式和Template Method模式是满足OCP的最常用方法。
如果需要适应某种变化就需要对这种变化进行抽象，会增加程序的复杂度。所以设计人员应该熟悉业务和了解客户需求，预测到需要进行抽象的变化。
敏捷建模不建议提前进行各种假想的变化抽象，而是当变化发生第一次的时候抽象这种变化，以后同样的变化就变得很容易。对代码进行重构以保持良好的结构是很重要的，每次抽象都不应该使软件变得越来越僵化。这是非面向对象的语言不具备的优势。
