[Original] instance-less singleton and reduced coupling, instance Coupling

[Original] instance-less singleton and reduced coupling, instance Coupling
Introduction I would like to share some of the actual situations I encountered during my personal development. The language uses c # and java as examples, and the Code follows the language encoding specifications. for example, project A of the. net client. In Project A, the data access layer has the following service modules: 1. Each Service has A data processing logic, and provides simple interfaces for upper-layer business logic calls. 2. Mutual calls between services. To facilitate upper-layer access to various data services, some programmers will position each service as a singleton, it may be customary to name XxxManager an application between services. For example, service A relies on service B to provide data and uses BSerivice without thinking about it. instance. xxx () data acquisition is understandable for small projects. As the complexity of the software increases, such a structure will inevitably cause maintenance difficulties. There are too many global instances and strong coupling between services, which naturally gives rise to poor taste. How can this be improved, consider the following two points: 1. I do not need to use a singleton type for every service. 2. I do not want serious coupling between services. It is best to use interfaces to obtain services.Fewer Use Cases &Reduced CouplingSingleton is a common and basic design model. However, the role of a singleton is equivalent to a global object. Avoid using the following design to define the corresponding IXxxService Interface Types for each Service type, do not worry about type explosion (the number of types/interfaces has soared). After all, the Service has less than 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 );//...}}Initialize each Service object in order in the Init method. In the constructor, pay attention to passing this parameter (the most Service provider ), the AddService generic method is used to add each instance to the container. Each Service is derived from the abstract type ServiceBase. The base class ServiceBase maintains an IServiceProvider field _ serviceProvider, the implementation of referencing the actual ServicesManager object ServiceBase is roughly as follows:

    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;        }    }

You can use the following methods to obtain other Service instances within each Service:

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

 

Conclusion: This is actually the most basic dependency injection implementation. Through interfaces, services are decoupled. For the upper-layer business logic, you do not need to know the specific implementation of each Service, or even call various services in the form of interfaces through remote access (in fact, this software does exactly this, one machine maintains data and provides a data layer Service interface. Multiple Clients connect to the machine to query data. All interface definitions are placed in the Common Assembly for reuse.) decoupling will often increase the number of your types, increase complexity. During development, you should pay attention to keeping the code simple and easy to maintain, so that it is easy to refactor at any time, so that your software has a strong vitality.