Behavioral GOF

The Visitor Design Pattern is a behavioral pattern that allows you to define new operations on objects without changing their classes. It involves separating algorithms from the objects on which they operate. This pattern is useful when you need to perform operations on a group of objects with different types without altering their classes. Components of the Visitor Design Pattern: Visitor Interface: Declares a visit method for each type of element that can be visited. ConcreteVisitor: Implements the visitor interface and provides specific implementations of the visit methods. Element Interface: Declares an accept method that takes a visitor as an argument. ConcreteElement: Implements the element interface and defines the accept method to call the visitor’s visit method. Object Structure: Maintains a collection of elements and allows visitors to traverse them. Simple Example: Let’s consider a system where we have different types of documents, such as TextDocument and Spreadsheet, and we want to apply different operations to these documents without modifying their classes. ...

The Template Design Pattern is a behavioral pattern that defines the skeleton of an algorithm in a base class but allows subclasses to override specific steps of the algorithm without changing its structure. This pattern is useful when you have a common sequence of steps that are shared among multiple subclasses but may vary in certain details. Components of the Template Design Pattern: Abstract Class (Template): Defines the template method that outlines the algorithm’s structure and includes some default behavior. It may also include abstract methods that must be implemented by subclasses. Concrete Class: Implements the abstract methods defined in the abstract class and may override some steps of the algorithm. Simple Example: Let’s say we want to create a system for preparing beverages. The process of preparing a beverage involves several common steps, but the details may vary for different types of beverages. ...

The Observer Pattern is a behavioral design pattern used to define a one-to-many dependency between objects. When one object (the subject) changes its state, all dependent objects (observers) are notified and updated automatically. This pattern is commonly used in scenarios where changes in one part of an application need to be reflected in other parts without tightly coupling the components. Components of the Observer Pattern: Subject: The object that maintains a list of observers and notifies them of any changes. Observer: The interface or abstract class that defines the update method, which is called when the subject’s state changes. ConcreteSubject: A class that implements the Subject interface and maintains the state of interest. ConcreteObserver: A class that implements the Observer interface and updates itself based on the subject’s state. Simple Example in Java: Let’s create a weather monitoring system where a WeatherStation (subject) notifies multiple display devices (observers) of changes in weather conditions. ...

The Command Design Pattern is a behavioural design pattern that turns a request into a stand-alone object containing all the information about the request. This pattern allows you to parameterize objects with operations, delay the execution of an operation, or queue a request for execution. Simple Example: Imagine you have a remote control that can turn on and off a light. The Command Pattern can be used to encapsulate these operations into objects. ...

Imagine you’re sending a package. It goes through various checkpoints: sorting, security, customs, etc. Each checkpoint decides whether to handle the package or pass it on to the next. This is similar to the Chain of Responsibility pattern. Key Idea: A request is passed along a chain of objects. Each object decides whether to handle or pass the request to the next. This creates a loose coupling between the sender and receiver. Code Example // Handler.java public abstract class Handler { protected Handler nextHandler; public void setNextHandler(Handler nextHandler) { this.nextHandler = nextHandler; } public abstract void handleRequest(String request); } // ConcreteHandlerA.java public class ConcreteHandlerA extends Handler { @Override public void handleRequest(String request) { if (request.equals("A")) { System.out.println("ConcreteHandlerA handled the request."); } else if (nextHandler != null) { nextHandler.handleRequest(request); } } } // ConcreteHandlerB.java public class ConcreteHandlerB extends Handler { @Override public void handleRequest(String request) { if (request.equals("B")) { System.out.println("ConcreteHandlerB handled the request."); } else if (nextHandler != null) { nextHandler.handleRequest(request); } } } // ConcreteHandlerC.java public class ConcreteHandlerC extends Handler { @Override public void handleRequest(String request) { if (request.equals("C")) { System.out.println("ConcreteHandlerC handled the request."); } else if (nextHandler != null) { nextHandler.handleRequest(request); } } } // Main.java public class Main { public static void main(String[] args) { Handler handlerA = new ConcreteHandlerA(); Handler handlerB = new ConcreteHandlerB(); Handler handlerC = new ConcreteHandlerC(); handlerA.setNextHandler(handlerB); handlerB.setNextHandler(handlerC); handlerA.handleRequest("B"); handlerA.handleRequest("C"); handlerA.handleRequest("A"); } } Explanation Interface Handler: Defines the common interface for all handlers. Concrete Handlers: Implement the Handler interface and provide specific logic for handling requests. setNextHandler: Links handlers in the chain. handleRequest: Checks if the handler can process the request. If yes, it handles it. Otherwise, it passes the request to the next handler in the chain. Request: Represents the data associated with the request. Key Points The Handler interface provides a common contract for all handlers. Each concrete handler decides whether to handle or pass the request. The chain of handlers is created by linking them together. The client sends the request to the first handler in the chain.

