Please enable JavaScript.

Coggle requires JavaScript to display documents.

Behavioral Pattern - Coggle Diagram

- - - - let traverse elements of a collection without exposing its underlying representation(list,stack,tree)
    - - not only about traversing through a collection, provide different kind of iterators based on our requirements
      - hides the actual implementation of traversal through the collection and client programs just use iterator methods
    - - extract the traversal behavior of a collection into a separate object
    - - when the collection has a complex data structure under the hood, but want to hide complexity from clients
      - to reduce duplication of the reversal code across the app
      - code to be able to traverse different data structures or when types of these structures are unknown beforehand
    - - single responsibility Principle: clean up the client code and the collections by extracting bulky traversal algorithms into separate classes
      - open/close principle: implement new types of collections and iterators and pass them to existing code without breaking anything
      - iterate over the same collection in parallel because each iterator object contains its own iteration state
      - can delay an iteration and continue it when needed
    - - can be an overkill if your app only works with simple collections
      - may be less efficient than going through elements of some specialized collections directly
  - - - this pattern lets define a subscription mechanism to notify multiple objects about any events that happens to the object they are observing
    - - used
        
        to get notification whenever there is any change in interested object's state
      - that watch on the state of another object are called Observer
      - the object that is being watched is called Subject
    - - when changes to the state if one object may require changing other objects, and the actual set of objects is unknown beforehand or changes dynamically
      - when some objects in app must observe others, but only for a limited time or in specific cases
    - - open/closed principle: can introduce new subscriber classes without having to change the publisher's code
      - can establish relations between objects at runtime
    - - subscribers are notified in random Oder
  - - - this pattern let separate algorithms from the objects on which they operate
    - - used to
        
        perform an operation on a group of similar kind of Objects
        
        move the operational logic from the objects to another class
    - - to perform an operation on all elements of a complex object structure
      - when a behavior makes sense only in some classes of a class hierarchy, but not in others
    - - open/closed principle: can introduce new behavior that can work with objects of different classes without changing these classes
      - single responsibility principle: move multiple versions of the same behavior into the same class
      - a visitor object can accumulate some useful information while working with various objects
    - - need to update all visitors each time a class gets added to or removed from the element hierarchy
      - visitors might lack the necessary access to the private fields and methods of the elements that they are supposed to work with
  - - - this pattern lets define a family of algorithms. Put each of them into a separate class, and make their objects interchangeable
    - - also known as policy pattern
      - define multiple algorithms and let client application pass the algorithm to be used as a parameter
    - - to use different variants of an algorithm within a object and be able to switch from one algorithm to another during runtime
      - Have a lot of similar classes that only differ in the way they execute some behavior
      - to isolate the business logic of a class from the implementation details of algorithms that may not be as important un the context of that logic
      - class has a massive conditional statement that switches between different variants of the same algorithm
    - - can swap algorithms used inside an object at runtime
      - can isolate the implementation details of an algorithm from the code that uses it
      - can replace inheritance with composition
      - open/closed principle: can introduce new strategies without having to change the text
    - - If only have a couple of algorithms and they rarely change,there's no real reason to overcomplicate the program with new classes and interfaces that come along with the pattern
      - clients must be aware of the differences between strategies to be able to select a proper one
      - a lot of modern programming languages have functional type support that lets implement different versions of an algorithm inside a set of anonymous functions. Then could use these functions exactly as used the strategy objects, but without bloating code with extra classes and interfaces
  - - - This pattern makes it possible to lessen chaotic object dependencies.
        The pattern prevents the objects from interacting directly and compels them to work together exclusively through a mediator object
    - - this pattern is very helpful in an enterprise application where multiple objects are interacting with each other
      - focuses on
        
        provide a mediator between objects for communication and help in implementing lose-coupling between objects
      - example
        
        Air traffic controller
    - - use when hard to change some of the classes because they are tightly coupled to a bunch of other classes
      - use when can't reuse a component in a different program because it's too dependent on other components
      - use when you find yourself creating tons of component subclass just to reuse some basic behavior in various contexts
    - - can extract the communications between various components into a single place, making it easier to comprehend and maintain
      - can introduce new mediators without having to change the actual components
      - can reduce coupling between various components of a program
      - can reuse individual components more easily
    - - over time a mediator can evolve into a God Object
  - - - this pattern let pass requests along a chain of handlers.Upon receiving a request,each handler decides either to process the request or to pass it to the next handler in the chain.
    - - to achieve loose coupling in software design where a request from the client is passed to a chain of objects to process them
    - - transforming particular behaviors into stand-alone objects called handlers
    - - the program is expected to process different kinds of requests in various ways, but the exact types of requests and their sequences are unknown beforehand
      - essential to execute several handlers in a particular order
      - the set of handlers and their order are supposed to change at runtime
    - - can control the order of request handling
      - can decouple classes that invoke operations from classes that perform operations
      - can introduce new handlers into the app without breaking the existing client code
    - - some requests may end up unhandled
  - - - design pattern turns a request into a stand-alone object containing all the requested information. this transformation lets pass requests as method arguments, delay or queue a request's execution, and supports undoable operations
    - - to parametrize objects with operations
      - to queue operations, schedule their execution, or execute them remotely
      - to implement reversible operations
    - - Single responsibility principle: decouple classes that invoke operations from classes that perform these operations
      - open/closed principle: introduce new commands into the app without breaking existing client code
      - implement undo/redo
      - implement deferred execution of operations
        assemble a set of simple commands into a complex one
    - - code may become more complicated since introducing a whole new layer between senders and receivers