uml design class diagrams (2014)
DESCRIPTION
TRANSCRIPT
2 / 24
Strategy
http://en.wikipedia.org/wiki/Strategy_pattern
The Strategy Pattern (also known as the Policy Pattern) is a software design pattern that enables an algorithm's behavior to be selected at runtime. The strategy pattern defines a family of algorithms, encapsulates each algorithm, and makes the algorithms interchangeable within that family. Strategy lets the algorithm vary independently from clients that use it.
3 / 24
StateThe State Pattern, which closely resembles Strategy Pattern, is a behavioral software design pattern, also known as the objects for states pattern. This pattern is used in computer programming to encapsulate varying behavior for the same routine based on an object's state object. This can be a cleaner way for an object to change its behavior at runtime without resorting to large monolithic conditional statements.
http://en.wikipedia.org/wiki/State_pattern
4 / 24
BridgeThe Bridge Pattern is meant to "decouple an abstraction from its implementation so that the two can vary independently". The bridge uses encapsulation, aggregation, and can use inheritance to separate responsibilities into different classes. The Bridge Pattern is useful when both the class as well as what it does vary often. The class itself can be thought of as the implementation and what the class can do as the abstraction. The bridge pattern can also be thought of as two layers of abstraction. The Bridge Pattern is often confused with the Adapter Pattern. In fact, the Bridge Pattern is often implemented using the Class Adapter Pattern,
http://en.wikipedia.org/wiki/Bridge_pattern
5 / 24
CompositeThe Composite Pattern is a partitioning design pattern. The composite pattern describes that a group of objects are to be treated in the same way as a single instance of an object. The intent of a composite is to "compose" objects into tree structures to represent part-whole hierarchies. Implementing the Composite Pattern lets clients treat individual objects and compositions uniformly.
http://en.wikipedia.org/wiki/Composite_pattern
6 / 24
FlyweightA flyweight is 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. A classic example is the data structures for graphical representation of characters in a word processor. For every character there might be a reference to a flyweight glyph object shared by every instance of the same character in the document. Only the position of each character (in the document and/or the page) would need to be stored internally.
http://en.wikipedia.org/wiki/Flyweight_pattern
7 / 24
Interpreter
http://en.wikipedia.org/wiki/Interpreter_pattern
The Interpreter Pattern is a design pattern that specifies how to evaluate sentences in a language. The basic idea is to have a class for each symbol (terminal or nonterminal) in a specialized computer language. The syntax tree of a sentence in the language is an instance of the composite pattern and is used to evaluate (interpret) the sentence. Uses for the Interpreter pattern: specialized database query languages such as SQL; specialized computer languages which are often used to describe communication protocols; most general-purpose computer languages actually incorporate several specialized languages.
8 / 24
Decorator
http://en.wikipedia.org/wiki/Decorator_pattern
The Decorator Pattern (also known as Wrapper, an alternative naming shared with the Adapter Pattern) is a design pattern that allows behavior to be added to an individual object, either statically or dynamically, without affecting the behavior of other objects from the same class.
9 / 24
Chain of Responsibility
http://en.wikipedia.org/wiki/Chain_of_responsibility_pattern
The Chain-Of-Responsibility Pattern is a design pattern consisting of a source of command objects and a series of processing objects. Each processing object contains logic that defines the types of command objects that it can handle. The rest are passed to the next processing object in the chain. A mechanism also exists for adding new processing objects to the end of this chain. This pattern promotes the idea of loose coupling, which is considered a programming best practice.
10 / 24
Facade
http://en.wikipedia.org/wiki/Facade_pattern
The Facade Pattern (or Façade Pattern) is a software design pattern commonly used with object-oriented programming. The name is by analogy to an architectural facade. A facade is an object that provides a simplified interface to a larger body of code, such as a class library. A facade can: make a software library easier to use, understand and test, since the facade has convenient methods for common tasks; make the library more readable, for the same reason; reduce dependencies of outside code on the inner workings of a library, since most code uses the facade, thus allowing more flexibility in developing the system; wrap a poorly designed collection of APIs with a single well-designed API (as per task needs).
11 / 24
Adapter
http://en.wikipedia.org/wiki/Adapter_pattern
The Adapter Pattern is a software design pattern that allows the interface of an existing class to be used from another interface. It is often used to make existing classes work with others without modifying their source code.
12 / 24
Proxy
http://en.wikipedia.org/wiki/Proxy_pattern
A Proxy, in its most general form, is a class functioning as an interface to something else. The proxy could interface to anything: a network connection, a large object in memory, a file, or some other resource that is expensive or impossible to duplicate. A well-known example of the Proxy Pattern is a reference counting pointer object. In situations where multiple copies of a complex object must exist, the proxy pattern can be adapted to incorporate the flyweight pattern in order to reduce the application's memory footprint. Typically, one instance of the complex object and multiple proxy objects are created, all of which contain a reference to the single original complex object. Any operations performed on the proxies are forwarded to the original object. Once all instances of the proxy are out of scope, the complex object's memory may be deallocated.
13 / 24
Command
http://en.wikipedia.org/wiki/Command_pattern
The Command Pattern is a behavioral design pattern in which an object is used to represent and encapsulate all the information needed to call a method at a later time. Using command objects makes it easier to construct general components that need to delegate, sequence or execute method calls at a time of their choosing without the need to know the class of the method or the method parameters.
14 / 24
Memento
http://en.wikipedia.org/wiki/Memento_pattern
The Memento Pattern is a software design pattern that provides the ability to restore an object to its previous state (undo via rollback). The originator is some object that has an internal state. The caretaker is going to do something to the originator, but wants to be able to undo the change. The caretaker first asks the originator for a memento object. Then it does whatever operation (or sequence of operations) it was going to do. To roll back to the state before the operations, it returns the memento object to the originator. The memento object itself is an opaque object (one which the caretaker cannot, or should not, change). Classic examples of the memento pattern include the seed of a pseudorandom number generator (it will always produce the same sequence thereafter when initialized with the seed state) and the state in a finite state machine.
15 / 24
Iterator
http://en.wikipedia.org/wiki/Iterator_pattern
The Iterator Pattern is a design pattern in which an iterator is used to traverse a container and access the container's elements. The iterator pattern decouples algorithms from containers; in some cases, algorithms are necessarily container-specific and thus cannot be decoupled. For example, the hypothetical algorithm SearchForElement can be implemented generally using a specified type of iterator rather than implementing it as a container-specific algorithm. This allows SearchForElement to be used on any container that supports the required type of iterator.
16 / 24
Mediator
http://en.wikipedia.org/wiki/Mediator_pattern
The Mediator Pattern defines an object that encapsulates how a set of objects interact. This pattern is considered to be a behavioral pattern due to the way it can alter the program's running behavior. 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. This reduces the dependencies between communicating objects, thereby lowering the coupling.
17 / 24
Observer
http://en.wikipedia.org/wiki/Observer_pattern
The Observer Pattern is a software design pattern in which an object, called the subject, maintains a list of its dependents, called observers, and notifies them automatically of any state changes, usually by calling one of their methods. It is mainly used to implement distributed event handling systems. The Observer pattern is also a key part in the familiar Model View Controller (MVC) architectural pattern. In fact the observer pattern was first implemented in Smalltalk's MVC based user interface framework. The Observer Pattern is implemented in numerous programming libraries and systems, including almost all GUI toolkits.
18 / 24
Template Method
http://en.wikipedia.org/wiki/Template_method_pattern
The Template Method Pattern is a behavioral design pattern that defines the program skeleton of an algorithm in a method, called template method, which defers some steps to subclasses. It lets one redefine certain steps of an algorithm without changing the algorithm's structure. This use of "template" is unrelated to C++ templates. In the Template Method of this design pattern, one or more algorithm steps can be overridden by subclasses to allow differing behaviors while ensuring that the overarching algorithm is still followed.
19 / 24
Visitor
http://en.wikipedia.org/wiki/Visitor_pattern
The Visitor Pattern is a way of separating an algorithm from an object structure on which it operates. A practical result of this separation is the ability to add new operations to existing object structures without modifying those structures. It is one way to follow the open/closed principle. In essence, the visitor allows one to add new virtual functions to a family of classes without modifying the classes themselves; instead, one creates a visitor class that implements all of the appropriate specializations of the virtual function. The visitor takes the instance reference as input, and implements the goal through double dispatch.
20 / 24
Factory Method
http://en.wikipedia.org/wiki/Factory_method_pattern
The Factory Method pattern is a creational pattern which uses factory methods to deal with the problem of creating objects without specifying the exact class of object that will be created. This is done by creating objects via a factory method, which is either specified in an interface (abstract class) and implemented in implementing classes (concrete classes); or implemented in a base class, which can be overridden when inherited in derived classes; rather than by a constructor.
21 / 24
Prototype
http://en.wikipedia.org/wiki/Prototype_pattern
The Prototype Pattern is a creational design pattern in software development. This pattern is used to avoid subclasses of an object creator in the client application, like the abstract factory pattern does, and to avoid the inherent cost of creating a new object in the standard way (using the 'new' keyword) when it is prohibitively expensive. To implement the pattern, an abstract base class that specifies a pure virtual clone() method is declared, and any class that needs a "polymorphic constructor" capability derives itself from the abstract base class. The client calls the clone() method on the prototype, calls a factory method with a parameter designating the particular concrete derived class desired, or invokes the clone() method through some mechanism provided by another design pattern.
22 / 24
Abstract Factory
http://en.wikipedia.org/wiki/Abstract_factory_pattern
The Abstract Factory Pattern provides a way to encapsulate a group of individual factories that have a common theme without specifying their concrete classes. In normal usage, the client software creates a concrete implementation of the Abstract Factory and then uses the generic interface of the factory to create the concrete objects that are part of the theme. The client doesn't know (or care) which concrete objects it gets from each of these internal factories, since it uses only the generic interfaces of their products. This pattern separates the details of implementation of a set of objects from their general usage and relies on object composition, as object creation is implemented in methods exposed in the Factory interface.
23 / 24
Builder
http://en.wikipedia.org/wiki/Builder_pattern
The Builder Pattern is an object creation software design pattern. Unlike the Abstract Factory Pattern and the Factory Method Pattern whose intention is to enable polymorphism, the intention of the builder pattern is to find a solution to the telescoping constructor anti-pattern. The telescoping constructor anti-pattern occurs when the increase of object constructor parameter combination leads to an exponential list of constructors. Instead of using numerous constructors, the builder pattern uses another object, a builder, that receives each initialization parameter step by step and then returns the resulting constructed object at once. The builder pattern has another benefit: it can be used for objects that contain flat data (html code, SQL query, X.509 certificate...), that is, data that cannot be edited step by step and must be edited at once.
24 / 24
Singleton
http://en.wikipedia.org/wiki/Singleton_pattern
The Singleton Pattern is a design pattern that restricts the instantiation of a class to one object. This is useful when exactly one object is needed to coordinate actions across the system. The concept is sometimes generalized to systems that operate more efficiently when only one object exists, or that restrict the instantiation to a certain number of objects. The term comes from the mathematical concept of a singleton. There is criticism of the use of the singleton pattern, as some consider it an anti-pattern, judging that it is overused, introduces unnecessary restrictions in situations where a sole instance of a class is not actually required, and introduces global state into an application. In C++ it also serves to isolate from the unpredictability of the order of dynamic initialization, returning control to the programmer.