#Design_Patterns
#Structural_patterns
▪️In Software Engineering, Structural Design Patterns are Design Patterns that ease the design by identifying a simple way to realize relationships between entities.
1️⃣ #Adapter_Design_Pattern
Match interfaces of different classes
2️⃣ #Bridge_Design_Pattern
Separates an object's interface from its implementation
3️⃣ #Composite_Design_Pattern
A tree structure of simple and composite objects
4️⃣ #Decorator_Design_Pattern
Add responsibilities to objects dynamically
5️⃣ #Facade_Design_Pattern
A single class that represents an entire subsystem
6️⃣ #Flyweight_Design_Pattern
A fine-grained instance used for efficient sharing
7️⃣ #PrivateClassData_Design_Pattern
Restricts accessor/mutator access
8️⃣ #Proxy_Design_Pattern
An object representing another object
@javaCode☕️
#Structural_patterns
▪️In Software Engineering, Structural Design Patterns are Design Patterns that ease the design by identifying a simple way to realize relationships between entities.
1️⃣ #Adapter_Design_Pattern
Match interfaces of different classes
2️⃣ #Bridge_Design_Pattern
Separates an object's interface from its implementation
3️⃣ #Composite_Design_Pattern
A tree structure of simple and composite objects
4️⃣ #Decorator_Design_Pattern
Add responsibilities to objects dynamically
5️⃣ #Facade_Design_Pattern
A single class that represents an entire subsystem
6️⃣ #Flyweight_Design_Pattern
A fine-grained instance used for efficient sharing
7️⃣ #PrivateClassData_Design_Pattern
Restricts accessor/mutator access
8️⃣ #Proxy_Design_Pattern
An object representing another object
@javaCode☕️
#Design_Patterns
#Bridge_Design_Pattern
👉Intent
▪️Decouple an abstraction from its implementation so that the two can vary independently.
▪️Publish interface in an inheritance hierarchy, and bury implementation in its own inheritance hierarchy.
▪️Beyond encapsulation, to insulation
@javaCode☕️
#Bridge_Design_Pattern
👉Intent
▪️Decouple an abstraction from its implementation so that the two can vary independently.
▪️Publish interface in an inheritance hierarchy, and bury implementation in its own inheritance hierarchy.
▪️Beyond encapsulation, to insulation
@javaCode☕️
#Bridge_Design_Pattern
👉Problem
"Hardening of the software arteries" has occurred by using subclassing of an abstract base class to provide alternative implementations. This locks in compile-time binding between interface and implementation. The abstraction and implementation cannot be independently extended or composed.
@javaCode☕️
👉Problem
"Hardening of the software arteries" has occurred by using subclassing of an abstract base class to provide alternative implementations. This locks in compile-time binding between interface and implementation. The abstraction and implementation cannot be independently extended or composed.
@javaCode☕️
#Bridge_Design_Pattern
👉Discussion
Decompose the component's interface and implementation into orthogonal class hierarchies. The interface class contains a pointer to the abstract implementation class. This pointer is initialized with an instance of a concrete implementation class, but all subsequent interaction from the interface class to the implementation class is limited to the abstraction maintained in the implementation base class. The client interacts with the interface class, and it in turn "delegates" all requests to the implementation class.
The interface object is the "handle" known and used by the client; while the implementation object, or "body", is safely encapsulated to ensure that it may continue to evolve, or be entirely replaced (or shared at run-time.
👉Use the Bridge pattern when:
1️⃣you want run-time binding of the implementation,
2️⃣you have a proliferation of classes resulting from a coupled interface and numerous implementations,
3️⃣you want to share an implementation among multiple objects,
4️⃣you need to map orthogonal class hierarchies.
👉Consequences include:
1️⃣decoupling the object's interface,
2️⃣improved extensibility (you can extend (i.e. subclass) the abstraction and implementation hierarchies independently),
3️⃣hiding details from clients.
👉Bridge is a synonym for the "handle/body" idiom. This is a design mechanism that encapsulates an implementation class inside of an interface class. The former is the body, and the latter is the handle. The handle is viewed by the user as the actual class, but the work is done in the body. "The handle/body class idiom may be used to decompose a complex abstraction into smaller, more manageable classes. The idiom may reflect the sharing of a single resource by multiple classes that control access to it (e.g. reference counting)."
@javaCode☕️
👉Discussion
Decompose the component's interface and implementation into orthogonal class hierarchies. The interface class contains a pointer to the abstract implementation class. This pointer is initialized with an instance of a concrete implementation class, but all subsequent interaction from the interface class to the implementation class is limited to the abstraction maintained in the implementation base class. The client interacts with the interface class, and it in turn "delegates" all requests to the implementation class.
The interface object is the "handle" known and used by the client; while the implementation object, or "body", is safely encapsulated to ensure that it may continue to evolve, or be entirely replaced (or shared at run-time.
👉Use the Bridge pattern when:
1️⃣you want run-time binding of the implementation,
2️⃣you have a proliferation of classes resulting from a coupled interface and numerous implementations,
3️⃣you want to share an implementation among multiple objects,
4️⃣you need to map orthogonal class hierarchies.
👉Consequences include:
1️⃣decoupling the object's interface,
2️⃣improved extensibility (you can extend (i.e. subclass) the abstraction and implementation hierarchies independently),
3️⃣hiding details from clients.
👉Bridge is a synonym for the "handle/body" idiom. This is a design mechanism that encapsulates an implementation class inside of an interface class. The former is the body, and the latter is the handle. The handle is viewed by the user as the actual class, but the work is done in the body. "The handle/body class idiom may be used to decompose a complex abstraction into smaller, more manageable classes. The idiom may reflect the sharing of a single resource by multiple classes that control access to it (e.g. reference counting)."
@javaCode☕️
#Bridge_Design_Pattern
👉Check list
1️⃣Decide if two orthogonal dimensions exist in the domain. These independent concepts could be: abstraction/platform, or domain/infrastructure, or front-end/back-end, or interface/implementation.
2️⃣Design the separation of concerns: what does the client want, and what do the platforms provide.
3️⃣Design a platform-oriented interface that is minimal, necessary, and sufficient. Its goal is to decouple the abstraction from the platform.
4️⃣Define a derived class of that interface for each platform.
5️⃣Create the abstraction base class that "has a" platform object and delegates the platform-oriented functionality to it.
6️⃣Define specializations of the abstraction class if desired.
@javaCode☕️
👉Check list
1️⃣Decide if two orthogonal dimensions exist in the domain. These independent concepts could be: abstraction/platform, or domain/infrastructure, or front-end/back-end, or interface/implementation.
2️⃣Design the separation of concerns: what does the client want, and what do the platforms provide.
3️⃣Design a platform-oriented interface that is minimal, necessary, and sufficient. Its goal is to decouple the abstraction from the platform.
4️⃣Define a derived class of that interface for each platform.
5️⃣Create the abstraction base class that "has a" platform object and delegates the platform-oriented functionality to it.
6️⃣Define specializations of the abstraction class if desired.
@javaCode☕️
#Bridge_Design_Pattern
👉Rules of thumb
▪️Adapter makes things work after they're designed; Bridge makes them work before they are.
▪️Bridge is designed up-front to let the abstraction and the implementation vary independently. Adapter is retrofitted to make unrelated classes work together.
▪️State, Strategy, Bridge (and to some degree Adapter) have similar solution structures. They all share elements of the "handle/body" idiom. They differ in intent - that is, they solve different problems.
▪️The structure of State and Bridge are identical (except that Bridge admits hierarchies of envelope classes, whereas State allows only one). The two patterns use the same structure to solve different problems: State allows an object's behavior to change along with its state, while Bridge's intent is to decouple an abstraction from its implementation so that the two can vary independently.
▪️If interface classes delegate the creation of their implementation classes (instead of creating/coupling themselves directly), then the design usually uses the Abstract Factory pattern to create the implementation objects.
@javaCode☕️
👉Rules of thumb
▪️Adapter makes things work after they're designed; Bridge makes them work before they are.
▪️Bridge is designed up-front to let the abstraction and the implementation vary independently. Adapter is retrofitted to make unrelated classes work together.
▪️State, Strategy, Bridge (and to some degree Adapter) have similar solution structures. They all share elements of the "handle/body" idiom. They differ in intent - that is, they solve different problems.
▪️The structure of State and Bridge are identical (except that Bridge admits hierarchies of envelope classes, whereas State allows only one). The two patterns use the same structure to solve different problems: State allows an object's behavior to change along with its state, while Bridge's intent is to decouple an abstraction from its implementation so that the two can vary independently.
▪️If interface classes delegate the creation of their implementation classes (instead of creating/coupling themselves directly), then the design usually uses the Abstract Factory pattern to create the implementation objects.
@javaCode☕️