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

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

using System;
using System.Collections;
/**//// <summary>
/// ShopCart Class
/// </summary>
public class ShopCart
{
    private List<Production> productions; 
    public ShopCart()
    {
        productions = new List<Production>();
    }
    public void AddProduction(Production NewProduction)
    {
        productions.Add(NewProduction);
    }
}
/**//// <summary>
/// Abstract Class production
/// </summary>
public abstract class Production
{
    //
}
/**//// <summary>
/// Instance Class
/// </summary>
public class Apple : Production
{
    //
}
/**//// <summary>
/// Another Instance Class
/// </summary>
public class Fish : Production
{
    //
}

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

using System;
using System.Collections;
/**//// <summary>
/// SubWay Class
/// </summary>
public class SubWay
{
    private List<Station> stations; 
    private List<Connection> connections; 

    public SubWay()
    {
        stations = new List<Station>();
        connections = new List<Connection>();

    }
    public void AddStation(string StationName)
    {
        stations.Add(new Station(StationName));
    }
    public void AddConnection(string StationName1, string StationName2)
    {
        stations.Add(new Connection(StationName1, StationName2));
    }
    //
}

/**//// <summary>
/// Station Class
/// </summary>
public class Station
{
    public Station(string stationName)
    {
        //
    }
    //
}
/**//// <summary>
/// Connection Class
/// </summary>
public class Connection
{
    public Connection(Station station1, Station station2)
    {
        //
    }
    //
}

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