2.1 State
State is a behavioral design pattern. It is used in those cases when, during the execution of the program, the object must change its behavior depending on its state.
The pattern consists of 3 blocks:
Context is a class whose objects should change their behavior depending on the state.
State is the interface that each of the concrete states must implement. Through this interface, the Context object interacts with the state by delegating method calls to it. The interface should contain means for feedback to the object whose behavior is to be changed.
For this, an event is used (pattern Publisher - Subscriber). This is necessary in order to replace the state object during the execution of the program when events occur. There may be cases where the Context itself periodically polls the state object for a transition.
ConcreteState1, ConcreteState2 - classes of concrete states. Should contain information on under what conditions and in what states the object can pass from the current state. For example, from ConcreteState1, an object can go to ConcreteState2 and ConcreteState3, and from ConcreteState2 back to ConcreteState1, and so on. The object of one of them must contain the Context when created.
For example, you are writing a game where a character can run, swim and fly. If your character got into the water, then it is reasonable to limit his behavior in the water: now he cannot shoot, but he still has some actions: swim forward, right, left, etc.
The state of your character can be described by a State object, which has methods that can be called and that will do something. And after your character got into the water, you just change the reference to another State object inside it - and it changes its state.
2.2 strategy
Strategy is a behavioral design pattern for defining a family of algorithms, encapsulating each one, and making them interchangeable. This allows you to choose an algorithm by defining the appropriate class.
The Strategy pattern allows you to change the selected algorithm regardless of the client objects that use it.
The Strategy pattern allows you to use different business rules or algorithms depending on the context. It is used in cases where different algorithms must be used in the same place depending on the current state of the system (or its environment).
Strengths:
- encapsulation of the implementation of various algorithms, the system becomes independent of possible changes in business rules;
- calling all algorithms in one standard way;
- not using switches and/or conditional statements.
This pattern is somewhat similar to the State pattern, but here the emphasis is not on the state, but on the behavior. Let's say a character in your game can change weapons. Then when changing weapons, you can simply change the reference to the object that describes how this weapon works.
2.3 Template Method
Abstract class (abstract class) - defines the abstract operations that are replaced in the heirs to implement the steps of the algorithm; implements a template method that defines the skeleton of the algorithm. The template method calls the replaced and other operations defined in the Abstract class.
Concrete class (concrete class) - implements the replaced operations in the way necessary for implementation. The Concrete class assumes that the invariant steps of the algorithm will be performed in the AbstractClass.
This pattern is often used when needed:
- Single use of the invariant part of the algorithm, leaving the changing part at the discretion of the heirs.
- Localization and isolation of code common to several classes to avoid duplication.
- Allow inheritors to extend code only in certain places.
Yes, this pattern describes the use of a pair: an abstract class and its implementation.
2.4 Chain of Responsibility
Chain of responsibility is a behavioral design pattern designed to organize levels of responsibility in a system.
The template is recommended for use in conditions where:
- in the developed system there is a group of objects that can process messages of a certain type;
- all messages must be processed by at least one system object;
- messages in the system are processed according to the “process it yourself or pass it on to another” scheme, that is, some messages are processed at the level where they were received, while others are forwarded to objects of another level.
2.5 Memento
Keeper (Memento) is a behavioral design pattern that allows you to fix and save the internal state of an object without violating encapsulation so that it can be restored to this state later.
The Guardian pattern is used when:
- it is necessary to save a snapshot of the state of the object (or part of it) for subsequent restoration;
- The direct interface for getting the state of an object exposes implementation details and breaks object encapsulation.
GO TO FULL VERSION