The Interpreter Pattern is a design pattern used to define a grammatical representation of a language and provide an interpreter to deal with this grammar. It is useful for interpreting expressions in a language. Simple Explanation: Grammar: Define the rules of the language. Expressions: Create classes for each rule in the grammar. Context: Store information that might be needed during interpretation. Interpreter: Evaluate the expressions based on the rules. Example: Imagine a simple language for arithmetic expressions with numbers, addition, and multiplication. ...

The Iterator pattern provides a way to access the elements of a collection without exposing its internal structure. It promotes loose coupling between the collection and the code that uses it. Key Components: Iterator: Defines the interface for accessing and traversing elements in a collection. Concrete Iterator: Implements the Iterator interface and keeps track of the current position in the traversal. Aggregate: Defines an interface for creating an Iterator object. Concrete Aggregate: Implements the Aggregate interface and creates a Concrete Iterator. A Simple Example: Book Collection Let’s consider a collection of books. We want to iterate over these books without exposing how they are stored (array, linked list, etc.). ...

Understanding the Problem Imagine you’re building a text editor. Users often make mistakes or want to revert changes. How can you allow them to undo their actions without exposing the internal state of the document? The Memento Solution The Memento pattern provides a solution by capturing and storing the internal state of an object without violating encapsulation. Key Players: Originator: The object whose state needs to be saved (e.g., the text editor). Memento: An object that stores a snapshot of the originator’s state. Caretaker: An object that holds mementos and doesn’t access their contents. Example: Text Editor Let’s break down the pattern using a text editor example: ...

The Mediator pattern promotes loose coupling between objects by introducing a mediator that handles communication between them. This reduces dependencies and makes the system more flexible and maintainable. A Simple Chat Room Example Let’s consider a basic chat room application with multiple users. Instead of users communicating directly with each other, they’ll send messages to a chat room (the mediator), which then broadcasts the message to all users. 1. Define the Mediator Interface: interface ChatRoom { void registerUser(User user); void send(String msg, User user); } 2. Create a Concrete Mediator: class ChatRoomImpl implements ChatRoom { private List<User> users = new ArrayList<>(); @Override public void registerUser(User user) { users.add(user); } @Override public void send(String msg, User user) { for (User u : users) { if (u != user) { u.receive(msg); } } } } 3. Define the User Interface: interface User { void send(String msg); void receive(String msg); } 4. Create Concrete Users: class UserImpl implements User { private ChatRoom chatRoom; private String name; public UserImpl(ChatRoom chatRoom, String name) { this.chatRoom = chatRoom; this.name = name; } @Override public void send(String msg) { chatRoom.send(msg, this); } @Override public void receive(String msg) { System.out.println(name + " received: " + msg); } } 5. Client Code: public class MediatorPatternDemo { public static void main(String[] args) { ChatRoom chatRoom = new ChatRoomImpl(); User user1 = new UserImpl(chatRoom, "User1"); User user2 = new UserImpl(chatRoom, "User2"); chatRoom.registerUser(user1); chatRoom.registerUser(user2); user1.send("Hello, everyone!"); user2.send("Hi there!"); } } How it Works Users interact with the ChatRoom (mediator) to send messages. The ChatRoom broadcasts the message to all registered Users. Users receive the message and display it. Key Benefits: Loose coupling: Users don’t need to know about each other. Flexibility: Adding new users or changing the message handling logic is easier. Maintainability: The code is more organized and easier to understand.