《敏捷软件开发第五讲-开闭原则与里氏替换原则》课件.ppt

* * * * * 我们会发现在自己编程中常常会违反里氏替换原则，程序照样跑。所以大家都会产生这样的疑问，假如我非要不遵循里氏替换原则会有什么后果？ 后果就是：你写的代码出问题的几率将会大大增加。 * 符合OCP的设计方案 public interface Excutable { public boolean isOpen(); public void open(); public void close(); } 新的实现 public class Door implements Excutable { private boolean _isOpen = false; public boolean isOpen() { return _isOpen; } public void open() { _isOpen = true; } public void close() { _isOpen = false; } } public class Hand { public Excutable item; void do() { if (item.isOpen()) item.close(); else item.open(); } } public class Drawer implements Excutable { private boolean _isOpen = false; public boolean isOpen() { return _isOpen; } public void open() { _isOpen = true; } public void close() { _isOpen = false; } } public class SmartTest { public static void main(String[] args) { Hand myHand = new Hand(); myHand.item = new Door(); myHand.do(); } } 新的需求…… 需要手去开关冰箱……? 为冰箱实现Excutable接口 不需要修改任何原有的设计和代码 public class Refrigerator implements Excutable { private boolean _isOpen = false; public boolean isOpen() { return _isOpen; } public void open() { _isOpen = true; } public void close() { _isOpen = false;} } OCP原则实施要点 预测变化和“贴切的”结构 上述的例子其实并不是完全封闭的，如果手增加了新的动作，例如搬运，很多地方还是会有改动变化。那么原来所选定的抽象对于这种变化来说反到成为一种障碍。 一般而言，无论模块是多么的“封闭”，都会存在一些无法对之封闭的变化。没有对于所有的情况都贴切的模型。 设计人员必须对于他们设计的模块应该对哪种变化封闭做出选择。 必须先猜测出最有可能发生的变化种类，然后构造抽象来隔离变化。 OCP原则实施要点 要避免进行多余的抽象 遵循OCP的代价也是昂贵的。创建正确的抽象是要花费时间和精力的。同时这些抽象也增加了软件的复杂性。因此，开闭原则很难被完全实现，只能在某些模块、某种程度上、某个限度内符合OCP的要求。所以可以说，OCP具有理想主义的色彩，是OOD的终极目标。 在项目很紧张的情况下，一般只会对能百分之百预测到的变化经行抽象，而且要是那种会经常发生变化的部分才进行抽象。 OCP原则实施要点 隔离变化的手段 1. “只受一次愚弄” 这意味着在我们最初编写代码时，假设变化不会发生；当变化发生时，我们就创建抽象来隔离以后发生的同类变化。 2. 刺激变化。 我们首先编写测试 我们使用很短的迭代周期进行开发——一个周期为几天而不是几周 我们在加入基础结构之前就开发特性，并且经常性的把那些特性展示给涉众 我们首先开发最重要的特性 尽早的、经常的发布软件 L