基于扩展性考虑,不同场景选择的不同方案

  说到可扩展性(Extension),大家都知道应用一些OO的feature和Principles可以达到这种效果像封装(Encapsulation),可以使对象最大可能性的把变化的部分封装在对象内部,减小影响面.面向接口而非实现编程(Coding to Interface instead of Implementation)可以是对象之间松散耦合,方便扩展. OCP,SRP这类的guideline也是达到易于扩展目的的方法.
  在实际应用中,可能会因为不同场景选择不同的方案,看两个例子.
第一个,

using System;
using System.Collections;

这个很好理解,ShopCart中可以放任何商品,只要是从Production基类中继承来的,这样以后有新的品种商品加入的话,只需要增加新的实例类就可以了,对于ShopCart类不用任何修改.
第二个例子,

using System;
using System.Collections;
}

是不是貌似相同的情况,地铁由车站和连接线组成.用户可以自己添加车站和线路.
这里我们没有把Station 和 Connection 的对象当做参数传入SubWay类中,我们的考虑是,地铁和连接线是实体类,一般不会有修改,我们就没有做抽象.而最终用户,只关心车站名称和最终的地铁线路图,对于地铁对象和连接线对象也是不感兴趣的.所以我们就没有暴露这两个对象给用户.这样,如果以后有扩展或修改需求,比如车站除了名字还要颜色属性,我们就可以很方便在内部解决问题,对外没有任何变化.
  这两个例子我们可以看出,最终的好的design不是靠一些书本的知识能够得出来的,而是对需求的准确理解,以及对于将来需求变更的预测.才能知道那些是变化的,那些是不变的.这种OOA的工作,需要花费相当的精力来做,而且非常值得,对于以后的维护能够起到事半功倍的效果.