This article has multiple issues. Please help improve it or discuss these issues on the talk page . (Learn how and when to remove these template messages) (Learn how and when to remove this template message)
|
The Archetype pattern separates the logic from implementation; the separation is accomplished by there being two abstract classes, a decorator (for logic) and a delegate (for implementation). The Factory handles the mapping of decorator and delegate classes and returns the pair associated with a parameter or parameters passed. The interface is the contract between a decorator, a delegate and the calling class creating an Inversion of Responsibility. [1] This example use two branches however you can have 'N' branches as required. The pattern means that one branch from the interface does not have to worry about how another branch operators as long it implements the interface.
Decorator
The descendants of the decorator class handle the logic, for example performing a calculation. The descendants of the decorator can then call the descendants of the delegated when or if they wish to pass responsibility for example storage or communication.
Delegate
The descendants of the delegate flow class handle the implementation for call a sub-system, storage, or communication. Different children can use completely different sub-systems storage, or communications than each other.
publicinterfaceRequest{publicvoidsendRequest();}publicclassRequestFactory{publicstaticRequestgetRequest(Stringa,Stringb){DecoratorRequestdcr=null;DelegateRequestdlr=null;if(a.equals("A"))dcr=newADecoratorRequest();if(a.equals("B"))dcr=newBDecoratorRequest();if(b.equals("Y"))dlr=newYDelegateRequest();if(b.equals("Z"))dlr=newZDelegateRequest();dcr.setDelegate(dlr);returndcr;}}publicclassApp{publicstaticvoidmain(String[]args){Requestcr=null;cr=RequestFactory.getRequest("A","Y");cr.sendRequest();cr=RequestFactory.getRequest("A","Z");cr.sendRequest();cr=RequestFactory.getRequest("B","Y");cr.sendRequest();cr=RequestFactory.getRequest("B","Z");cr.sendRequest();}}publicabstractclassDecoratorRequestimplementsRequest{protectedDelegateRequestdelegate;publicDecoratorRequest(){}publicvoidsetDelegate(DelegateRequestdelegate){this.delegate=delegate;}}publicabstractclassDelegateRequestimplementsRequest{publicDelegateRequest(){}}publicclassADecoratorRequestextendsDecoratorRequest{@OverridepublicvoidsendRequest(){System.out.print("A-");delegate.sendRequest();}}publicclassBDecoratorRequestextendsDecoratorRequest{@OverridepublicvoidsendRequest(){System.out.print("B-");delegate.sendRequest();}}publicclassYDelegateRequestextendsDelegateRequest{@OverridepublicvoidsendRequest(){System.out.println("-Y");}}publicclassZDelegateRequestextendsDelegateRequest{@OverridepublicvoidsendRequest(){System.out.println("-Z");}}
Delegation pattern - calls the specific implementation
Decorator pattern - performs the generalised logic
Factory method pattern - creates the archetype combination
In object-oriented programming and software engineering, the visitor design 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 the structures. It is one way to follow the open/closed principle.
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 does not know 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.
In software engineering, the adapter pattern is a software design pattern that allows the interface of an existing class to be used as another interface. It is often used to make existing classes work with others without modifying their source code.
The bridge pattern is a design pattern used in software engineering that is meant to "decouple an abstraction from its implementation so that the two can vary independently", introduced by the Gang of Four. The bridge uses encapsulation, aggregation, and can use inheritance to separate responsibilities into different classes.
In computer programming, flyweight is a software design pattern. A flyweight is an object that minimizes memory usage 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 objects temporarily when they are used.
In software engineering, the composite pattern is a partitioning design pattern. The composite pattern describes a group of objects that are treated the same way as a single instance of the same type of 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.
In object-oriented programming, the decorator pattern is a design pattern that allows behavior to be added to an individual object, dynamically, without affecting the behavior of other objects from the same class. The decorator pattern is often useful for adhering to the Single Responsibility Principle, as it allows functionality to be divided between classes with unique areas of concern. The decorator pattern is structurally nearly identical to the chain of responsibility pattern, the difference being that in a chain of responsibility, exactly one of the classes handles the request, while for the decorator, all classes handle the request.
In computer programming, the proxy pattern is a software design 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. In short, a proxy is a wrapper or agent object that is being called by the client to access the real serving object behind the scenes. Use of the proxy can simply be forwarding to the real object, or can provide additional logic. In the proxy, extra functionality can be provided, for example caching when operations on the real object are resource intensive, or checking preconditions before operations on the real object are invoked. For the client, usage of a proxy object is similar to using the real object, because both implement the same interface.
In object-oriented programming, the command pattern is a behavioral design pattern in which an object is used to encapsulate all information needed to perform an action or trigger an event at a later time. This information includes the method name, the object that owns the method and values for the method parameters.
In object-oriented programming, 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.
In computer programming, 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 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 for a client. See also Composite pattern.
In software engineering, 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.
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.
The state pattern is a behavioral software design pattern that allows an object to alter its behavior when its internal state changes. This pattern is close to the concept of finite-state machines. The state pattern can be interpreted as a strategy pattern, which is able to switch a strategy through invocations of methods defined in the pattern's interface.
The syntax of the Java refers to the set of rules defining how a Java program is written and interpreted.
In software engineering, dependency injection is a technique in which an object receives other objects that it depends on. These other objects are called dependencies. In the typical "using" relationship the receiving object is called a client and the passed object is called a service. The code that passes the service to the client can be many kinds of things and is called the injector. Instead of the client specifying which service it will use, the injector tells the client what service to use. The "injection" refers to the passing of a dependency into the object that would use it.
In the Java computer programming language, an annotation is a form of syntactic metadata that can be added to Java source code. Classes, methods, variables, parameters and Java packages may be annotated. Like Javadoc tags, Java annotations can be read from source files. Unlike Javadoc tags, Java annotations can also be embedded in and read from Java class files generated by the Java compiler. This allows annotations to be retained by the Java virtual machine at run-time and read via reflection. It is possible to create meta-annotations out of the existing ones in Java.
In object-oriented computer programming, a null object is an object with no referenced value or with defined neutral ("null") behavior. The null object design pattern describes the uses of such objects and their behavior. It was first published in the Pattern Languages of Program Design book series.
In object-oriented design, 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. Thus, the chain of responsibility is an object oriented version of the if ... else if ... else if ....... else ... endif
idiom, with the benefit that the condition–action blocks can be dynamically rearranged and reconfigured at runtime.
In object-oriented programming, forwarding means that using a member of an object results in actually using the corresponding member of a different object: the use is forwarded to another object. Forwarding is used in a number of design patterns, where some members are forwarded to another object, while others are handled by the directly used object. The forwarding object is frequently called a wrapper object, and explicit forwarding members are called wrapper functions.