Please enable JavaScript.

Coggle requires JavaScript to display documents.

Design patterns (behavioral (Iterator (Compared to other patterns (You can…

- - - - Lets you build an invoker class that doesn't know anything about the logic each Command object contains; it simply knows that it should call the execute() method on an object when an event occurs.
      - Used when need to issue requests to objects without knowing anything about the operation being requested or the receiver of the request.
      - decouples the object that invokes the action from the object that performs the action so that’s why the pattern is commonly known as the producer-consumer pattern.
      - used for undo operations (like math operations: +10 and then -10)
      - Encapsulate a request as an object, thereby letting you parametrize clients with different requests, queue or log requests, and support undoable operations.
      - Promote "invocation of a method on an object" to full object status, aims to encapsulate a request, not receiver nor sender; wraps the action in an object so we move a method from the class and actually make it a new class.
      - You can use Command to convert any operation into an object. The operation’s parameters become fields of that object. The conversion lets you defer execution of the operation, queue it, store the history of commands, send commands to remote services, etc
    - - Invoker
        
        An invoker is an object that knows how to execute a given command but doesn’t know how the command has been implemented. It only knows the command’s interface.
        
        Invoker - holds reference(s) to ICommand interface. ICommand implementation(s) should be assigned to interface instance(s) in constructor - THAT'S HOW WE OMIT HARD-CODING, otherwise use instance method.
      - Command object
        
        You can create MacroCommands - Commands executing multiple Commands.
        
        command is an object whose role is to store all the information required for executing an action, including the method to call, the method arguments, and the object (known as the receiver) that implements the method.
        
        Commands can be shared across different Invokers even though they have completely different interfaces
      - Receiver
        
        A receiver is an object that performs a set of cohesive actions. It’s the component that performs the actual action when the command’s execute() method is called.
      - Command Interface
        
        ICommand - interface, has 2 methods: execute() and unexecute(); is implemented by Commands. Commands have reference to receiver which may for example be a lamp with methods on() and off().
      - Client
        
        A client is an object that controls the command execution process by specifying what commands to execute and at what stages of the process to execute them.
        
        creates a ConcreteCommand object
    - - https://www.youtube.com/watch?v=9qA5kw8dcSU
      - https://www.baeldung.com/java-command-pattern
    - - Just the same way we can consider the example of an auto-repair shop. People come in with different cars that have different problems. The person at the front desk takes their information and places the car in a queue for repair. The information on the order is encapsulated in the paper the car owner will use when he comes back to pick up the fixed car. At some point the car will become the first item in the queue and the mechanic will repair it. Just as in the example above, the Client is the customer. The Invoker is the person at the front desk that takes the information on the car and its problems, the ConcreteCommand is the request for fixing the car and the Receiver is the mechanic.
      - The example of the meal order at a restaurant is a very good one when trying to explain better how the pattern works:
        The waiter (Invoker) takes the order from the customer on his pad. The order is then queued for the order cook and gets to the cook (Receiver) where it is processed.
        In this case the actors in the scenario are the following: The Client is the customer. He sends his request to the receiver through the waiter, who is the Invoker. The waiter encapsulates the command (the order in this case) by writing it on the check and then places it, creating the ConcreteCommand object which is the command itself. The Receiver will be the cook that, after completing work on all the orders that were sent to him before the command in question, starts work on it. Another noticeable aspect of the example is the fact that the pad for the orders does not support only orders from the menu, so it can support commands to cook many different items.
      - Invoker - remote controller
        
        Command - TurnOnLight, ChangeColor, Dim
        
        Receiver - Lamp, LightStrip etc.
      - java.lang.Runnable
    - - Command encapsulates action while Strategy encapsulates algorithm, it's a difference between what to do (or rather who call) vs how to do it.
      - Handlers in Chain of Responsibility can be implemented as Commands. In this case, you can execute a lot of different operations over the same context object, represented by a request.
        However, there’s another approach, where the request itself is a Command object. In this case, you can execute the same operation in a series of different contexts linked into a chain.
      - You can use Command and Memento together when implementing “undo”. In this case, commands are responsible for performing various operations over a target object, while mementos save the state of that object just before a command gets executed.
      - You can treat Visitor as a powerful version of the Command pattern. Its objects can execute operations over various objects of different classes.
      - Prototype can help when you need to save copies of Commands into history.
  - - - java.util.logging.Logger or Spring Security's filter chain.
      - Authentication -> Authorization -> Sanitize data -> Cache check -> Check for brute force attack from same IP -> ... -> get data.
      - When a user clicks a button, the event propagates through the chain of GUI elements that starts with the button, goes along its containers (like forms or panels), and ends up with the main application window. The event is processed by the first element in the chain that’s capable of handling it. This example is also noteworthy because it shows that a chain can always be extracted from an object tree.
    - - cons
        
        runtime configuration is risk - great flexibility comes with inability to test all of the possible configurations
        
        chain length performance issues.
        
        no handlig/handler guarantee - request may not be executed
      - pros
        
        Open/Closed Principle. You can introduce new handlers into the app without breaking the existing client code.
        
        Single Responsibility Principle. You can decouple classes that invoke operations from classes that perform operations.
    - - Commands and Handlers should be uinque but
      - In contrary to Command, if handler doesn't know what to do with the request, it passes it on to the next jandler. Command encapsulates all of its functionality.
      - Commands are reversible. We can hold a history of executed commands.
      - With commands we have a higher level of certainty that our request will be served, CoR may just omit it.
      - Chain of Responsibility is often used in conjunction with Composite. In this case, when a leaf component gets a request, it may pass it through the chain of all of the parent components down to the root of the object tree.
      - Chain of Responsibility and Decorator have very similar class structures. Both patterns rely on recursive composition to pass the execution through a series of objects. However, there are several crucial differences.
        The CoR handlers can execute arbitrary operations independently of each other. They can also stop passing the request further at any point. On the other hand, various Decorators can extend the object’s behavior while keeping it consistent with the base interface. In addition, decorators aren’t allowed to break the flow of the request.
    - - Chain of Responsibility, Command, Mediator and Observer address various ways of connecting senders and receivers of requests:
        
        Chain of Responsibility passes a request sequentially along a dynamic chain of potential receivers until one of them handles it.
        
        Command establishes unidirectional connections between senders and receivers.
        
        Mediator eliminates direct connections between senders and receivers, forcing them to communicate indirectly via a mediator object.
        
        Observer lets receivers dynamically subscribe to and unsubscribe from receiving requests.
        
        Chain of Responsibility is often used in conjunction with Composite. In this case, when a leaf component gets a request, it may pass it through the chain of all of the parent components down to the root of the object tree.
      - Handlers in Chain of Responsibility can be implemented as Commands. In this case, you can execute a lot of different operations over the same context object, represented by a request.
        However, there’s another approach, where the request itself is a Command object. In this case, you can execute the same operation in a series of different contexts linked into a chain.
      - The CoR handlers can execute arbitrary operations independently of each other. They can also stop passing the request further at any point. On the other hand, various Decorators can extend the object’s behavior while keeping it consistent with the base interface. In addition, decorators aren’t allowed to break the flow of the request.
      - Chain of Responsibility and Decorator have very similar class structures. Both patterns rely on recursive composition to pass the execution through a series of objects. However, there are several crucial differences.
  - - - java.util.Pattern
      - used by compilers to parse source code.
      - used when defining AST (abstract syntax tree)
      - java.text.Format - used to represent locale specific content such as dates, numbers etc
      - Useful when defining rules or validation criteria for objects.
    - - Client builds a sentence of TerminalExpressions and NonTerminalExpressions.
      - Context contains information that is global to interpreter.
      - TerminalExpressions and NonTerminalExpressions implement (or inherit from) Expression, which is an interface (or an abstract class) that contains interpret(Context context) method.
      - TerminalExpressions can be interpreted in their current form.
      - NonTerminalExpressions (CompoundExpression) need to be reevaluated (they contain TerminalExpressions).
      - Interpreter suggests modeling the domain with a recursive grammar. Each rule in the grammar is either a 'composite' (a rule that references other rules) or a terminal (a leaf node in a tree structure). Interpreter relies on the recursive traversal of the Composite pattern to interpret the 'sentences' it is asked to process.
    - - Considered in its most general form (i.e. an operation distributed over a class hierarchy based on the Composite pattern), nearly every use of the Composite pattern will also contain the Interpreter pattern. But the Interpreter pattern should be reserved for those cases in which you want to think of this class hierarchy as defining a language.
      - Interpreter can use State to define parsing contexts.
      - The abstract syntax tree of Interpreter is a Composite (therefore Iterator and Visitor are also applicable).
      - Terminal symbols within Interpreter's abstract syntax tree can be shared with Flyweight.
  - - - Captures state, each of which is independent . This pattern is focused on creating a history .
      - The classic implementation of the pattern relies on support for nested classes. This lets the originator access the fields and methods of the memento, even though they’re declared private.
      - The Memento pattern lets you make full copies of an object’s state, including private fields, and store them separately from the object. While most people remember this pattern thanks to the “undo” use case, it’s also indispensable when dealing with transactions (i.e., if you need to roll back an operation on error).
      - We can simplify the originator’s code by letting the caretaker maintain the history of the originator’s state.
      - Used to externalize object's state, usually to provide rollback functionality without revealing the details of its implementation.
    - - Originator - object of which state we want to keep. Creates an actual memento. Has methods saveMemento() and revert(EmployeeMemento memento).
      - Caretaker - manages copies (mementos) that we've just created. Think of it as list of undos in your menu.
        Knows why and when the originator needs to be saved and how to restore it. Has 2 mthods : save(Employee emp) and revert(Employee emp).
      - Memento - copy of the originator that we want to store, is a value object. Consists of a magic cookie - combination of the fields needed to recreate the state of the object. Only originator has access to its state. It’s a common practice to make the memento immutable and pass it the data only once, via the constructor.
    - - Serializable interface in Java; we can create an object and then implement serialize() method and write this object to the file system.
      - java.util.Date
    - - can be expensive i.e. object can be large and a lot of them can be stored.
      - be careful with exposing originator's information
      - Most dynamic programming languages, such as PHP, Python and JavaScript, can’t guarantee that the state within the memento stays untouched.
    - - Comparison to Command: Command is almost identical to Memento but it is focused more on request than on a state of an object and although history is available it is rarely used.
      - You can use Command and Memento together when implementing “undo”. In this case, commands are responsible for performing various operations over a target object, while mementos save the state of that object just before a command gets executed.
      - You can use Memento along with Iterator to capture the current iteration state and roll it back if necessary.
      - Sometimes Prototype can be a simpler alternative to Memento. This works if the object, the state of which you want to store in the history, is fairly straightforward and doesn’t have links to external resources, or the links are easy to re-establish.
  - - - Mediator knows about colleagues rather than colleagues knowing about each other. Colleagues know about mediator.
      - Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.
      - Use the pattern when you can’t reuse a component in a different program because it’s too dependent on other components.
      - After you apply the Mediator, individual components become unaware of the other components. They could still communicate with each other, albeit indirectly, through a mediator object. To reuse a component in a different app, you need to provide it with a new mediator class
      - Use the Mediator when you find yourself creating tons of component subclasses just to reuse some basic behavior in various contexts.
      - Since all relations between components are contained within the mediator, it’s easy to define entirely new ways for these components to collaborate by introducing new mediator classes, without having to change the components themselves
    - - courier
      - chat room
      - taxi radio (centrala)
      - java examples: java.util.timer
    - - Facade Pattern - a simplified mediator becomes a facade pattern if the mediator is the only active class and the colleagues are passive classes. A facade pattern is just an implementation of the mediator pattern where mediator is the only object triggering and invoking actions on passive colleague classes. The Facade is being call by some external classes.
      - Adapter Pattern - the mediator patter just "mediate" the requests between the colleague classes. It is not supposed to change the messages it receives and sends; if it alters those messages then it is an Adapter pattern.
      - Observer Pattern - the observer and mediator are similar patterns, solving the same problem. The main difference between them is the problem they address. The observer pattern handles the communication between observers and subjects or subject. It's very probable to have new observable objects added. On the other side in the mediator pattern the mediator class is the the most likely class to be inherited.
      - Finally, the facade is an structural pattern, that is it describes the composition of the objects, while the mediator is an behavioral, that is , it describes the way the objects interact.
      - Chain of Responsibility, Command, Mediator and Observer address various ways of connecting senders and receivers of requests:
        
        Chain of Responsibility passes a request sequentially along a dynamic chain of potential receivers until one of them handles it.
        
        Command establishes unidirectional connections between senders and receivers.
        
        Mediator eliminates direct connections between senders and receivers, forcing them to communicate indirectly via a mediator object.
        
        Observer lets receivers dynamically subscribe to and unsubscribe from receiving requests.
      - The difference between Mediator and Observer is often elusive. In most cases, you can implement either of these patterns; but sometimes you can apply both simultaneously. Let’s see how we can do that.
        The primary goal of Mediator is to eliminate mutual dependencies among a set of system components. Instead, these components become dependent on a single mediator object. The goal of Observer is to establish dynamic one-way connections between objects, where some objects act as subordinates of others.
        There’s a popular implementation of the Mediator pattern that relies on Observer. The mediator object plays the role of publisher, and the components act as subscribers which subscribe to and unsubscribe from the mediator’s events. When Mediator is implemented this way, it may look very similar to Observer.
        When you’re confused, remember that you can implement the Mediator pattern in other ways. For example, you can permanently link all the components to the same mediator object. This implementation won’t resemble Observer but will still be an instance of the Mediator pattern.
        Now imagine a program where all components have become publishers, allowing dynamic connections between each other. There won’t be a centralized mediator object, only a distributed set of observers.
    - - pros
        
        Single Responsibility Principle. You can extract the communications between various components into a single place, making it easier to comprehend and maintain.
        
        Open/Closed Principle. You can introduce new mediators without having to change the actual components.
        
        You can reduce coupling between various components of a program.
        
        You can reuse individual components more easily.
      - cons
        
        Over time a mediator can evolve into a God Object.
  - - - Observer is OneToMany while Mediator is ManyToMany and handles complex communication in a more direct model than pub/sub.
      - The Observer pattern: Defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.
        The Mediator pattern: Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.
      - Observer is like Instagram or Twitter, while Mediator is like TaxiCenter or Flight Tower.
    - - pros
        
        Open/Closed Principle. You can introduce new subscriber classes without having to change the publisher’s code (and vice versa if there’s a publisher interface).
        
        You can establish relations between objects at runtime.
      - cons
        
        Subscribers are notified in random order.
  - - - Separate an algorithm and a logic from an object structure, put it into ConcreteVisitor class, e.g. move shipping cost logic from all of the objects implementing certain interface and put into PartsShippingVisitor.
    - - cons
        
        You may build flexibility that is never used wchich leads to over-architecting.
        
        Each Visitor may not need to implement all of its methods so use of Adapter may be needed.
        
        Visitors might lack the necessary access to the private fields and methods of the elements that they’re supposed to work with.
        
        You need to update all visitors each time a class gets added to or removed from the element hierarchy.
      - pros
        
        OCP, SRP
        
        A visitor object can accumulate some useful information while working with various objects. This might be handy when you want to traverse some complex object structure, such as an object tree, and apply the visitor to each object of this structure.
    - - You can treat Visitor as a powerful version of the Command pattern. Its objects can execute operations over various objects of different classes.
      - You can use Visitor to execute an operation over an entire Composite tree.
      - You can use Visitor along with Iterator to traverse a complex data structure and execute some operation over its elements, even if they all have different classes.
  - - - cons
        
        unidirectional
        
        no access to index
        
        Using an iterator may be less efficient than going through elements of some specialized collections directly.
        
        Applying the pattern can be an overkill if your app only works with simple collections.
      - pros
        
        efficient with large collections
        
        SRP, OCP
        
        You can iterate over the same collection in parallel because each iterator object contains its own iteration state. For the same reason, you can delay an iteration and continue it when needed.
    - - You can use Iterators to traverse Composite trees.
      - You can use Factory Method along with Iterator to let collection subclasses return different types of iterators that are compatible with the collections.
      - You can use Memento along with Iterator to capture the current iteration state and roll it back if necessary.
      - You can use Visitor along with Iterator to traverse a complex data structure and execute some operation over its elements, even if they all have different classes.
  - - - Strategy is like Template Method except in its granularity. Template Method uses inheritance to vary part of an algorithm. Strategy uses delegation to vary the entire algorithm. Strategy modifies the logic of individual objects. Template Method modifies the logic of an entire class. Template Method works at the class level, so it’s static. Strategy works on the object level, letting you switch behaviors at runtime.
      - Factory Method is a specialization of Template Method. At the same time, a Factory Method may serve as a step in a large Template Method.
    - - Java
        
        java.util.Collections.sort
  - - - Use the State pattern when you have an object that behaves differently depending on its current state, the number of states is enormous, and the state-specific code changes frequently.
      - The pattern suggests that you extract all state-specific code into a set of distinct classes. As a result, you can add new states or change existing ones independently of each other, reducing the maintenance cost. SRP & OCP.
      - object's behavior is a function of its state
      - State is a behavioral design pattern that lets an object alter its behavior when its internal state changes. It appears as if the object changed its class.
      - allow theMain idea is to allow object for changing its behavior without changing its class.
    - - The buttons and switches in your smartphone behave differently depending on the current state of the device: When the phone is unlocked, pressing buttons leads to executing various functions. When the phone is locked, pressing any button leads to the unlock screen. When the phone’s charge is low, pressing any button shows the charging screen.
      - The State pattern allows an object to change its behavior when its internal state changes. This pattern can be observed in a vending machine. Vending machines have states based on the inventory, amount of currency deposited, the ability to make change, the item selected, etc. When currency is deposited and a selection is made, a vending machine will either deliver a product and no change, deliver a product and change, deliver no product due to insufficient currency on deposit, or deliver no product due to inventory depletion.
      - The State pattern is closely related to the concept of a Finite-State Machine. The main idea is that, at any given moment, there’s a finite number of states which a program can be in. Within any unique state, the program behaves differently, and the program can be switched from one state to another instantaneously. However, depending on a current state, the program may or may not switch to certain other states. These switching rules, called transitions, are also finite and predetermined.State machines are usually implemented with lots of conditional operators (if or switch) that select the appropriate behavior depending on the current state of the object. Usually, this “state” is just a set of values of the object’s fields.
    - - vs strategy
        
        State can be considered as an extension of Strategy. Both patterns are based on composition: they change the behavior of the context by delegating some work to helper objects. Strategy makes these objects completely independent and unaware of each other. However, State doesn’t restrict dependencies between concrete states, letting them alter the state of the context at will.
        
        This structure may look similar to the Strategy pattern, but there’s one key difference. In the State pattern, the particular states may be aware of each other and initiate transitions from one state to another, whereas strategies almost never know about each other.
      - Bridge, State, Strategy (and to some degree Adapter) have very similar structures. Indeed, all of these patterns are based on composition, which is delegating work to other objects. However, they all solve different problems. A pattern isn’t just a recipe for structuring your code in a specific way. It can also communicate to other developers the problem the pattern solves.
      - State objects are often Singletons.
      - Flyweight explains when and how State objects can be shared.
      - Interpreter can use State to define parsing contexts.
      - 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.
    - - Example
    - - Context stores a reference to one of the concrete state objects and delegates to it all state-specific work. The context communicates with the state object via the state interface. The context exposes a setter for passing it a new state object.
      - The State interface declares the state-specific methods. These methods should make sense for all concrete states because you don’t want some of your states to have useless methods that will never be called.
      - Concrete States provide their own implementations for the state-specific methods. To avoid duplication of similar code across multiple states, you may provide intermediate abstract classes that encapsulate some common behavior.
        State objects may store a backreference to the context object. Through this reference, the state can fetch any required info from the context object, as well as initiate state transitions.
      - Both context (object having state) and concrete states can set the next state of the context and perform the actual state transition by replacing the state object linked to the context.
      - Nest the state classes into the context class, but only if your programming language supports nesting classes if you need access to private content.
    - - pros
        
        Simplifies cyclomatic complexity and removes spaghetti code with if/else statements.
        
        The State pattern lets you compose hierarchies of state classes and reduce duplication by extracting common code into abstract base classes.
        
        Use the pattern when you have a class polluted with massive conditionals that alter how the class behaves according to the current values of the class’s fields. The State pattern lets you extract branches of these conditionals into methods of corresponding state classes
  - - - java
        
        java.util.Comparator
      - real-life
        
        Modes of transportation to an airport is an example of a Strategy : by bus, by car, by bike, on feet.
    - - The context isn’t responsible for selecting an appropriate algorithm for the job. Instead, the client passes the desired strategy to the context. In fact, the context doesn’t know much about strategies. It works with all strategies through the same generic interface, which only exposes a single method for triggering the algorithm encapsulated within the selected strategy.This way the context becomes independent of concrete strategies, so you can add new algorithms or modify existing ones without changing the code of the context or other strategies.
      - UML diagram is identical to State
      - The context doesn’t know what type of strategy it works with or how the algorithm is executed.
      - The Client creates a specific strategy object and passes it to the context. The context exposes a setter which lets clients replace the strategy associated with the context at runtime.
      - The context may define an interface which lets the strategy access its data.
      - Client knows about strategies but strategies don't know about each other. Eliminates if/else statements.
    - - pros
        
        You can swap algorithms used inside an object at runtime.
        
        You can isolate the implementation details of an algorithm from the code that uses it.
        
        You can replace inheritance with composition.
        
        Open/Closed Principle. You can introduce new strategies without having to change the context.
    - - Strategy lets you change the guts of an object. Decorator lets you change the skin.
      - 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.
      - Strategy objects often make good Flyweights.
- - - - public class ProductFactory{ public Product createProduct(String ProductID){ if (id==ID1) return new OneProduct(); if (id==ID2) return return new AnotherProduct(); ... // so on for the other Ids return null; //if the id doesn't have any of the expected values } ... }
      - intent
        
        creates objects without exposing the instantiation logic to the client.
        
        refers to the newly created object through a common interface
      - The client uses the products as abstract products without being aware about their concrete implementation.
      - factory class is usually used as a singleton
    - - The Simple factory pattern describes a class that has one creation method with a large conditional that based on method parameters chooses which product class to instantiate and then return.
      - People usually confuse simple factories with a general factories or with one of the creational design patterns. In most cases, a simple factory is an intermediate step of introducing Factory Method or Abstract Factory patterns.
      - class UserFactory { public static function create($type) { switch ($type) { case 'user': return new User(); case 'customer': return new Customer(); case 'admin': return new Admin(); default: throw new Exception('Wrong user type passed.'); } } }
    - - The Factory Method is a creational design pattern that provides an interface for creating objects but allows subclasses to alter the type of an object that will be created.
      - If you have a creation method in base class and subclasses that extend it, you might be looking at the factory method.
      - abstract class Department { public abstract function createEmployee($id); public function fire($id) { $employee = $this->createEmployee($id); $employee->paySalary(); $employee->dismiss(); } } class ITDepartment extends Department { public function createEmployee($id) { return new Programmer($id); } } class AccountingDepartment extends Department { public function createEmployee($id) { return new Accountant($id); } }
      - Factory Method defines a method, which should be used for creating objects instead of direct constructor call (new operator). Subclasses can override this method to change the class of objects that will be created.
    - - a lot of people mix-up the abstract factory pattern with a simple factory class declared as abstract. Don’t do that!
      - The Abstract Factory is a creational design pattern that allows producing families of related or dependent objects without specifying their concrete classes.
- - - - Consumers encounter a Facade when ordering from a catalog. The consumer calls one number and speaks with a customer service representative. Like with sending email in TaxCare.
      - https://en.wikipedia.org/wiki/Facade_pattern
    - - Whereas Flyweight shows how to make lots of little objects, Facade shows how to make a single object represent an entire subsystem.
      - Abstract Factory can be used as an alternative to Facade to hide platform-specific classes.
      - While most textbook examples show the adapter adapting one class, you may need to adapt many classes to provide the interface a client is coded to. Likewise, a Facade may provide a simplified interface to a single class with a very complex interface but mainly it wraps few of them. The difference between the two is not in terms of how many classes they "wrap", it is in their intent.
      - Mediator is similar to Facade in that it abstracts functionality of existing classes. Mediator abstracts/centralizes arbitrary communications between colleague objects. It routinely "adds value", and it is known/referenced by the colleague objects. In contrast, Facade defines a simpler interface to a subsystem, it doesn't add new functionality, and it is not known by the subsystem classes.
      - Facade defines a new interface, whereas Adapter uses an old interface. Remember that Adapter makes two existing interfaces work together as opposed to defining an entirely new one.