[原創]實例-少用單例及降低耦合

引言

我想就我個人開發時遇到的一些實際情況，與各位做一些分享，語言以c#、java為例，代碼遵循語言編碼規范

實例

本文以某.net客戶端項目A為例，在項目A中，數據訪問層存在如下多個服務模塊

1、各服務內聚了數據處理邏輯，並提供簡單的接口供上層業務邏輯調用

2、各個服務間存在相互調用的情況

 

 

為便於上層訪問各數據服務，一些程序員會將每個服務都定位為單例，或許會習慣性的命名為XxxManager

服務間的應用，如服務A依賴服務B提供數據，不假思索的使用BSerivice.Instance.Xxx()獲取數據

對於小型項目，這樣做無可厚非，隨着軟件的復雜度的提升，這樣的結構難免會造成維護上的苦難。過多全局實例，服務間的強耦合，自然散發出不佳的味道

 

那么如何改善，考慮如下兩點

1、我不需要每一個服務都是單例類型

2、我不希望各個服務之間嚴重耦合，最好以接口來獲取服務

 

少用單例&降低耦合

單例是常用且最基本的一種設計模式。然而，單例的作用相當於全局對象，應避免過度使用

采用如下設計

針對每個Service類型，分別定義對應的IXxxService接口類型，不要擔心類型爆炸（類型/接口 數量激增），Service畢竟不足10個

 

僅存在一個單例類型ServicesManager，其組合各Service實例，上層直接以ServicesManager.Instance.XxxService獲取接口類型的服務對象

 

 

那么如何降低服務間的耦合呢，見下圖

 

ServicesManger實現System.IServiceProvider接口，實現GetService方法，以作為服務提供者

組合一個集合類型用作容器，字典_serviceMap，key為Type，value為service實例

整體代碼大致如下

    class ServicesManager : IServiceProvider
    {
        private static readonly ServicesManager INSTANCE = new ServicesManager();
 
        public static ServicesManager Instance
        {
            get { return INSTANCE; }
        }
 
        private readonly Dictionary<Type, object> _serviceMap = new Dictionary<Type, object>();
 
        public void AddService<T>(T service)
        {
            _serviceMap.Add(typeof(T), service);
        }
 
        public object GetService(Type serviceType)
        {
            return _serviceMap[serviceType];
        }
 
        public void Init()
        {
            UserCenterService userCenterService = new UserCenterService(this);
            userCenterService.Init();
            AddService<IUserCenterService>(userCenterService);
            // ...
        }
    }

 

在Init方法中依次初始化各個Service對象，構造方法中注意傳遞this參數（將最為服務提供者），通過AddService泛型方法將各實例添加到容器中

每個Service均從抽象類型ServiceBase派生，基類ServiceBase維護一個IServiceProvider類型的字段_serviceProvider，引用實際的ServicesManager對象

ServiceBase的實現大致如下

    abstract class ServiceBase
    {
        private readonly IServiceProvider _serviceProvider;
 
        protected ServerServiceBase(IServiceProvider serviceProvider)
        {
            _serviceProvider = serviceProvider;
        }
 
        protected T GetService<T>() where T : class
        {
            return _serviceProvider.GetService(typeof(T)) as T;
        }
    }

 

在各Service內部，可以使用方式如下獲取其他Service實例

var realtimeDataService = GetService<IRealtimeDataService>();
realtimeDataService.xxxx

 

結語

這其實就是一個最基本的依賴注入實現，通過接口，各服務間得到了解耦。對於上層業務邏輯而言，也不需要知道各個Service的具體實現，甚至可以通過遠程訪問的方式，以接口的形式調用各種服務（實際上這個軟件正是這樣做的，一台機器維護數據，提供數據層Service接口，多客戶端連接該機器查詢數據，所有接口定義放在Common程序集中以供復用）

 

解耦合往往會加倍你的類型數量，提升復雜度。

開發中應該注意保持代碼的簡單易於維護，使其在任何時候都易於重構，做到這點你的軟件就已經具備很強的生命力了。