- Los patrones de diseño surgen a partir del libro *A Pattern Language: Towns, Buildings, Construction* de Cristopher Alexander.
- La inspiración del libro fueron las ciudades medievales, atractivas y armoniosas, que fueron construidas según regulaciones locales que requerían ciertas características, pero que permitían al arquitecto adaptarlas a situaciones particulares.
- En el libro se suministran reglas e imágenes y se describen métodos exactos para construir diseños prácticos, seguros y atractivos a cualquier escala. También recopila modelos anteriores (con ventajas/desventajas) con el fin de usarlos en un futuro.
- El libro recomienda que las decisiones sobre la construcción de edificios se tomen de acuerdo al entorno preciso de cada proyecto.
@startuml
top to bottom direction
scale 700 width
scale 600 height
class Product
class Creator
class ConcreteProduct
class ConcreteCreator
Creator : factoryMethod()
Creator : anOperation()
ConcreteCreator : factoryMethod()
Creator <|–down- ConcreteCreator
Product <|–down- ConcreteProduct
ConcreteProduct <- ConcreteCreator
hide members
show methods
note top of Creator
The Creator is a class that contains
the implementation for all of the
methods to manipulate products,
except for the factory method.
end note
note right of Creator
The abstract factoryMethod()
is what all Creator subclasses
must implement.
end note
note right of ConcreteCreator
The ConcreteCreator
implements the
factoryMethod(), which is
the method that actually
produces products.
end note
note “The ConcreteCreator is responsible for\ncreating one or more concrete products. It\nis the only class that has the knowledge of\nhow to create these products.” as n1
ConcreteProduct .. n1
ConcreteCreator .. n1
note “All products must implement\nthe same interface so that the\nclasses which use the products\ncan refer to the interface,\nnot the concrete class.” as n2
n2 . ConcreteProduct
n2 . Product
@enduml
---
@startuml
class Client
class Invoker
class Command <<interface>>
class Receiver
class ConcreteCommand
Invoker : setCommand()
Command : execute()
Command : undo()
Receiver : action()
ConcreteCommand : execute()
ConcreteCommand : undo()
Client -> Receiver
Client -> ConcreteCommand
Receiver <- ConcreteCommand
Invoker -> Command
Command <|.. ConcreteCommand
note left of Client
The Client is responsible for
creating a ConcreteCommand and
setting its Receiver.
end note
note bottom of Receiver
The Receiver knows how to
perform the work needed to
carry out the request. Any class
can act as a Receiver.
end note
note bottom of ConcreteCommand
The ConcreteCommand defines a binding between an action
and a Receiver. The Invoker makes a request by calling
execute() and the ConcreteCommand carries it out by
calling one or more actions on the Receiver.
end note
note left of Invoker
The Invoker holds
a command and at
some point asks the
command to carry
out a request by
calling its execute()
method.
end note
note top of Command
Command declares an interface for all commands. A
command is invoked through its execute() method,
which asks a receiver to perform its action.
end note
note right of ConcreteCommand::execute()
The execute method invokes the action(s)
on the receiver needed to fulfill the
request;
public void execute() {
receiver.action()
}
end note
@enduml
@startuml
class Client
class Target <<interface>>
class Adapter
class Adaptee
Target : request()
Adapter : request()
Adaptee : specificRequest()
Client -> Target
Target <|.. Adapter
Adapter -> Adaptee
note on link
Adapter is composed
with the Adapter.
end note
note bottom of Client
The client sees only the
Target interface
end note
note “The Adapter implements\nthe Target interface.” as n1
Target .. n1
n1 .. Adapter
note bottom of Adaptee
All requests get
delegated to the
Adaptee.
end note
@enduml
@startuml
class Client
class Component
class Leaf
class Composite
Component : operation()
Component : add(Component)
Component : remove(Component)
Component : getChild(int)
Leaf : operation()
Composite : operation()
Composite : add(Component)
Composite : remove(Component)
Composite : getChild(int)
Client -> Component
Component <|– Leaf
Component <|– Composite
Component “0..*” <–o “1” Composite
note top of Client
The Client uses the
Component interface to
manipulate the objects in the
composition.
end note
note top of Component
The Component defines an
interface for all objects in
the composition: both the
composite and the leaf nodes.
end note
note top of Component
The Component may implement a
default behavior for add(), remove(),
getChild() and its operations.
end note
note bottom of Leaf
A Leaf has no
children.
end note
note left of Leaf
Note that the Leaf also
inherits methods like add(),
remove() and getChild(), which
do not necessarily make a lot of
sense for a leaf node. We are
going to come back to this issue.
end note
note bottom of Leaf
A Leaf defines the behavior for the
elements in the composition. It does
this by implementing the operations
the Composite supports.
end note
note bottom of Composite
The Composite’s role is to define
behavior of the components
having children and to store child
components.
end note
note right of Composite
The Composite also
implements the Leaf-
related operations.
Note that some of
these may not make
sense on a Composite,
so in that case an
exception might be
generated.
end note
@enduml
@startuml
skinparam componentStyle uml2
class Component
class ConcreteComponent
class Decorator
class ConcreteDecoratorA
class ConcreteDecoratorB
Component : methodA()
Component : methodB()
Component : // otherMethods()
ConcreteComponent : methodA()
ConcreteComponent : methodB()
ConcreteComponent : // otherMethods()
Decorator : methodA()
Decorator : methodB()
Decorator : // otherMethods()
ConcreteDecoratorA : Component wrappedObject
ConcreteDecoratorA : methodA()
ConcreteDecoratorA : methodB()
ConcreteDecoratorA : newBehavior()
ConcreteDecoratorA : // otherMethods()
ConcreteDecoratorB : Component wrappedObject
ConcreteDecoratorB : Object newState
ConcreteDecoratorB : methodA()
ConcreteDecoratorB : methodB()
ConcreteDecoratorB : // otherMethods()
Component <|– ConcreteComponent
Component <|– Decorator
Decorator <|– ConcreteDecoratorA
Decorator <|– ConcreteDecoratorB
Decorator –> Component : component
note right on link
Each component can be used on its
own, or wrapped by a decorator
component
end note
note bottom of ConcreteComponent
The ConreteComponent
is the object we are going
to dynamically add new
behavior to it. It extends
Component.
end note
note bottom of Decorator
Decorators implement the
same interface or abstract
class as the component they
are going to decorate.
end note
note bottom of ConcreteDecoratorB
Decorators can extend the
state of the component
end note
note bottom of ConcreteDecoratorB
Decorators can add new methods;
however, new behavior is typically
added by doing computation
before or after an existing method
in the component.
end note
note bottom of ConcreteDecoratorA
The ConcreteDecorator has an
instance variable for the thing
it decorates (the Component the
Decorator wraps).
end note
@enduml
@startuml
class Client
class Invoker
class Command <<interface>>
class Receiver
class ConcreteCommand
Invoker : setCommand()
Command : execute()
Command : undo()
Receiver : action()
ConcreteCommand : execute()
ConcreteCommand : undo()
Client -> Receiver
Client -> ConcreteCommand
Receiver <- ConcreteCommand
Invoker -> Command
Command <|.. ConcreteCommand
note left of Client
The Client is responsible for
creating a ConcreteCommand and
setting its Receiver.
end note
note bottom of Receiver
The Receiver knows how to
perform the work needed to
carry out the request. Any class
can act as a Receiver.
end note
note bottom of ConcreteCommand
The ConcreteCommand defines a binding between an action
and a Receiver. The Invoker makes a request by calling
execute() and the ConcreteCommand carries it out by
calling one or more actions on the Receiver.
end note
note left of Invoker
The Invoker holds
a command and at
some point asks the
command to carry
out a request by
calling its execute()
method.
end note
note top of Command
Command declares an interface for all commands. A
command is invoked through its execute() method,
which asks a receiver to perform its action.
end note
note right of ConcreteCommand::execute()
The execute method invokes the action(s)
on the receiver needed to fulfill the
request;
public void execute() {
receiver.action()
}
end note
@enduml