GoConqr hat ein neues Design! Sag uns, wie es dir gefällt.

Mindmap

patterns

Tom David Englisch

Inhalt der Mindmap

patterns

  1. Template method definition

    • Defines a skeleton of an algorithm as a series of method calls, deferring some steps to subclasses. Template method lets subclasses redefine certain steps of an algorithm without changing the algorithm’s structure And the superclass implementation of the highest level methods is the template
  2. Principles

    • Top=down development replicates how a super class has sub classes
      • hollywood principle ensures only the superclass calls methods of subclass to stop code breaking in the event high level changed
        • Encapsulate what varies/ implementation simplified (re)usage -- Abstract Interfaces (code to interfaces) Not tied to implementations Helps highlight similarities/ common functionality
          • We should keep our interfaces static wherever and whenever possible Interfaces should only be extended rather than changed, and then only in the knowledge that any cascading will not result in problems Interfaces may be built up using composition (has-a relationship) or inheritance (is-a relationship) Differences in interface implementation should then be encapsulated (hidden) behind those interfaces
  3. Why OO?

    • Associate code with data Simplify solving problems by allowing solutions to be envisaged in terms of objects (e.g. bird, dog) rather than just in terms of variables and functions Support code reuse and easy maintenance Support change and adaptation (if done right)
  4. Polymorphism is the mechanism by which code can be changed, specifically extended in terms of functionality, either requiring little change in the original code or no change at all

  5. Strategy pattern definition

    • The strategy defines a ‘family of algorithms’, which should all be encapsulated behind a common interface and be interchangeable. Strategy lets the algorithm change independently from the client that uses it
      • Advantages: The algorithms and behaviors can be reused. The algorithms are loosely coupled with the context entity. They can be changed/replaced without changing the context entity. Prevents the conditional statements. Disadvantages: Client must be aware of the various strategies, thus helping him decide the best strategy. It increases the number of objects in the application.
  6. Observer Pattern

    • Definition: Define a one-to-many dependency between objects so that when one object changes state, all of its dependents are notified and updated automatically We can also see that we need a subject object and there will be one or more observer objects We will also need the subject to be able to: REGISTER and REMOVE observer objects NOTIFY observer objects of a change Finally the observer objects will need to be able to receive any UPDATES
      • Pros - Loose coupling means that observer and subject can in future vary and change, providing they mainttain the interfaces Subject can handle a variable number of observers that is not in any way hard coded, which is critical because this is unlikely to be known at design time, and would probably change even if it were known
        • cons
          • Poor scalability/ decreased performance. As the observer list increases, so does the time required for the notify method to complete (updates may cease ti become real-time) Memory leaks/ run-time errors. If observers fail to unsubscribe from subjects properly, they would persist beyond their needed use (memory leak), or possibly result in a run-time error if deleted in a non-memory managed environment whilst remaining on the Observer notify list
  7. Definition: The Decorator pattern attaches additional responsibility to an object dynamically. Decorators provide a flexible alternative to using subclasses in order to extend functionality

    • Pros: Decorators provide a flexible alternative to subclassing for extending functionality Decorators allow behavior modification at runtime rather than going back into existing code and making changes Decorators are a nice solution to permutation issues because you can wrap a component with any number of decorators The decorator pattern supports the principle that classes should be open for extension but closed for modification Cons: Decorators can result in many small objects in our design, and overuse can be complex Decorators can cause issues if the client relies heavily on the components concrete type Decorators can complicate the process of instantiating the component because you not only have to instantiate the component but wrap it in a number of decorators It can be complicated to have decorators keep track of other decorators because to look back into multiple layers of the decorator chain starts to push the decorator pattern beyond its tru
  8. The factory pattern: defines an interface for creating (abstract creator class) an object (product), and then leaves subclasses decide which class to instantiate.

    • Advantage of Factory Pattern - Loose Coupling and Segregation of Responsibilities. Now instead of hard binding the complete logic to decide the nature and shape of the object on the basis of some conditions, you are assigning the responsibility to some other object and hence making the relationship loosely coupled and hence main tenable. Disadvantages - Before Understanding the Dis-advantages , we should understand that these patterns were chosen after a period of evolution and research and almost best fit for the required solution, otherwise these patterns would have easily been replaced by now.
  9. Object wrapping / encapsulation hide the implementation/ API details of one part of the code base from another This allows two sections of code that would normally not be able to talk to one another to do so It also allows us to plug in new bits of code, even stuff we have never seen before The Adapter Pattern supports all this by stipulating that the junction between two APIs be bridged by an intermediate object that inherits one API and has a compositional relationship to the other

    • Adapter pattern definition: coverts the interface of a class into another interface. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces
  10. Facade pattern definition: provides a unified interface to a set of interfaces. Facade defines a high-level interface that makes a system easier to use In other words, it uses the essential principle of the Adapter pattern: presenting a give interface as another It then increases the number of interfaces that are being adapted And it does so in a way that simplifies their collective use – e.g. Calling a construct car method to plug together a number component objects

  11. Definition: The Mediator pattern collects the rules of interaction between a number of objects (Colleagues) and encapsulates these into a separate Mediator object.

    • Advantages: limits need to modify client classes; when adding new classes, only the mediator changes. decouples objects, reuse/ plug-and-play simplifies communication (many-to-one instead of many-to-many) simplifies maintainability Problem: centralised control (mediator may become monolithic)
  12. And Flyweight object is defined as: “an object that minimizes memory use by sharing as much data as possible with other similar objects; it is a way to use objects in large numbers when a simple repeated representation would use an unacceptable amount of memory. Often some parts of the object state can be shared, and it is common practice to hold them in external data structures and pass them to the flyweight objects temporarily when they are used.”

    • Minimizes memory use by sharing as much data as possible with other similar objects It does this by recommending that common and repeated data / data structures be identified

Informationen

Beschreibung
Mindmap am patterns, erstellt von Tom David am 22/05/2015.
Erstellt von
Tom David
Aufrufe
1
Bewertung

Feedback

Worum geht es?

Wie gefällt dir das neue Design?

Dein Eindruck