Lucent Owl logo Lucent Owl

Programming Patterns Diagrams

Last updated:

3 related guides
diagrams solid dependency-inversion design-patterns

Dependency Inversion Flips the Arrow

Structure

Source dependencies between a business module and infrastructure, before and after inversion.

Dependency inversion moves the interface into the business module Two panels, each with a business module above an infrastructure module. Before: OrderService in the business module uses SmtpEmailSender in the infrastructure module directly, so the source dependency points down from business logic to infrastructure. After: the business module holds both OrderService and the INotificationSender interface, and OrderService uses the interface. In the infrastructure module, EmailNotificationSender and SmsNotificationSender implement INotificationSender, so the only dependencies crossing the module boundary point up, from infrastructure to the business module. BEFORE: POLICY DEPENDS ON MECHANISM AFTER: THE DEPENDENCY CROSSES UPWARD BUSINESS MODULE INFRASTRUCTURE MODULE OrderService [class] SmtpEmailSender [class] Business rules can't compile or be tested without the SMTP code. BUSINESS MODULE INFRASTRUCTURE MODULE OrderService [class] INotificationSender [interface] EmailNotificationSender [class] SmsNotificationSender [class] The interface is owned by the business module, so infrastructure depends on business logic, not the reverse. uses (source dependency) implements

Four Wrapper Patterns Compared

Structure

Adapter, Decorator, Proxy, and Facade, by the interfaces each call passes through.

How Adapter, Decorator, Proxy, and Facade wrap other objects Four small diagrams. Adapter: a client calls the adapter through interface A, and the adapter calls a legacy class through a different interface B. Decorator: a client calls a logging decorator, which calls a retrying decorator, which calls the real object, and every call uses the same interface A, so the decorators stack. Proxy: a client calls a proxy through interface A, and the proxy may or may not forward the call to the real object through the same interface A. Facade: a client calls a facade through one simple interface S, and the facade calls three services, inventory, payments, and shipping. ADAPTER Client Adapter Legacy class A B Takes calls on interface A and translates them into interface B, which the legacy class has. DECORATOR Client Logging Retrying Real A A A Interface A at every layer, so decorators stack. Each one adds behavior and forwards the call. PROXY Client Proxy Real object A A Same interface A. The proxy decides whether and when to forward: lazily, after a check, or not at all. FACADE Client Facade S Inventory Payments Shipping One simple interface S in front of several services. the wrapper A, B, S the interface a call goes through forwarded only sometimes

Bridge Turns N × M Classes Into N + M

Structure

Three shapes and three renderers, by inheritance alone and through a bridge.

Bridge splits a two-dimensional class hierarchy into two hierarchies Left: with inheritance alone, three shapes and three renderers need nine classes, one per combination, from VectorCircle to PdfTriangle. Right: with a bridge, an abstract Shape class has three subclasses, Circle, Rectangle, and Triangle, and an IRenderer interface has three implementations, VectorRenderer, RasterRenderer, and PdfRenderer. Shape holds a reference to an IRenderer, which is the bridge, so six classes cover every combination and a new renderer is one new class. INHERITANCE ONLY: 3 × 3 = 9 CLASSES VectorCircle RasterCircle PdfCircle VectorRectangle RasterRectangle PdfRectangle VectorTriangle RasterTriangle PdfTriangle Every combination is its own class. A fourth renderer adds three more classes. BRIDGE: 3 + 3 = 6 CLASSES Shape [abstract class] IRenderer [interface] bridge Circle Rectangle Triangle VectorRenderer RasterRenderer PdfRenderer Each shape holds a reference to some renderer. A fourth renderer is one new class. inherits or implements holds a reference

Direct Links Versus a Mediator

Dependency graph

Five objects linked pairwise, and the same five linked through one mediator.

A mediator replaces pairwise links with links to one hub Left: five objects, A to E, where every object refers to every other, which takes ten links, and each new object adds a link to all the others. Right: the same five objects each linked only to a central mediator, which takes five links, and each new object adds one. DIRECT REFERENCES: 10 LINKS THROUGH A MEDIATOR: 5 LINKS A B C D E A B C D E Mediator Every object knows every other. A sixth object adds five links, one to each existing object. Each object knows only the mediator. A sixth object adds one link.

Found this useful? Share it:

Share on LinkedIn