Update memento description
This commit is contained in:
34
README.md
34
README.md
@@ -32,7 +32,7 @@ Chain length/performance issues - in theory you could see a chain that is too bi
|
|||||||
1. Execute first that matches the condition and exit -> Get one to process the request, or get the type of object
|
1. Execute first that matches the condition and exit -> Get one to process the request, or get the type of object
|
||||||
2. Execute all elements of chain until the condition does not match -> Execute all validators until one invalidates the request
|
2. Execute all elements of chain until the condition does not match -> Execute all validators until one invalidates the request
|
||||||
3. Always execute all handlers
|
3. Always execute all handlers
|
||||||
4. Instead of each handler, having a successor, you could have each handler have a list of successors, and have it's policy what handlers to execute
|
4. Tree of responssibility -> Instead of each handler, having a successor, you could have each handler have a list of successors, and have it's policy what handlers to execute
|
||||||
|
|
||||||
### f. Examples described:
|
### f. Examples described:
|
||||||
* Purchase example:
|
* Purchase example:
|
||||||
@@ -153,6 +153,7 @@ Some use the term container, some use the term aggregate, is one and the same th
|
|||||||
* Having a list of files, some bigger than other, get the files that have content
|
* Having a list of files, some bigger than other, get the files that have content
|
||||||
* Created IEnmuerator using yield return
|
* Created IEnmuerator using yield return
|
||||||
|
|
||||||
|
|
||||||
4. Mediator pattern
|
4. Mediator pattern
|
||||||
------------------
|
------------------
|
||||||
|
|
||||||
@@ -160,19 +161,24 @@ Some use the term container, some use the term aggregate, is one and the same th
|
|||||||
With the mediator pattern, communication between objects is encapsulated with a mediator object.
|
With the mediator pattern, communication between objects is encapsulated with a mediator object.
|
||||||
Objects no longer communicate directly with each other, but instead communicate through the mediator.
|
Objects no longer communicate directly with each other, but instead communicate through the mediator.
|
||||||
This reduces the dependencies between communicating objects, thereby lowering the coupling.
|
This reduces the dependencies between communicating objects, thereby lowering the coupling.
|
||||||
|
|
||||||
### b. When to use Mediator pattern
|
### b. When to use Mediator pattern
|
||||||
* A collection of interacting objects whose interaction needs simplification
|
* A collection of interacting objects whose interaction needs simplification
|
||||||
* When you need to monitor/audit the communication between objects
|
* When you need to monitor/audit the communication between objects
|
||||||
* When building UI components -> High level components mediate the communication between subcomponents
|
* When building UI components -> High level components mediate the communication between subcomponents
|
||||||
* When you want to do publish/subscribe -> publish subscribe is a pattern implemented using mediator
|
* When you want to do publish/subscribe -> publish subscribe is a pattern implemented using mediator
|
||||||
|
|
||||||
### c. Actors
|
### c. Actors
|
||||||
* Mediator: interface of the mediator, that defines what messages does it mediate between colleagues.
|
* Mediator: interface of the mediator, that defines what messages does it mediate between colleagues.
|
||||||
* Concrete Mediator: implementation of the interface
|
* Concrete Mediator: implementation of the interface
|
||||||
* Colleague: objects that communicate through the mediator
|
* Colleague: objects that communicate through the mediator
|
||||||
|
|
||||||
### d. Pitfalls
|
### d. Pitfalls
|
||||||
* Mediator can become ver complicated as more colleagues are handled.
|
* Mediator can become ver complicated as more colleagues are handled.
|
||||||
|
|
||||||
### e. Flavors
|
### e. Flavors
|
||||||
Don't know
|
* Don't know
|
||||||
|
|
||||||
### f. Examples
|
### f. Examples
|
||||||
* StockExchange example: Starting class: StockExchange.StockExchangeExample
|
* StockExchange example: Starting class: StockExchange.StockExchangeExample
|
||||||
* Have multiple traders Buy/Sell actions from stock exchange (simplified)
|
* Have multiple traders Buy/Sell actions from stock exchange (simplified)
|
||||||
@@ -185,15 +191,39 @@ Don't know
|
|||||||
* Many to many relationship in code: No running class, only the models: User-UserToGroup-Group
|
* Many to many relationship in code: No running class, only the models: User-UserToGroup-Group
|
||||||
* Other possible examples that are not yet implemented -> Chat application, GUI Library, Taxi/Taxi Center
|
* Other possible examples that are not yet implemented -> Chat application, GUI Library, Taxi/Taxi Center
|
||||||
|
|
||||||
|
|
||||||
5. Memento pattern
|
5. Memento pattern
|
||||||
------------------
|
------------------
|
||||||
|
|
||||||
### a. Pattern description
|
### a. Pattern description
|
||||||
|
The memento pattern is a software design pattern that provides the ability to restore an object to its previous state (undo via rollback).
|
||||||
|
|
||||||
### b. When to use Memento pattern
|
### b. When to use Memento pattern
|
||||||
|
* When you need to be able to track the state of an object,or/and restore previous states as needed
|
||||||
|
* When you cannot use simple operation undo/redo, by saving the commands (when there are side effects to the operations) - example translation
|
||||||
|
* Database transactions.
|
||||||
|
|
||||||
### c. Actors
|
### c. Actors
|
||||||
|
* Originator: object that we want to save. It will create the actual memento.
|
||||||
|
* Caretaker: keeps the mementos
|
||||||
|
* Memento: (Magic cookie) internal state of the object
|
||||||
|
|
||||||
### d. Pitfalls
|
### d. Pitfalls
|
||||||
|
* if keeping the state/restoring the state is expensive, the memento pattern might not be fit
|
||||||
|
* Exposing information only to memento so that we don't brake encapsulation
|
||||||
|
* It may be difficult to ensure the Originator can access a Memento's state
|
||||||
|
* Caretaker has to manage Mementos, but doesn't know their size.
|
||||||
|
* Needs to consider deleting history, or how much history it should keep
|
||||||
|
|
||||||
### e. Flavors
|
### e. Flavors
|
||||||
|
* Classical memento: Save each time the entire state
|
||||||
|
* Iterative memento: Save the changes that occured from the previous state(delta), instead of saving the entire state again, (e.g. Git)
|
||||||
|
|
||||||
### f. Examples
|
### f. Examples
|
||||||
|
* Employee example1: Starting class: Employee.EmployeeExample
|
||||||
|
* Save the state of an employee using a class EmployeeMememento. Keep all the the updates that were made to the Employee.
|
||||||
|
* Employee example2: Starting class: EmployeeSerialized.EmployeeSerializedExample
|
||||||
|
* Save the state of an employee by serializing Employee. Keep only 10 updates of the employee, the rest will be lost
|
||||||
|
|
||||||
6. Observer pattern
|
6. Observer pattern
|
||||||
------------------
|
------------------
|
||||||
|
|||||||
@@ -61,7 +61,7 @@ Memento: (Magic cookie) internal state of the object";
|
|||||||
{
|
{
|
||||||
return @"
|
return @"
|
||||||
Can be expensive
|
Can be expensive
|
||||||
Deltes/history
|
Needs to consider deleting history, or how much history it should keep
|
||||||
Exposing information only to memento so that we don't brake encapsulation";
|
Exposing information only to memento so that we don't brake encapsulation";
|
||||||
}
|
}
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user