4. Coupling
● A device for connecting parts.
● In Software Terminology
○ Coupling is the degree of interdependence between software entities.
○ It measure of how closely connected two or more software entities.
○ It shows strength of the relationships between software entities.
○ Coupling is usually contrasted with cohesion.
○ Low coupling often correlates with high cohesion, and vice versa.
○ Coupling can be "low" (also "loose" and "weak") or "high" (also "tight" and "strong")
6. Tightly Coupled System
● Tight coupling is when a group of entities are highly dependent on one
another.
● This scenario arises when a class assumes too many responsibilities,
● When one concern is spread over many entities rather than having its own
class.
● When entity don’t follow Single Responsibility Principle and separation of
concerns.
F
E
D
C
A
B
7. Tightly Coupled System - Disadvantages
● A change in one module usually forces a ripple effect of changes in other
modules.
● Assembly of modules might require more effort and/or time due to the
increased inter-module dependency.
● A particular module might be harder to reuse and/or test because dependent
modules must be included.
8. Loosely Coupled System
● Loose coupling is achieved by means of a design that promotes
single-responsibility and separation of concerns.
● A loosely-coupled entity can be consumed and tested independently of other
entities.
● Loose coupling is often a sign of a well-structured computer system and a
good design.
● when it combined with high cohesion, it supports the general goals of high
readability and maintainability.
9. Loosely Coupled System
● Components can be replaced with alternative implementations that provide
the same services.
● Components in a loosely coupled system are less constrained to the same
platform, language, operating system, or build environment.
F
E
D
C
A
B
12. Event - Structure
● Event Header
○ The event header might include information such as event name, time stamp for the event,
and type of event.
● Event Body
○ The event body provides the details of the state change detected. An event body should not
be confused with the pattern or the logic that may be applied in reaction to the occurrence of
the event itself.
15. Dispatcher
● Dispatchers are communications personnel
responsible for receiving and transmitting pure and
reliable messages.
● A number of organizations, including police and fire
departments, emergency medical services, railroads,
etc, use dispatchers to relay information and
coordinate their operations.
17. Event Dispatcher
● It provides way which allow application components to communicate with
each other by dispatching events and listening to them.
● It is the only way to use communication where you don't care about the
target object.
● Target object may or may not be exists.
● They will listen to any messages that are being broadcasted.
19. Open Ear Event Dispatcher - Listener
● This type of event dispatchers are like
message-sponges.
● They will listen to any messages that are
being broadcasted.
21. Open Mouth Event Dispatcher - Talker
● This type of event dispatchers are like
loudmouths.
● They will broadcast any message to anyone
who is listening on demand.
23. Event-Driven Architecture
Event-Driven Architecture aims at promoting
Loosely Coupled System.
● It is a programming paradigm in which the flow of the program is
determined by series of events.
● It is a software architecture pattern promoting the creation, detection,
consumption of, and reaction to events.
25. Event-Driven Architecture
● A listener tells a central dispatcher object that it wants to listen to the some
specific event (X).
● At some point, the event generator tells the dispatcher object to dispatch the
event (X), passing with it an Event object.
● Event object itself often contains data about the event being dispatched.
● The dispatcher notifies (i.e. calls a method on) all listeners of the event (X).
27. Listener
● It is signed up specifying the events on which it listens (i.e. Service
Definition).
● It can also listen on several events simply by adding more tags in service
definition.
● Same event listener can be bind to different events without modifying class.
Simply by changing service definition.
● An event listeners are bind at the time of bootstrapping.
● Listeners are more flexible because bundles can enable or disable each of
them conditionally depending on some configuration value.
28. Subscriber
● The Subscriber has a method telling the dispatcher what events it is listening
to.
● It keeps the knowledge of the events in the class rather than in the service
definition.
● You can change the events a subscriber is registered for, at runtime and
even after registering the subscriber by changing the return value of
getSubscribedEvents method.
● Subscribers are easier to reuse because the knowledge of the events is kept
in the class rather than in the service definition. This is the reason why
Symfony uses subscribers internally;
30. Debugging Event Listeners
You can find out what listeners are registered in the event dispatcher using the
console:
You can get registered listeners for a particular event by specifying its name:
# php bin/console debug:event-dispatcher
# php bin/console debug:event-dispatcher kernel.exception
