Category Archives: Java Design Patterns

Java Design Patterns

Proxy Pattern

Proxy Pattern:

“Proxy is a structural design pattern that lets you provide a substitute or placeholder for another object. A proxy controls access to the original object, allowing you to perform something either before or after the request gets through to the original object.

A credit card is a proxy for a bank account, which is a proxy for a bundle of cash. Both implement the same interface: they can be used for making a payment. A consumer feels great because there’s no need to carry loads of cash around. A shop owner is also happy since the income from a transaction gets added electronically to the shop’s bank account without the risk of losing the deposit or getting robbed on the way to the bank.

Click on the images to see them clearly.

In the above UML class diagram, the Proxy class implements the Subject interface so that it can act as substitute for Subject objects. It maintains a reference (realSubject) to the substituted object (RealSubject) so that it can forward requests to it (realSubject.operation()).

UML Class Diagram

https://refactoring.guru/design-patterns/proxy

https://en.wikipedia.org/wiki/Proxy_pattern

Java: Facade Design Pattern

Façade Pattern

“Facade is a structural design pattern that provides a simplified interface to a library, a framework, or any other complex set of classes.”

“When you call a shop to place a phone order, an operator is your facade to all services and departments of the shop. The operator provides you with a simple voice interface to the ordering system, payment gateways, and various delivery services.”

For a clear view, click on the images (images are from Wikipedia)

Ref: https://refactoring.guru/design-patterns/facade

https://en.wikipedia.org/wiki/Facade_pattern

Java : Decorator Design pattern

Decorator Design pattern:

Decorator is a structural design pattern that lets you attach new behaviors to objects by placing these objects inside special wrapper objects that contain the behaviors.

Example:

Assume: A notifier class/object can send only email messages. But the application at a later time may want to use text/SMS, FB, or similar messages. With decorator pattern: decorate the Notifier class with other behaviours such as send SMS, send fb message, send twitter message (i.e. may create additional classes/objects (create link to original notifier class with interfaces/inheritance and aggregations/compositions) ). Then the client can use the original notifier class/object but dynamically point to the other classes/objects and use the corresponding sendMessage() method/behaviour for SMS, Text, FB, Twitter or similar messaging/notification.

Note: Inheritance/subclasses can be a choice but they have limitations. Aggregations/Compositions/interfaces will be used for the purpose of Decorator pattern.

Note: “When does a simple wrapper become the real decorator? As I mentioned, the wrapper implements the same interface as the wrapped object. That’s why from the client’s perspective these objects are identical.

Ref: https://refactoring.guru/design-patterns/decorator

https://en.wikipedia.org/wiki/Decorator_pattern