Component Design Practice-Relationship between components (Event, dependency inversion, Bridge)

The relationship between one component and another can be established in three ways: event, dependency inversion, and Bridge. Now we only consider one-way dependency, that is, information providers and information consumers. An event is a loosely coupled information publishing method. The event publisher (information provider) does not need to care about any information of the event subscriber (that is, information consumer, however, the event preferer must rely on the event publisher. The dependency inversion reverses this relationship. In the Dependency inversion mode, the information provider depends on the Information consumer (You may think this sentence is strange, in the following example, the Information consumer does not need to know any information about the information provider. The so-called Bridge is an intermediary mode, information publishers and information providers are completely independent of each other and do not depend on each other. They are bridging through Bridge.

Then, when designing the relationship between the components, the method should be determined based on the actual situation. Assume that component A is the information provider, and component B is the information consumer. There may be the following situations:
(1) A releases the event, B contains the reference of A, and B predefines the event of. (Event Method)
(2) interface B provides methods for receiving information. A contains references of interface B. When appropriate, A calls the method for receiving information of interface B. (Dependency inversion)
(3) A publishes an event. Interface B provides methods for receiving information and connects A and B through Bridge. (Bridge Mode)

The following is a practical example. In our application, there is a function Service Manager IServiceManager (information provider), which can be changed during running, this change can be detected by IServiceManager, And the IServiceDisplayer (Information consumer) that displays the function service name also needs to make the necessary changes when the function service changes. If the "event" method is used, the following design should be performed: public interface IServiceManager
{
Event CbServiceAdded ServiceAdded;
}

Public delegate void CbServiceAdded (string serviceName );

Public interface IServiceDisplayer
{
IServiceManager ServiceManager;
}

The dependency inversion method is designed as follows: public interface IServiceManager
{
IServiceDisplayer ServiceDisplayer {set ;}
}

Public interface IServiceDisplayer
{
Void AddService (string serviceName );
}

The "Bridge" method is designed as follows: public interface IServiceManager
{
Event CbServiceAdded ServiceAdded;
}

Public delegate void CbServiceAdded (string serviceName );

Public interface IServiceDisplayer
{
Void AddService (string serviceName );
}

Public interface IServiceBridge
{
IServiceManager ServiceManager {set ;}
IServiceDisplayer ServiceDisplayer {set ;}

Void Initialize ();
}

Public class ServiceBridge: IServiceBridge
{
Private IServiceManager serviceManager = null;
Private IServiceDisplayer serviceDisplayer = null;

# Region IServiceBridge Member

Public void Initialize ()
{
This. serviceManager. ServiceAdded + = new CbServiceAdded (serviceManager_ServiceAdded );
}

Public IServiceManager ServiceManager
{
Set
{
This. serviceManager = value;
}
}

Public IServiceDisplayer ServiceDisplayer
{
Set
{
This. serviceDisplayer = value;
}
}

# Endregion

Private void serviceManager_ServiceAdded (string serviceName)
{
This. serviceDisplayer. AddService (serviceName );
}
}

All three methods are feasible, but in different application cases, different methods lead to different dependency complexity between components in the application, it has a profound impact on the definition of the entire system structure. So what is the principle?
(1) Generally, "events" are used.
(2) If you encounter this situation when using the "event" method: IServiceDisplayer's scheduled IServiceManager's scheduled part of the event is only IServiceDisplayer, and no other component will schedule this part of the event, you can consider removing these events from IServiceManager, and then "Dependency inversion. This greatly reduces the number of events that IServiceManager needs to release.
(3) If the information required by IServiceDisplayer is not only from IServiceManager, but also from many other components, the third method is used.
(4) exercise caution when using the "Dependency inversion" method, especially when IServiceManager does not need to obtain any information from IServiceDisplayer, the second method may cause IServiceManager to depend on IServiceManager, this dependency is unnecessary.
(5) when one or more information recipients need to obtain event information from a large number of information publishers, the third method is recommended.

The subsequent articles will continue to make a profound analysis of these three methods, of course, this will wait until my understanding is further deepened. The name "Dependency inversion" is obtained by me. I don't know if there is a more formal name. Please tell me :)