[原創]實例-少用單例及降低耦合，實例耦合
引言
我想就我個人開發時遇到的一些實際情況，與各位做一些分享，語言以c#、java為例，代碼遵循語言編碼規范
實例
本文以某.net客戶端項目A為例，在項目A中，數據訪問層存在如下多個服務模塊
1、各服務內聚了數據處理邏輯，並提供簡單的接口供上層業務邏輯調用
2、各個服務間存在相互調用的情況
為便於上層訪問各數據服務，一些程序員會將每個服務都定位為單例，或許會習慣性的命名為XxxManager
服務間的應用，如服務A依賴服務B提供數據，不假思索的使用BSerivice.Instance.Xxx()獲取數據
對於小型項目，這樣做無可厚非，隨著軟件的復雜度的提升，這樣的結構難免會造成維護上的苦難。過多全局實例，服務間的強耦合，自然散發出不佳的味道
那麼如何改善，考慮如下兩點
1、我不需要每一個服務都是單例類型
2、我不希望各個服務之間嚴重耦合，最好以接口來獲取服務
少用單例&降低耦合
單例是常用且最基本的一種設計模式。然而，單例的作用相當於全局對象，應避免過度使用
采用如下設計
針對每個Service類型，分別定義對應的IXxxService接口類型，不要擔心類型爆炸（類型/接口 數量激增），Service畢竟不足10個
![]()
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程序集中以供復用）
解耦合往往會加倍你的類型數量，提升復雜度。
開發中應該注意保持代碼的簡單易於維護，使其在任何時候都易於重構，做到這點你的軟件就已經具備很強的生命力了。
