基於擴充性考慮,不同情境選擇的不同方案

  說到可擴充性(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的工作,需要花費相當的精力來做,而且非常值得,對於以後的維護能夠起到事半功倍的效果.