Structural Design Patterns

Structural Design Patterns are solutions in software design that focus on how classes and objects are organized to form larger, functional structures. These patterns help developers simplify relationships between objects, making code more efficient, flexible, and easy to maintain. By using structural patterns, you can better manage complex class hierarchies, reuse existing code, and create scalable architectures.

There are two recurring themes in these patterns:

• This pattern is particularly useful for making independently developed class libraries work together.
• Structural Design Patterns describe ways to compose objects to realize new functionality.
• The added flexibility of object composition comes from the ability to change the composition at run-time, which is impossible with static class composition.

Example for Structural Design Patterns

A drawing editor that lets users draw and arrange graphical elements (lines, polygons, text, etc.) into pictures and diagrams. The drawing editor's key abstraction is the graphical object, which has an editable shape and can draw itself.

The interface for graphical objects is defined by an abstract class called Shape. The editor defines a subclass of the Shape for each kind of graphical object: a LineShape class for lines, a PolygonShape class for polygons, and so forth.

Types of Structural Design Patterns

1. Adapter Method Design Pattern

Adapter Method or Adapter Design Pattern also knows as wrapper. It converts the interface of a class into another interface which clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.

When to use Adapter Method?

• You want to use an existing class, and its interface does not match the one you need.
• You want to create a reusable class that cooperates with unrelated or unforeseen classes, that is, classes that don't necessarily have compatible interfaces.
• (object adapter only) you need to use several existing subclasses, but it's unpractical to adapt their interface by subclassing every one. An object adapter can adapt the interface of its parent class.

2. Bridge Method Design Pattern

By separating an object's implementation (how it does something) from its abstraction (what it does), the Bridge Design Pattern enables the two to develop separately.

Imagine you have different types of devices (like TVs and Radios) and different ways to control them (like Remote and Voice Control). Instead of tightly coupling each device with each control type, the Bridge pattern lets you connect them loosely.

When to use Bridge Method?

• You want to avoid a permanent binding between an abstraction and its implementation. This might be the case,for example,when the implementation must be selected or switched at run-time.
• Changes in the implementation of an abstraction should have no impact on clients; that is, their code should not have to be recompiled.
• You want to hide the implementation of an abstraction completely from clients.
• You want to share an implementation among multiple objects(perhaps using reference counting), and this fact should be hidden from the client.

3. Composite Method Design Pattern

Composite Method Design Pattern composes objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.

When to use Composite Method?

• You want to represent part-whole hierarchies of objects.
• You want clients to be able to ignore the difference between compositions of objects and individual objects. Clients will treat all objectsin the composite structure uniformly.

4. Decorator Method Design Pattern

Adding additional features or actions to an item without changing its structure is possible with the Decorator Method Design Pattern. Consider that you want to add things like milk, sugar, or whipped cream to your simple coffee. Instead of creating a whole new coffee type for every possible combination, the decorator pattern lets you "wrap" the plain coffee with add-ons.

When to use Decorator Method?

• To add responsibilities to individual objects dynamically and transparently, that is, without affecting other objects.
• For responsibilities that can be withdrawn.
• When extension by subclassing is impractical. Sometimes a large number of independent extensions are possible and would produce an explosion of subclasses to support every combination.

5. Facade Method Design Pattern

Facade Method Design Pattern provides a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.

When to use Facade Method Design Pattern?

• You want to provide a simple interface to a complex subsystem. Subsystems often get more complex as they evolve. This makes the subsystem more reusable and easier to customize, but it also becomes harder to use for clients that don't need to customize it.
• There are many dependencies between clients and theimplementation classes of an abstraction. Introduce a facade to decouple the subsystem from clients and other subsystems.
• You want to layer your subsystems. Use a facade to define an entry point to each subsystem level. If subsystems are dependent, then you can simplify the dependencies between them by making them communicate with each other through their facades.

6. Flyweight Method Design Pattern

The Flyweight Method Design Pattern helps reduce memory usage by sharing common parts of objects instead of creating separate instances. Imagine a game with many trees: rather than creating individual tree objects with identical properties (like texture or color), the Flyweight pattern shares these common properties across all tree objects. Only the unique data for each tree is stored separately.

When to use Flyweight Method?

The Flyweight pattern's effectiveness depends heavily on how and where it's used. Apply the Flyweight pattern when all of the following are applicable:

• An application uses a large number of objects.
• Storage costs are high because of the sheer quantity of objects.
• Most object state can be made extrinsic.
• Many groups of objects may be replaced by relatively few shared objects once extrinsic state is removed.
• The application doesn't depend on object identity.

7. Proxy Method Design Pattern

Proxy Method Design Pattern also known as Surrogate, provides a surrogate or placeholder for another object to control access to it.

When to use Proxy Method?

Proxy method is applicable whenever there is a need for a more versatile or sophisticated reference to an object than a simple pointer. Here are several common situations in which the Proxy pattern is applicable:

• A remote proxy provides a local representative for an object in a different address space.
• A virtual proxy creates expensive objects on demand.
• A protection proxy controls access to the original object. Protection proxies are useful when objects should have different access rights
• A smart reference is a replacement for a bare pointer that performs additional actions when an object is accessed.

Benefits of Structural Design Patterns

• Simplify Code: Structural patterns help organize and simplify code by connecting objects and classes in a clear way, making complex relationships easier to understand and manage.
• Reduce Duplicate Code: By reusing existing structures, structural patterns avoid duplicate code, which makes your program more efficient and less prone to errors.
• Enhance Flexibility: These patterns allow you to add or change features without altering existing code too much, making the program easier to extend or modify.
• Improve Readability: They provide a clear structure that organizes classes and objects, making it easier for others to understand and maintain the code.
• Optimize Resource Use: Structural patterns like Flyweight help reduce memory usage and improve performance by sharing common data among objects instead of duplicating it.

Challenges of Structural Design Patterns

• Increased Complexity: Structural patterns like Decorator or Proxy can add layers to the code, making it harder to read and follow. If too many patterns are used, the code can become overly complex.
• Performance Issues: Some patterns, such as Flyweight, may need extra processing to manage shared objects. This can lead to slower performance if not used carefully.
• Overhead in Maintenance: As structural patterns add more classes and interfaces, it can be harder to maintain or update the code. New developers may need more time to understand how everything fits together.
• Risk of Overengineering: It’s easy to overuse patterns, which leads to unnecessary abstraction. Sometimes, simpler code without patterns is more effective and easier to work with.
• Difficulty in Debugging: With extra layers, tracing bugs can become challenging since the problem might be hidden deep within the pattern structure.