Lesson 10

Structural object patterns use composition to build larger structures from individual objects. Structural class patterns use inheritance to combine the interfaces or implementations of multiple classes. What are additional properties of Structural Design Patterns which enable software architects build systems?

Structural Design Patterns serve as the architectural underpinnings that allow complex systems to be constructed in an organized, maintainable, and efficient manner. Beyond merely using composition and inheritance as foundational mechanisms, these patterns offer nuanced capabilities that significantly benefit software architects in system building. The properties that render Structural Design Patterns invaluable for architectural endeavors include:

Patterns like the Adapter or the Facade allow architects to create lightweight interfaces focused on client requirements. Such interface segregation simplifies client interactions with complex subsystems, fostering an architectural landscape where high cohesion and low coupling are achieved, ultimately augmenting system extensibility.

Structural Design Patterns often serve to map real-world entities and their relationships into the software domain, which aids in creating more intuitive and understandable system architectures. This simplifies both the development and the subsequent maintenance phases, providing a semantic framework that is easier to reason about.
In summary, Structural Design Patterns offer a multifaceted toolkit for constructing complex systems. They provide essential mechanisms for promoting modularity, reusability, dynamic composition, and several other critical architectural virtues. Their judicious application is integral to crafting robust, scalable, and maintainable software architectures.

This module discussed structural patterns. Structural object patterns use composition to build larger structures from individual objects. Structural class patterns use inheritance to combine the interfaces or implementations of multiple classes. Used properly, structural patterns can increase the efficiency of your code, enhance its reusability and flexibility, more cleanly separate implementation from interface, and reduce complexity by providing cleaner, simpler interfaces to a system that are easier for client programmers to understand.

1. The Adapter Design Pattern is a type of design pattern that is used for converting the interface of a class into an interface that its clients expect to see. This pattern allows incompatible interfaces to work together.
2. The Bridge Design Pattern separates an abstract interface from its implementation so that both the interface and its implementation can change without any dependancy between each other.
3. The Composite Design Pattern is used to compose objects so that they can be represented in part-whole hierarchies in tree-structures. This pattern allows clients to treat individual objects equally.
4. The Decorator Design Pattern is used when additional functionality needs to be added to objects dynamically. This pattern provides an alternative to subclassing for extending an object's functionality.
5. The Facade Design Pattern is used to provide a high-level interface that makes the subsystem easier to use. It helps create a unified interface to a set of interfaces in the subsystem.
6. The Flyweight Design Pattern is used to share a large numbers of small objects efficiently
7. The Proxy Design Pattern is used is used when it is required to use another object as a substitute to control access to this object.

The lessons in this module show that structural patterns are not selected by matching a class diagram. They are selected by identifying a pressure in the way components collaborate. Adapter protects a client from an incompatible interface. Bridge separates two dimensions that must evolve independently. Composite gives leaves and groups one contract. Decorator adds composable responsibilities. Facade reduces the surface of a subsystem. Proxy controls access. Flyweight shares immutable intrinsic state across many logical objects.

Several patterns can produce a wrapper or delegation relationship, so intent must remain explicit. State which contract is preserved, what implementation detail is hidden, and which participant owns lifecycle and failure translation. This explanation is more valuable than the pattern name alone because it gives reviewers a testable reason for the extra structure.

Generics, dependency injection, records, smart pointers, and functional interfaces reduce some of the boilerplate found in classic object-oriented examples. They do not remove the need to reason about dependency direction, composition, state sharing, and substitutability. A small lambda may replace a class, while the surrounding structural boundary remains important.

Cloud-native systems extend these decisions across processes. An API gateway may resemble a Facade, a client stub may resemble a Proxy, and an integration component may act as an Adapter. Remote calls add latency, timeouts, retries, authentication, idempotency, and partial failure. A classic pattern supplies useful vocabulary, but production documentation must also define these operational behaviors.

The Flyweight sequence moved from motivation through suitability, structure, consequences, and the vehicle-intersection project. The essential decision is the boundary between intrinsic and extrinsic state. Immutable vehicle descriptions such as type, length, and maximum speed may be shared. Lane, position, arrival time, and current speed belong to each simulated occurrence.

A factory or repository canonicalizes a complete immutable key and returns one shared specification. A separate context holds live state. Tests must prove that equal keys share a specification while two vehicles continue to move independently. Profiling must show that reduced allocation and retained memory justify the added lookup, lifecycle, and API complexity.

The project also demonstrates restraint. The course simulation may not create enough vehicles to require Flyweight in production. Implementing both a simple factory and a flyweight-backed factory behind the same interface permits a measured comparison without changing the simulation contract.

1. Describe the collaboration problem before naming a pattern.
2. Define the stable client contract and the detail expected to change.
3. Prefer direct composition when it already communicates the design.
4. Use inheritance only for a genuine substitutable type relationship.
5. Make ownership, cleanup, and error translation explicit.
6. Test that wrappers preserve every promised semantic behavior.
7. For Flyweight, separate immutable intrinsic state from extrinsic state.
8. Bound or monitor caches whose key space can grow.
9. Measure memory, latency, allocation, and contention claims.
10. Document network failure behavior when a boundary becomes remote.

Structural patterns improve long-lived software when they make extension points visible, isolate incompatible or volatile dependencies, and let clients work through smaller contracts. They become liabilities when chosen for fashion, when wrappers hide important semantic changes, or when optimization is introduced without measurement.

The practical goal is therefore not to maximize the number of patterns in a system. It is to create a structure that another programmer can explain, test, operate, and change safely. With that foundation, the next module can focus on behavioral collaboration while relying on stable structural boundaries.

Maintain those boundaries with architecture tests, focused integration tests, and short decision records. An architecture test can prevent domain code from importing a vendor SDK that should remain behind an Adapter. Integration tests can verify that a Proxy translates failures consistently and that a Decorator preserves delegation order. Decision records explain why a Facade or Bridge exists and identify conditions under which it can be simplified.

Patterns should be reviewed as the system evolves. A wrapper created for an obsolete library may no longer be necessary. A small Flyweight cache may become unbounded after a new field is added to its key. Periodic review keeps the structure aligned with current forces rather than preserving accidental complexity indefinitely.