to speak to the rest of the application when something interesting happens. We then use a different layer to interpret requests so that modules don’t directly access the core. This aids in preventing applications from falling over due to errors with a speciﬁc module.
They probably can in most current architectures. Having an intermediate layer handle permissions for which modules can access which parts of your framework gives you a layer of security. This means a module is only able to do at most what we’ve permitted it do.
possible In our case, modules should not rely on other modules in order to function correctly. When used effectively, it’s straight-forward to see how changes to one part of a system may affect another.
body of code, regardless of underlying complexity Hides the inner-workings of a library or set of modules, allowing the implementation to be less important. We thus only need to interact with the facade rather than the subsystem it encompasses.
or listen for messages without worrying about the rest of the system Messages can be handled by any number of modules at once. Typically signiﬁcantly more easy to add or remove features to systems which are loosely coupled like this.
always communicate indirectly. This can cause a very minor performance drop. Because of the nature of loose coupling, it’s difﬁcult to establish how a system might react by only looking at the broadcasts. At the end of the day, tight coupling causes all kinds of headaches and this is one solution.
handles what planes can take off and land. All communications are done from the planes to the control tower, rather than from plane-to- plane A centralised controller is key to the success of this system as is the case with the mediator pattern.
sits in the middle between it and modules Ensures a consistent interface to our modules is available at all times Should be the only thing modules are aware of - they shouldn’t know about other components.
to be dependable The adapter acts as a security guard, determining which parts of the application a module can access Components only call their own methods and shouldn’t interact with anything they don’t have permission to
sandbox controller. Agrees that it could equally be considered the adapter, proxy or facade pattern. As Stoyan Stefanov deﬁned an existing ‘sandbox’ pattern, I refer to the sandbox as a facade as IMO this pattern matches it’s purpose most closely.
LabelManager ‘Tom’s order has been successfully packaged ‘Tom’s order has been labelled notify(‘orderPackaged’,‘Tom’,‘success’) notify(‘orderLabelled’,‘Tom’, ‘success’) Module 3 DispatchManager ‘Tom’s order has been dispatched notify(‘orderDispatched’,‘Tom’, ‘success’,’12-08-11’) Start LabelManager Start DispatchManager
the mediator pattern. Responsible for module management. The facade abstracts the core to avoid modules touching it directly. Handles security. The modules contain speciﬁc pieces of functionality for your application.