Common Structural Patterns used with Design Patterns
Examples of Structural patterns
The more I learn about patterns the more frequently I see them in other people's code.
The Java class library in particular seems to be littered with common design patterns. However, the Java class library documentation makes no mention of this fact. In one sense this a good idea because it makes the documentation more accessible to non-pattern-literate programmers. However, it also makes it more obscure. For instance, more than one programmer has found themselves confused by the Reader and Writer classes in the java.io package because they do not recognize its use of the Decorator pattern. In general, I think that if you are using a well-known pattern in your class library, it would not hurt to mention that fact in its documentation. These design patterns concern class and object composition.
The concept of inheritance is used to compose interfaces and define ways to compose objects to obtain new functionalities.
In software engineering, structural design patterns are design patterns that ease the design by identifying a simple way to realize relationships between entities. Examples of Structural Patterns include:
Adapter pattern: adapts one interface for a class into one that a client expects
Retrofit Interface Pattern: An adapter used as a new interface for multiple classes at the same time.
Adapter pipeline: Use multiple adapters for debugging purposes.
Aggregate pattern: a version of the Composite pattern with methods for aggregation of children
Bridge pattern: decouple an abstraction from its implementation so that the two can vary independently
Tombstone: An intermediate lookup object contains the real location of an object.
Composite pattern: a tree structure of objects where every object has the same interface
Decorator pattern: add additional functionality to a class at runtime where subclassing would result in an exponential rise of new classes
Extensibility pattern: also known as Framework - hide complex code behind a simple interface
Facade pattern: create a simplified interface of an existing interface to ease usage for common tasks
Flyweight pattern: a high quantity of objects share a common properties object to save space
Proxy pattern: a class functioning as an interface to another thing
Pipes and filters: a chain of processes where the output of each process is the input of the next
Private class data pattern: restrict accessor/mutator access
There are seven popular structural design patterns which you are liable to encounter. In this module, we are going to concentrate on the Flyweight pattern, and incorporate it into the course project. The other six common structural patterns are described in the following series of images below:
Common Structural Patterns
Structural patterns primarily:
Deal with objects delegating responsibilities to other objects. This results in a layered architecture of components with a low degree of coupling.
Facilitate inter-object communication when one object is not accessible to the other by normal means or when an object is not usable because of its incompatible interface.
Provide ways to structure an aggregate object so that it is created in full and to reclaim system resources in a timely manner.
Structural Patterns: Designing objects to satisfy particular project constraints.
These work with the way objects are connected with other objects to ensure that changes in the system do not require changes to those connections.
Decorator:
Extends the functionality of an object in a manner that is transparent to its clients without using inheritance.
Adapter:
Allows the conversion of the interface of a class to another interface that clients expect. This allows classes with incompatible interfaces to work together.
Chain of Responsibility:
Avoids coupling a (request) sender object to a receiver object. Allows a sender object to pass its request along a chain of objects without knowing which object will actually handle the request.
Facade:
Provides a higher-level interface to a subsystem of classes, making the subsystem easier to use.
Proxy:
Allows a separate object to be used as a substitute to provide controlled access to an object that is not accessible by normal means.
Bridge:
Allows the separation of an abstract interface from its implementation. This eliminates the dependency between the two, allowing them to be modified independently.
Virtual Proxy Facilitates:
The mechanism for delaying the creation of an object until it is actually needed in a manner that is transparent to its client objects.
Counting Proxy:
When there is a need to perform supplemental operations such as logging and counting before or after a method call on an object, recommends encapsulating the supplemental functionality into a separate object.
Aggregate Enforcer:
Recommends that when an aggregate object is instantiated, all of its member variables representing the set of constituting objects must also be initialized. In other words, whenever an aggregate object is instantiated it must be constructed in full.
Explicit Object Release:
Recommends that when an object goes out of scope, all of the system resources tied up with that object must be released in a timely manner.
Object:
Cache Stores the results of a method call on an object in a repository. When client objects invoke the same method, instead of accessing the actual object, results are returned to the client object from the repository.
This is done mainly to achieve a faster response time.
These patterns use the same basic techniques to form their structures, so they look somewhat similar on the face of it.
Howwever, most of these patterns solve different problems, and in general the problem you face determines which pattern you choose.