PetRockBlock https://blog.petrockblock.com Fun Stuff for Technics Enthusiasts Tue, 16 Oct 2018 15:42:46 +0000 en-US hourly 1 Design Pattern with PlantUML: Proxy Pattern https://blog.petrockblock.com/2018/09/02/design-pattern-plantuml-proxy-pattern/ https://blog.petrockblock.com/2018/09/02/design-pattern-plantuml-proxy-pattern/#respond Sun, 02 Sep 2018 15:48:26 +0000 https://blog.petrockblock.com/?p=125311 This post gives a brief overview about the Proxy Pattern. The post is part of a series about software design patterns and their UML representations with the help of PlantUML. The article aims at providing a very short description of the general idea of the pattern in the first part. This also involves a descriptive UML …

The post Design Pattern with PlantUML: Proxy Pattern appeared first on PetRockBlock.

]]>
This post gives a brief overview about the Proxy Pattern. The post is part of a series about software design patterns and their UML representations with the help of PlantUML.

The article aims at providing a very short description of the general idea of the pattern in the first part. This also involves a descriptive UML diagram. Then, the second part provides the PlantUML code for the diagram so that these posts can also be used as a source of design patterns in PlantUML syntax.

What is the Proxy Pattern?

According to Wikipedia, 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.

What problems can the Proxy design pattern solve?

  • The access to an object should be controlled.
  • Additional functionality should be provided when accessing an object.

When accessing sensitive objects, for example, it should be possible to check that clients have the needed access rights.

What solution does the Proxy design pattern describe?

Define a separate Proxy object that

  • can be used as substitute for another object (Subject) and
  • implements additional functionality to control the access to this subject.

This enables to work through a Proxy object to perform additional functionality when accessing a subject. For example, to check the access rights of clients accessing a sensitive object.
To act as substitute for a subject, a proxy must implement the Subject interface. Clients can’t tell whether they work with a subject or its proxy.

UML Diagram

The following diagram shows the Proxy Pattern in UML notation. It is based on the corresponding chapter in the book “Head First Design Patterns“:

PlantUML Syntax:
<p>@startuml<br />
interface Subject {<br />
{abstract} request()<br />
}<br />
together {<br />
class RealSubject<br />
class Proxy<br />
}</p>
<p>RealSubject : request()<br />
Proxy : request()</p>
<p>Subject <|.. RealSubject<br />
Subject <|.. Proxy<br />
RealSubject <- Proxy : subject</p>
<p>note bottom of RealSubject<br />
The RealSubject is<br />
usually the object<br />
that does most<br />
of the real work;<br />
the Proxy controls<br />
access to it.<br />
end note</p>
<p>note “The Proxy often instantiates\nor handles the creation of\nthe RealSubject.” as n1</p>
<p>RealSubject .. n1<br />
Proxy .. n1</p>
<p>note right of Subject<br />
Both the Proxy and the<br />
RealSubject implement the<br />
Subject interface. This<br />
allows any client to treat<br />
the proxy just like the<br />
RealSubject.<br />
end note<br />
@enduml</p>

PlantUML Sources

PlantUML is a tool allowing users to create UML diagrams from a plain text language. Here are the PlantUML sources for the above software pattern:

@startuml
interface Subject {
{abstract} request()
}
together {
class RealSubject
class Proxy
}

RealSubject : request()
Proxy : request()

Subject <|.. RealSubject
Subject <|.. Proxy
RealSubject <- Proxy : subject
@enduml

Other Design Patterns

In another article you find information about how to put together a single-side web application using PlantUML.

Proxy Pattern Design Pattern with PlantUML: Proxy Pattern - This post gives a brief overview about the Proxy Pattern. The post is part of a series about software design ... Read More
State Pattern Design Patterns with PlantUML: State Pattern - This post gives a brief overview about the State Pattern. The post is part of a series about software design ... Read More
Composite Pattern Design Patterns with PlantUML: Composite Pattern - This post gives a brief overview about the Composite Pattern. The post is part of a series about software design ... Read More
Iterator Pattern Design Patterns with PlantUML: Iterator Pattern - This post gives a brief overview about the Iterator Pattern. The post is part of a series about software design ... Read More
Template Pattern Design Patterns with PlantUML: Template Pattern - This post gives a brief overview about the Template Pattern. The post is part of a series about software design ... Read More
Facade Pattern Design Patterns with PlantUML: Facade Pattern - This post gives a brief overview about the Facade Pattern. The post is part of a series about software design ... Read More
Adapter Pattern Design Patterns with PlantUML: Adapter Pattern - This post gives a brief overview about the Adapter Pattern. The post is part of a series about software design ... Read More
Command Pattern Design Patterns with PlantUML: Command Pattern - This post gives a brief overview about the Command Pattern. The post is part of a series about software design ... Read More
Singleton Design Patterns with PlantUML: Singleton - This post gives a brief overview about the Singleton Pattern. The post is part of a series about software design ... Read More
Design Patterns with PlantUML: Abstract Factory Pattern - This post gives a brief overview about the Abstract Factory Pattern. The post is part of a series about software design ... Read More

The post Design Pattern with PlantUML: Proxy Pattern appeared first on PetRockBlock.

]]>
https://blog.petrockblock.com/2018/09/02/design-pattern-plantuml-proxy-pattern/feed/ 0
Design Patterns with PlantUML: State Pattern https://blog.petrockblock.com/2018/09/02/design-patterns-plantuml-state-pattern/ https://blog.petrockblock.com/2018/09/02/design-patterns-plantuml-state-pattern/#respond Sun, 02 Sep 2018 08:30:06 +0000 https://blog.petrockblock.com/?p=125309 This post gives a brief overview about the State Pattern. The post is part of a series about software design patterns and their UML representations with the help of PlantUML. The article aims at providing a very short description of the general idea of the pattern in the first part. This also involves a descriptive UML …

The post Design Patterns with PlantUML: State Pattern appeared first on PetRockBlock.

]]>
This post gives a brief overview about the State Pattern. The post is part of a series about software design patterns and their UML representations with the help of PlantUML.

The article aims at providing a very short description of the general idea of the pattern in the first part. This also involves a descriptive UML diagram. Then, the second part provides the PlantUML code for the diagram so that these posts can also be used as a source of design patterns in PlantUML syntax.

What is the State Pattern?

According to Wikipedia, the State pattern is a behavioral software design pattern to allow an object to alter its behavior when its internal state changes. This pattern is close to the concept of Finite-state machine however it is important to keep in mind that this pattern is not a software implementation of Finite-state machine. The state pattern can be interpreted as a strategy pattern which is able to switch the current strategy through invocations of methods defined in the pattern’s interface.

What problems can the State design pattern solve?

  • An object should change its behavior when its internal state changes.
  • State-specific behavior should be defined independently. That is, new states should be added and the behavior of existing states should be changed independently.

Implementing state-specific behavior directly within a class is inflexible because it commits the class to a particular behavior and makes it impossible to add a new state or change the behavior of an existing state later independently from (without changing) the class.

What solution does the State design pattern describe?

  • Define separate (state) objects that encapsulate state-specific behavior for each state. That is, define an interface (State) for performing state-specific behavior, and define classes that implement the interface for each state.
  • A class delegates state-specific behavior to its current state object instead of implementing state-specific behavior directly.

This makes a class independent of how state-specific behavior is implemented. New states can be added by defining new state classes. A class can change its behavior at run-time by changing its current state object.

UML Diagram

The following diagram shows the State Pattern in UML notation. It is based on the corresponding chapter in the book “Head First Design Patterns“:

PlantUML Syntax:
<p>@startuml<br />
class Context {<br />
void request()<br />
State state<br />
}<br />
interface State {<br />
{abstract} handle()<br />
}<br />
together {<br />
class ConcreteStateA<br />
class ConcreteStateB<br />
}</p>
<p>ConcreteStateA : handle()<br />
ConcreteStateB : handle()</p>
<p>Context -> State<br />
State <|– ConcreteStateA<br />
State <|– ConcreteStateB</p>
<p>note top of Context<br />
The Context is the class that<br />
can have a number of internal<br />
states. In out example, the<br />
GumballMachine is the context.<br />
end note</p>
<p>note left of Context::request<br />
Whenever the request()<br />
is made on the Context<br />
it is delegated to the<br />
state to handle:</p>
<p>“”state.handle()””</p>
<p>end note</p>
<p>note top of State<br />
The State interface defines a common<br />
interface for all concrete states; the<br />
states all implement the same interface,<br />
so they are interchangeable.<br />
end note</p>
<p>note “ConcreteStates handle requests from the\nContext. Each ConcreteState provides its\nown implementation for a request. In this\nway, when the Context changes state, its\n behavior will change as well.” as n1</p>
<p>ConcreteStateA .. n1<br />
ConcreteStateB .. n1</p>
<p>note right of ConcreteStateB<br />
Many concrete states<br />
are possible.<br />
end note<br />
@enduml</p>

PlantUML Sources

PlantUML is a tool allowing users to create UML diagrams from a plain text language. Here are the PlantUML sources for the above software pattern:

@startuml
class Context {
void request()
State state
}
interface State {
{abstract} handle()
}
together {
class ConcreteStateA
class ConcreteStateB
}

ConcreteStateA : handle()
ConcreteStateB : handle()

Context -> State
State <|-- ConcreteStateA
State <|-- ConcreteStateB

@enduml

Other Design Patterns

In another article you find information about how to put together a single-side web application using PlantUML.

Proxy Pattern Design Pattern with PlantUML: Proxy Pattern - This post gives a brief overview about the Proxy Pattern. The post is part of a series about software design ... Read More
State Pattern Design Patterns with PlantUML: State Pattern - This post gives a brief overview about the State Pattern. The post is part of a series about software design ... Read More
Composite Pattern Design Patterns with PlantUML: Composite Pattern - This post gives a brief overview about the Composite Pattern. The post is part of a series about software design ... Read More
Iterator Pattern Design Patterns with PlantUML: Iterator Pattern - This post gives a brief overview about the Iterator Pattern. The post is part of a series about software design ... Read More
Template Pattern Design Patterns with PlantUML: Template Pattern - This post gives a brief overview about the Template Pattern. The post is part of a series about software design ... Read More
Facade Pattern Design Patterns with PlantUML: Facade Pattern - This post gives a brief overview about the Facade Pattern. The post is part of a series about software design ... Read More
Adapter Pattern Design Patterns with PlantUML: Adapter Pattern - This post gives a brief overview about the Adapter Pattern. The post is part of a series about software design ... Read More
Command Pattern Design Patterns with PlantUML: Command Pattern - This post gives a brief overview about the Command Pattern. The post is part of a series about software design ... Read More
Singleton Design Patterns with PlantUML: Singleton - This post gives a brief overview about the Singleton Pattern. The post is part of a series about software design ... Read More
Design Patterns with PlantUML: Abstract Factory Pattern - This post gives a brief overview about the Abstract Factory Pattern. The post is part of a series about software design ... Read More

The post Design Patterns with PlantUML: State Pattern appeared first on PetRockBlock.

]]>
https://blog.petrockblock.com/2018/09/02/design-patterns-plantuml-state-pattern/feed/ 0
Design Patterns with PlantUML: Composite Pattern https://blog.petrockblock.com/2018/08/22/design-patterns-plantuml-composite-pattern/ https://blog.petrockblock.com/2018/08/22/design-patterns-plantuml-composite-pattern/#respond Wed, 22 Aug 2018 18:38:49 +0000 https://blog.petrockblock.com/?p=125307 This post gives a brief overview about the Composite Pattern. The post is part of a series about software design patterns and their UML representations with the help of PlantUML. The article aims at providing a very short description of the general idea of the pattern in the first part. This also involves a descriptive UML …

The post Design Patterns with PlantUML: Composite Pattern appeared first on PetRockBlock.

]]>
This post gives a brief overview about the Composite Pattern. The post is part of a series about software design patterns and their UML representations with the help of PlantUML.

The article aims at providing a very short description of the general idea of the pattern in the first part. This also involves a descriptive UML diagram. Then, the second part provides the PlantUML code for the diagram so that these posts can also be used as a source of design patterns in PlantUML syntax.

What is the Composite Pattern?

According to Wikipedia, the Composite pattern describes a group of objects that is 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.

What problems can the Composite design pattern solve?

  • A part-whole hierarchy should be represented so that clients can treat part and whole objects uniformly.
  • A part-whole hierarchy should be represented as tree structure.

When defining (1) Part objects and (2) Whole objects that act as containers for Part objects, clients must treat them separately, which complicates client code.

What solution does the Composite design pattern describe?

  • Define a unified Component interface for both part (Leaf) objects and whole (Composite) objects.
  • Individual Leaf objects implement the Component interface directly, and Composite objects forward requests to their child components.

This enables clients to work through the Component interface to treat Leaf and Composite objects uniformly: Leaf objects perform a request directly, and Composite objects forward the request to their child components recursively downwards the tree structure. This makes client classes easier to implement, change, test, and reuse.

UML Diagram

The following diagram shows the Composite Pattern in UML notation. It is based on the corresponding chapter in the book “Head First Design Patterns“:

PlantUML Syntax:
<p>@startuml<br />
class Client<br />
class Component<br />
class Leaf<br />
class Composite</p>
<p>Component : operation()<br />
Component : add(Component)<br />
Component : remove(Component)<br />
Component : getChild(int)</p>
<p>Leaf : operation()</p>
<p>Composite : operation()<br />
Composite : add(Component)<br />
Composite : remove(Component)<br />
Composite : getChild(int)</p>
<p>Client -> Component<br />
Component <|– Leaf<br />
Component <|– Composite<br />
Component “0..*” <–o “1” Composite</p>
<p>note top of Client<br />
The Client uses the<br />
Component interface to<br />
manipulate the objects in the<br />
composition.<br />
end note</p>
<p>note top of Component<br />
The Component defines an<br />
interface for all objects in<br />
the composition: both the<br />
composite and the leaf nodes.<br />
end note</p>
<p>note top of Component<br />
The Component may implement a<br />
default behavior for add(), remove(),<br />
getChild() and its operations.<br />
end note</p>
<p>note bottom of Leaf<br />
A Leaf has no<br />
children.<br />
end note</p>
<p>note left of Leaf<br />
Note that the Leaf also<br />
inherits methods like add(),<br />
remove() and getChild(), which<br />
do not necessarily make a lot of<br />
sense for a leaf node. We are<br />
going to come back to this issue.<br />
end note</p>
<p>note bottom of Leaf<br />
A Leaf defines the behavior for the<br />
elements in the composition. It does<br />
this by implementing the operations<br />
the Composite supports.<br />
end note</p>
<p>note bottom of Composite<br />
The Composite’s role is to define<br />
behavior of the components<br />
having children and to store child<br />
components.<br />
end note</p>
<p>note right of Composite<br />
The Composite also<br />
implements the Leaf-<br />
related operations.<br />
Note that some of<br />
these may not make<br />
sense on a Composite,<br />
so in that case an<br />
exception might be<br />
generated.<br />
end note<br />
@enduml</p>

PlantUML Sources

PlantUML is a tool allowing users to create UML diagrams from a plain text language. Here are the PlantUML sources for the above software pattern:


@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

@enduml

Other Design Patterns

In another article you find information about how to put together a single-side web application using PlantUML.

Proxy Pattern Design Pattern with PlantUML: Proxy Pattern - This post gives a brief overview about the Proxy Pattern. The post is part of a series about software design ... Read More
State Pattern Design Patterns with PlantUML: State Pattern - This post gives a brief overview about the State Pattern. The post is part of a series about software design ... Read More
Composite Pattern Design Patterns with PlantUML: Composite Pattern - This post gives a brief overview about the Composite Pattern. The post is part of a series about software design ... Read More
Iterator Pattern Design Patterns with PlantUML: Iterator Pattern - This post gives a brief overview about the Iterator Pattern. The post is part of a series about software design ... Read More
Template Pattern Design Patterns with PlantUML: Template Pattern - This post gives a brief overview about the Template Pattern. The post is part of a series about software design ... Read More
Facade Pattern Design Patterns with PlantUML: Facade Pattern - This post gives a brief overview about the Facade Pattern. The post is part of a series about software design ... Read More
Adapter Pattern Design Patterns with PlantUML: Adapter Pattern - This post gives a brief overview about the Adapter Pattern. The post is part of a series about software design ... Read More
Command Pattern Design Patterns with PlantUML: Command Pattern - This post gives a brief overview about the Command Pattern. The post is part of a series about software design ... Read More
Singleton Design Patterns with PlantUML: Singleton - This post gives a brief overview about the Singleton Pattern. The post is part of a series about software design ... Read More
Design Patterns with PlantUML: Abstract Factory Pattern - This post gives a brief overview about the Abstract Factory Pattern. The post is part of a series about software design ... Read More

The post Design Patterns with PlantUML: Composite Pattern appeared first on PetRockBlock.

]]>
https://blog.petrockblock.com/2018/08/22/design-patterns-plantuml-composite-pattern/feed/ 0
Design Patterns with PlantUML: Iterator Pattern https://blog.petrockblock.com/2018/08/21/design-patterns-plantuml-iterator-pattern/ https://blog.petrockblock.com/2018/08/21/design-patterns-plantuml-iterator-pattern/#respond Tue, 21 Aug 2018 18:53:28 +0000 https://blog.petrockblock.com/?p=125305 This post gives a brief overview about the Iterator Pattern. The post is part of a series about software design patterns and their UML representations with the help of PlantUML. The article aims at providing a very short description of the general idea of the pattern in the first part. This also involves a descriptive UML …

The post Design Patterns with PlantUML: Iterator Pattern appeared first on PetRockBlock.

]]>
This post gives a brief overview about the Iterator Pattern. The post is part of a series about software design patterns and their UML representations with the help of PlantUML.

The article aims at providing a very short description of the general idea of the pattern in the first part. This also involves a descriptive UML diagram. Then, the second part provides the PlantUML code for the diagram so that these posts can also be used as a source of design patterns in PlantUML syntax.

What is the Iterator Pattern?

According to Wikipedia, 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.

What problems can the Iterator design pattern solve?

  • The elements of an aggregate object should be accessed and traversed without exposing its representation (data structures).
  • New traversal operations should be defined for an aggregate object without changing its interface.

Defining access and traversal operations in the aggregate interface is inflexible because it commits the aggregate to particular access and traversal operations and makes it impossible to add new operations later without having to change the aggregate interface.

What solution does the Iterator design pattern describe?

  • Define a separate (iterator) object that encapsulates accessing and traversing an aggregate object.
  • Clients use an iterator to access and traverse an aggregate without knowing its representation (data structures).

Different iterators can be used to access and traverse an aggregate in different ways. New access and traversal operations can be defined independently by defining new iterators.

UML Diagram

The following diagram shows the Iterator Pattern in UML notation. It is based on the corresponding chapter in the book “Head First Design Patterns“:

PlantUML Syntax:
<p>@startuml<br />
class Aggregate <<interface>><br />
class Client<br />
class Iterator <<interface>><br />
together {<br />
class ConcreteAggregate<br />
class ConcreteIterator<br />
}</p>
<p>Aggregate : createIterator()<br />
ConcreteAggregate : createIterator()<br />
Iterator : hasNext()<br />
Iterator : next()<br />
Iterator : remove()<br />
ConcreteIterator : hasNext()<br />
ConcreteIterator : next()<br />
ConcreteIterator : remove()</p>
<p>Aggregate <- Client<br />
Client -> Iterator<br />
ConcreteAggregate -> ConcreteIterator<br />
Iterator <|.. ConcreteIterator<br />
Aggregate <|.. ConcreteAggregate</p>
<p>note top of Aggregate<br />
Having a common interface for your<br />
aggregates is handy for your client;<br />
it decouples your client from the<br />
implementation of your collection of objects.<br />
end note</p>
<p>note bottom of ConcreteAggregate<br />
The ConcreteAggregate<br />
has a collection of<br />
objects and implements<br />
the method that<br />
returns an Iterator<br />
for its collection.<br />
end note</p>
<p>note “Each ConcreteAggregate\nis responsible for\ninstantiating a\nConcreteIterator that\ncan iterate over its\ncollection of objects.” as n1<br />
ConcreteAggregate .. n1<br />
n1 .. ConcreteIterator</p>
<p>note bottom of ConcreteIterator<br />
The ConcreteIterator is<br />
responsible for managing<br />
the current position of<br />
the iteration.<br />
end note</p>
<p>note top of Iterator<br />
The Iterator interface<br />
provides the interface<br />
that all iterators<br />
must implement, and<br />
a set of methods<br />
for traversing over<br />
elements of a collection.<br />
Here we are using the<br />
java.util.Iterator. If you<br />
do not want to use Java’s<br />
Iterator interface, you<br />
can always create your<br />
own.<br />
end note<br />
@enduml</p>

PlantUML Sources

PlantUML is a tool allowing users to create UML diagrams from a plain text language. Here are the PlantUML sources for the above software pattern:


@startuml
class Aggregate <<interface>>
class Client
class Iterator <<interface>>
together {
class ConcreteAggregate
class ConcreteIterator
}

Aggregate : createIterator()
ConcreteAggregate : createIterator()
Iterator : hasNext()
Iterator : next()
Iterator : remove()
ConcreteIterator : hasNext()
ConcreteIterator : next()
ConcreteIterator : remove()

Aggregate <- Client Client -> Iterator
ConcreteAggregate -> ConcreteIterator
Iterator <|.. ConcreteIterator
Aggregate <|.. ConcreteAggregate

@enduml

Other Design Patterns

In another article you find information about how to put together a single-side web application using PlantUML.

Proxy Pattern Design Pattern with PlantUML: Proxy Pattern - This post gives a brief overview about the Proxy Pattern. The post is part of a series about software design ... Read More
State Pattern Design Patterns with PlantUML: State Pattern - This post gives a brief overview about the State Pattern. The post is part of a series about software design ... Read More
Composite Pattern Design Patterns with PlantUML: Composite Pattern - This post gives a brief overview about the Composite Pattern. The post is part of a series about software design ... Read More
Iterator Pattern Design Patterns with PlantUML: Iterator Pattern - This post gives a brief overview about the Iterator Pattern. The post is part of a series about software design ... Read More
Template Pattern Design Patterns with PlantUML: Template Pattern - This post gives a brief overview about the Template Pattern. The post is part of a series about software design ... Read More
Facade Pattern Design Patterns with PlantUML: Facade Pattern - This post gives a brief overview about the Facade Pattern. The post is part of a series about software design ... Read More
Adapter Pattern Design Patterns with PlantUML: Adapter Pattern - This post gives a brief overview about the Adapter Pattern. The post is part of a series about software design ... Read More
Command Pattern Design Patterns with PlantUML: Command Pattern - This post gives a brief overview about the Command Pattern. The post is part of a series about software design ... Read More
Singleton Design Patterns with PlantUML: Singleton - This post gives a brief overview about the Singleton Pattern. The post is part of a series about software design ... Read More
Design Patterns with PlantUML: Abstract Factory Pattern - This post gives a brief overview about the Abstract Factory Pattern. The post is part of a series about software design ... Read More

The post Design Patterns with PlantUML: Iterator Pattern appeared first on PetRockBlock.

]]>
https://blog.petrockblock.com/2018/08/21/design-patterns-plantuml-iterator-pattern/feed/ 0
Design Patterns with PlantUML: Template Pattern https://blog.petrockblock.com/2018/08/07/design-patterns-plantuml-template-pattern/ https://blog.petrockblock.com/2018/08/07/design-patterns-plantuml-template-pattern/#respond Tue, 07 Aug 2018 07:07:33 +0000 https://blog.petrockblock.com/?p=125303 This post gives a brief overview about the Template Pattern. The post is part of a series about software design patterns and their UML representations with the help of PlantUML. The article aims at providing a very short description of the general idea of the pattern in the first part. This also involves a descriptive UML …

The post Design Patterns with PlantUML: Template Pattern appeared first on PetRockBlock.

]]>
This post gives a brief overview about the Template Pattern. The post is part of a series about software design patterns and their UML representations with the help of PlantUML.

The article aims at providing a very short description of the general idea of the pattern in the first part. This also involves a descriptive UML diagram. Then, the second part provides the PlantUML code for the diagram so that these posts can also be used as a source of design patterns in PlantUML syntax.

What is the Template Pattern?

According to Wikipedia, the Template Pattern has two main parts, and typically uses object-oriented programming:

  • The “template method”, generally implemented as a base class (possibly an abstract class), which contains shared code and parts of the overall algorithm which are invariant. The template ensures that the overarching algorithm is always followed. In this class, “variant” portions are given a default implementation, or none at all.
  • Concrete implementations of the abstract class, which fill in the empty or “variant” parts of the “template” with specific algorithms that vary from implementation to implementation.

At run-time, a concrete class is instantiated. A main method inherited from the base class is called, which then may call other methods defined by both the base class and subclasses. This performs the overall algorithm in the same steps every time, but the details of some steps depend on which subclass was instantiated.

UML Diagram

The following diagram shows the Template Method Pattern in UML notation. It is based on the corresponding chapter in the book “Head First Design Patterns“:

PlantUML Syntax:
<p>@startuml<br />
class AbstractClass {<br />
templateMethod()<br />
{abstract} primitiveOperation1()<br />
{abstract} primitiveOperation2()<br />
}<br />
class ConcreteClass</p>
<p>ConcreteClass : primitiveOperation1()<br />
ConcreteClass : primitiveOperation2()</p>
<p>AbstractClass <|.. ConcreteClass</p>
<p>note left of AbstractClass<br />
The AbstractClass<br />
contains the template<br />
method.<br />
end note</p>
<p>note left of ConcreteClass<br />
There may be many<br />
ConcreteClasses, each<br />
implementing the full set of<br />
operations required by the<br />
template method.<br />
end note</p>
<p>note right of ConcreteClass<br />
The ConcreteClass implements<br />
the abstract operations,<br />
which are called when the<br />
templateMethod() needs them.<br />
end note</p>
<p>note right of AbstractClass::templateMethod<br />
The template method makes use of the<br />
primitiveOperations to implement an<br />
algorithm. It is decoupled from the actual<br />
implementation of the operations<br />
“”primitiveOperation1()””<br />
“”primitiveOperation2()””<br />
end note<br />
@enduml</p>

PlantUML Sources

PlantUML is a tool allowing users to create UML diagrams from a plain text language. Here are the PlantUML sources for the above software pattern:


@startuml
class AbstractClass {
templateMethod()
{abstract} primitiveOperation1()
{abstract} primitiveOperation2()
}
class ConcreteClass

ConcreteClass : primitiveOperation1()
ConcreteClass : primitiveOperation2()

AbstractClass &amp;lt;|.. ConcreteClass
@enduml

Other Design Patterns

In another article you find information about how to put together a single-side web application using PlantUML.

Proxy Pattern Design Pattern with PlantUML: Proxy Pattern - This post gives a brief overview about the Proxy Pattern. The post is part of a series about software design ... Read More
State Pattern Design Patterns with PlantUML: State Pattern - This post gives a brief overview about the State Pattern. The post is part of a series about software design ... Read More
Composite Pattern Design Patterns with PlantUML: Composite Pattern - This post gives a brief overview about the Composite Pattern. The post is part of a series about software design ... Read More
Iterator Pattern Design Patterns with PlantUML: Iterator Pattern - This post gives a brief overview about the Iterator Pattern. The post is part of a series about software design ... Read More
Template Pattern Design Patterns with PlantUML: Template Pattern - This post gives a brief overview about the Template Pattern. The post is part of a series about software design ... Read More
Facade Pattern Design Patterns with PlantUML: Facade Pattern - This post gives a brief overview about the Facade Pattern. The post is part of a series about software design ... Read More
Adapter Pattern Design Patterns with PlantUML: Adapter Pattern - This post gives a brief overview about the Adapter Pattern. The post is part of a series about software design ... Read More
Command Pattern Design Patterns with PlantUML: Command Pattern - This post gives a brief overview about the Command Pattern. The post is part of a series about software design ... Read More
Singleton Design Patterns with PlantUML: Singleton - This post gives a brief overview about the Singleton Pattern. The post is part of a series about software design ... Read More
Design Patterns with PlantUML: Abstract Factory Pattern - This post gives a brief overview about the Abstract Factory Pattern. The post is part of a series about software design ... Read More

The post Design Patterns with PlantUML: Template Pattern appeared first on PetRockBlock.

]]>
https://blog.petrockblock.com/2018/08/07/design-patterns-plantuml-template-pattern/feed/ 0
Update for PowerBlock Driver: Pin Configuration and Logging https://blog.petrockblock.com/2018/08/03/update-powerblock-driver-1-5-0/ https://blog.petrockblock.com/2018/08/03/update-powerblock-driver-1-5-0/#respond Fri, 03 Aug 2018 13:22:26 +0000 https://blog.petrockblock.com/?p=125484 The driver of our popular Raspberry Pi Power Switch add-on board PowerBlock got a feature update! More configuration, more logging, faster shutdown. What comes with this Feature Update? So, what’s new in this update? Basically, these are the two things: The status and shutdown pins on the Raspberry side can now be configured. This allows …

The post Update for PowerBlock Driver: Pin Configuration and Logging appeared first on PetRockBlock.

]]>
The driver of our popular Raspberry Pi Power Switch add-on board PowerBlock got a feature update! More configuration, more logging, faster shutdown.

What comes with this Feature Update?

So, what’s new in this update? Basically, these are the two things:

  • The status and shutdown pins on the Raspberry side can now be configured. This allows to use other HATs that might use the default pin numbers 17 and 18. The configuration file can be found at /etc/powerblockconfig.cfg.
  • The PowerBlock driver now has its own logger so that you can follow every action of it, if you are interested. You can find it at /var/log/powerblock.log
PowerBlock Logging Messages
PowerBlock Logging Messages

Besides that, the shutdown time was optimised so that a shutdown is much faster (again) now.

The new driver has version 1.5.0.

You can update your driver by simply re-installing the driver as depicted in the Installation Instructions.

The post Update for PowerBlock Driver: Pin Configuration and Logging appeared first on PetRockBlock.

]]>
https://blog.petrockblock.com/2018/08/03/update-powerblock-driver-1-5-0/feed/ 0
Design Patterns with PlantUML: Facade Pattern https://blog.petrockblock.com/2018/07/23/design-patterns-plantuml-facade-pattern/ https://blog.petrockblock.com/2018/07/23/design-patterns-plantuml-facade-pattern/#respond Mon, 23 Jul 2018 15:34:47 +0000 https://blog.petrockblock.com/?p=125300 This post gives a brief overview about the Facade Pattern. The post is part of a series about software design patterns and their UML representations with the help of PlantUML. The article aims at providing a very short description of the general idea of the pattern in the first part. This also involves a descriptive UML …

The post Design Patterns with PlantUML: Facade Pattern appeared first on PetRockBlock.

]]>
This post gives a brief overview about the Facade Pattern. The post is part of a series about software design patterns and their UML representations with the help of PlantUML.

The article aims at providing a very short description of the general idea of the pattern in the first part. This also involves a descriptive UML diagram. Then, the second part provides the PlantUML code for the diagram so that these posts can also be used as a source of design patterns in PlantUML syntax.

What is the Facade Pattern?

According to Wikipedia, 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, subjectively, poorly-designed collection of APIs with a single well-designed API

Implementors often use the facade design pattern when a system is very complex or difficult to understand because the system has a large number of interdependent classes or because its source code is unavailable. This pattern hides the complexities of the larger system and provides a simpler interface to the client.

What problems can the Facade design pattern solve?

  • To make a complex subsystem easier to use, a simple interface should be provided for a set of interfaces in the subsystem.
  • The dependencies on a subsystem should be minimized.

Clients that access a complex subsystem directly refer to (depend on) many different objects having different interfaces (tight coupling), which makes the clients hard to implement, change, test, and reuse.

What solution does the Facade design pattern describe?

Define a Facade object that

  • implements a simple interface in terms of (by delegating to) the interfaces in the subsystem and
  • may perform additional functionality before/after forwarding a request.

This enables to work through a Facade object to minimize the dependencies on a subsystem.

UML Diagram

The following diagram shows the Facade Pattern in UML notation. It is based on the corresponding chapter in the book “Head First Design Patterns“:

PlantUML Syntax:
<p>@startuml<br />
class Client<br />
class Facade<br />
Client -> Facade</p>
<p>package “Subsystem Classes” <<rectangle>> {</p>
<p>note “More complex subsystem” as n1</p>
<p>Facade — “class 1”<br />
Facade — “class 2”</p>
<p>package “class 1” <<rectangle>> {<br />
}</p>
<p>package “class 2” <<rectangle>> {<br />
}</p>
<p>package “class 3” <<rectangle>> {<br />
}</p>
<p>package “class 4” <<rectangle>> {<br />
}</p>
<p>package “class 5” <<rectangle>> {<br />
}</p>
<p>package “class 6” <<rectangle>> {<br />
}</p>
<p>“class 1” — “class 2”<br />
“class 1” — “class 3”<br />
“class 2” — “class 4”<br />
“class 3” — “class 5”<br />
“class 3” — “class 6”<br />
“class 4” — “class 5”<br />
“class 4” — “class 6”<br />
}</p>
<p>note left of Client<br />
Happy client whose<br />
job just became<br />
easier because of<br />
the facade.<br />
end note</p>
<p>note right of Facade<br />
Unified interface<br />
that is easier to use.<br />
end note<br />
@enduml</p>

PlantUML Sources

PlantUML is a tool allowing users to create UML diagrams from a plain text language. Here are the PlantUML sources for the above software pattern:


@startuml
class Client
class Facade
Client -> Facade

package "Subsystem Classes" <<rectangle>> {

note "More complex subsystem" as n1

Facade -- "class 1"
Facade -- "class 2"

package "class 1" <<rectangle>> {
}

package "class 2" <<rectangle>> {
}

package "class 3" <<rectangle>> {
}

package "class 4" <<rectangle>> {
}

package "class 5" <<rectangle>> {
}

package "class 6" <<rectangle>> {
}

"class 1" -- "class 2"
"class 1" -- "class 3"
"class 2" -- "class 4"
"class 3" -- "class 5"
"class 3" -- "class 6"
"class 4" -- "class 5"
"class 4" -- "class 6"
}

note left of Client
Happy client whose
job just became
easier because of
the facade.
end note

note right of Facade
Unified interface
that is easier to use.
end note
@enduml

Other Design Patterns

In another article you find information about how to put together a single-side web application using PlantUML.

Proxy Pattern Design Pattern with PlantUML: Proxy Pattern - This post gives a brief overview about the Proxy Pattern. The post is part of a series about software design ... Read More
State Pattern Design Patterns with PlantUML: State Pattern - This post gives a brief overview about the State Pattern. The post is part of a series about software design ... Read More
Composite Pattern Design Patterns with PlantUML: Composite Pattern - This post gives a brief overview about the Composite Pattern. The post is part of a series about software design ... Read More
Iterator Pattern Design Patterns with PlantUML: Iterator Pattern - This post gives a brief overview about the Iterator Pattern. The post is part of a series about software design ... Read More
Template Pattern Design Patterns with PlantUML: Template Pattern - This post gives a brief overview about the Template Pattern. The post is part of a series about software design ... Read More
Facade Pattern Design Patterns with PlantUML: Facade Pattern - This post gives a brief overview about the Facade Pattern. The post is part of a series about software design ... Read More
Adapter Pattern Design Patterns with PlantUML: Adapter Pattern - This post gives a brief overview about the Adapter Pattern. The post is part of a series about software design ... Read More
Command Pattern Design Patterns with PlantUML: Command Pattern - This post gives a brief overview about the Command Pattern. The post is part of a series about software design ... Read More
Singleton Design Patterns with PlantUML: Singleton - This post gives a brief overview about the Singleton Pattern. The post is part of a series about software design ... Read More
Design Patterns with PlantUML: Abstract Factory Pattern - This post gives a brief overview about the Abstract Factory Pattern. The post is part of a series about software design ... Read More

The post Design Patterns with PlantUML: Facade Pattern appeared first on PetRockBlock.

]]>
https://blog.petrockblock.com/2018/07/23/design-patterns-plantuml-facade-pattern/feed/ 0
Design Patterns with PlantUML: Adapter Pattern https://blog.petrockblock.com/2018/07/16/design-patterns-plantuml-adapter-pattern/ https://blog.petrockblock.com/2018/07/16/design-patterns-plantuml-adapter-pattern/#respond Mon, 16 Jul 2018 18:08:03 +0000 https://blog.petrockblock.com/?p=125298 This post gives a brief overview about the Adapter Pattern. The post is part of a series about software design patterns and their UML representations with the help of PlantUML. The article aims at providing a very short description of the general idea of the pattern in the first part. This also involves a descriptive UML …

The post Design Patterns with PlantUML: Adapter Pattern appeared first on PetRockBlock.

]]>
This post gives a brief overview about the Adapter Pattern. The post is part of a series about software design patterns and their UML representations with the help of PlantUML.

The article aims at providing a very short description of the general idea of the pattern in the first part. This also involves a descriptive UML diagram. Then, the second part provides the PlantUML code for the diagram so that these posts can also be used as a source of design patterns in PlantUML syntax.

What is the Adapter Pattern?

According to Wikipedia, the Adapter Pattern is a design patternthat allows the interface of an existing class to be used as another interface.

The Adapter design pattern solves problems like:

  • How can a class be reused that does not have an interface that a client requires?
  • How can classes that have incompatible interfaces work together?
  • How can an alternative interface be provided for a class?

Often an (already existing) class can’t be reused only because its interface doesn’t conform to the interface clients require.

The Adapter design pattern describes how to solve such problems:

  • Define a separate Adapter class that converts the (incompatible) interface of a class (Adaptee) into another interface (Target) clients require.
  • Work through an Adapter to work with (reuse) classes that do not have the required interface.

The key idea in this pattern is to work through a separate Adapter that adapts the interface of an (already existing) class without changing it. Clients don’t know whether they work with a Target class directly or through an Adapter with a class that does not have the Target interface.

UML Diagram

The following diagram shows the Adapter Pattern in UML notation. It is based on the corresponding chapter in the book “Head First Design Patterns“:

PlantUML Syntax:
<p>@startuml<br />
class Client<br />
class Target <<interface>><br />
class Adapter<br />
class Adaptee<br />
Target : request()<br />
Adapter : request()<br />
Adaptee : specificRequest()</p>
<p>Client -> Target<br />
Target <|.. Adapter<br />
Adapter -> Adaptee<br />
note on link<br />
Adapter is composed<br />
with the Adapter.<br />
end note</p>
<p>note bottom of Client<br />
The client sees only the<br />
Target interface<br />
end note</p>
<p>note “The Adapter implements\nthe Target interface.” as n1<br />
Target .. n1<br />
n1 .. Adapter</p>
<p>note bottom of Adaptee<br />
All requests get<br />
delegated to the<br />
Adaptee.<br />
end note<br />
@enduml</p>

PlantUML Sources

PlantUML is a tool allowing users to create UML diagrams from a plain text language. Here are the PlantUML sources for the above software pattern:


@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

Other Design Patterns

In another article you find information about how to put together a single-side web application using PlantUML.

Proxy Pattern Design Pattern with PlantUML: Proxy Pattern - This post gives a brief overview about the Proxy Pattern. The post is part of a series about software design ... Read More
State Pattern Design Patterns with PlantUML: State Pattern - This post gives a brief overview about the State Pattern. The post is part of a series about software design ... Read More
Composite Pattern Design Patterns with PlantUML: Composite Pattern - This post gives a brief overview about the Composite Pattern. The post is part of a series about software design ... Read More
Iterator Pattern Design Patterns with PlantUML: Iterator Pattern - This post gives a brief overview about the Iterator Pattern. The post is part of a series about software design ... Read More
Template Pattern Design Patterns with PlantUML: Template Pattern - This post gives a brief overview about the Template Pattern. The post is part of a series about software design ... Read More
Facade Pattern Design Patterns with PlantUML: Facade Pattern - This post gives a brief overview about the Facade Pattern. The post is part of a series about software design ... Read More
Adapter Pattern Design Patterns with PlantUML: Adapter Pattern - This post gives a brief overview about the Adapter Pattern. The post is part of a series about software design ... Read More
Command Pattern Design Patterns with PlantUML: Command Pattern - This post gives a brief overview about the Command Pattern. The post is part of a series about software design ... Read More
Singleton Design Patterns with PlantUML: Singleton - This post gives a brief overview about the Singleton Pattern. The post is part of a series about software design ... Read More
Design Patterns with PlantUML: Abstract Factory Pattern - This post gives a brief overview about the Abstract Factory Pattern. The post is part of a series about software design ... Read More

The post Design Patterns with PlantUML: Adapter Pattern appeared first on PetRockBlock.

]]>
https://blog.petrockblock.com/2018/07/16/design-patterns-plantuml-adapter-pattern/feed/ 0
Design Patterns with PlantUML: Command Pattern https://blog.petrockblock.com/2018/07/02/design-patterns-plantuml-command-pattern/ https://blog.petrockblock.com/2018/07/02/design-patterns-plantuml-command-pattern/#respond Mon, 02 Jul 2018 19:49:00 +0000 https://blog.petrockblock.com/?p=125294 This post gives a brief overview about the Command Pattern. The post is part of a series about software design patterns and their UML representations with the help of PlantUML. The article aims at providing a very short description of the general idea of the pattern in the first part. This also involves a descriptive UML …

The post Design Patterns with PlantUML: Command Pattern appeared first on PetRockBlock.

]]>
This post gives a brief overview about the Command Pattern. The post is part of a series about software design patterns and their UML representations with the help of PlantUML.

The article aims at providing a very short description of the general idea of the pattern in the first part. This also involves a descriptive UML diagram. Then, the second part provides the PlantUML code for the diagram so that these posts can also be used as a source of design patterns in PlantUML syntax.

What is the Command Pattern?

According to Wikipedia, 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.

The Command Pattern solves problems like:

  • Coupling the invoker of a request to a particular request should be avoided. That is, hard-wired requests should be avoided.
  • It should be possible to configure an object (that invokes a request) with a request.

Implementing (hard-wiring) a request directly into a class is inflexible because it couples the class to a particular request at compile-time, which makes it impossible to specify a request at run-time.

What solution does the Command design pattern describe?

  • Define separate (command) objects that encapsulate a request.
  • A class delegates a request to a command object instead of implementing a particular request directly.

This enables one to configure a class with a command object that is used to perform a request. The class is no longer coupled to a particular request and has no knowledge (is independent) of how the request is carried out.

UML Diagram

The following diagram shows the Command Pattern in UML notation. It is based on the corresponding chapter in the book “Head First Design Patterns“:

PlantUML Syntax:
<p>@startuml<br />
class Client<br />
class Invoker<br />
class Command <<interface>><br />
class Receiver<br />
class ConcreteCommand</p>
<p>Invoker : setCommand()<br />
Command : execute()<br />
Command : undo()<br />
Receiver : action()<br />
ConcreteCommand : execute()<br />
ConcreteCommand : undo()</p>
<p>Client -> Receiver<br />
Client -> ConcreteCommand<br />
Receiver <- ConcreteCommand<br />
Invoker -> Command<br />
Command <|.. ConcreteCommand</p>
<p>note left of Client<br />
The Client is responsible for<br />
creating a ConcreteCommand and<br />
setting its Receiver.<br />
end note</p>
<p>note bottom of Receiver<br />
The Receiver knows how to<br />
perform the work needed to<br />
carry out the request. Any class<br />
can act as a Receiver.<br />
end note</p>
<p>note bottom of ConcreteCommand<br />
The ConcreteCommand defines a binding between an action<br />
and a Receiver. The Invoker makes a request by calling<br />
execute() and the ConcreteCommand carries it out by<br />
calling one or more actions on the Receiver.<br />
end note</p>
<p>note left of Invoker<br />
The Invoker holds<br />
a command and at<br />
some point asks the<br />
command to carry<br />
out a request by<br />
calling its execute()<br />
method.<br />
end note</p>
<p>note top of Command<br />
Command declares an interface for all commands. A<br />
command is invoked through its execute() method,<br />
which asks a receiver to perform its action.<br />
end note</p>
<p>note right of ConcreteCommand::execute()<br />
The execute method invokes the action(s)<br />
on the receiver needed to fulfill the<br />
request;</p>
<p>“”public void execute() {“”<br />
“” receiver.action()””<br />
“”}””</p>
<p>end note<br />
@enduml</p>

PlantUML Sources

PlantUML is a tool allowing users to create UML diagrams from a plain text language. Here are the PlantUML sources for the above software pattern:


@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

@enduml

Other Design Patterns

In another article you find information about how to put together a single-side web application using PlantUML.

Proxy Pattern Design Pattern with PlantUML: Proxy Pattern - This post gives a brief overview about the Proxy Pattern. The post is part of a series about software design ... Read More
State Pattern Design Patterns with PlantUML: State Pattern - This post gives a brief overview about the State Pattern. The post is part of a series about software design ... Read More
Composite Pattern Design Patterns with PlantUML: Composite Pattern - This post gives a brief overview about the Composite Pattern. The post is part of a series about software design ... Read More
Iterator Pattern Design Patterns with PlantUML: Iterator Pattern - This post gives a brief overview about the Iterator Pattern. The post is part of a series about software design ... Read More
Template Pattern Design Patterns with PlantUML: Template Pattern - This post gives a brief overview about the Template Pattern. The post is part of a series about software design ... Read More
Facade Pattern Design Patterns with PlantUML: Facade Pattern - This post gives a brief overview about the Facade Pattern. The post is part of a series about software design ... Read More
Adapter Pattern Design Patterns with PlantUML: Adapter Pattern - This post gives a brief overview about the Adapter Pattern. The post is part of a series about software design ... Read More
Command Pattern Design Patterns with PlantUML: Command Pattern - This post gives a brief overview about the Command Pattern. The post is part of a series about software design ... Read More
Singleton Design Patterns with PlantUML: Singleton - This post gives a brief overview about the Singleton Pattern. The post is part of a series about software design ... Read More
Design Patterns with PlantUML: Abstract Factory Pattern - This post gives a brief overview about the Abstract Factory Pattern. The post is part of a series about software design ... Read More

The post Design Patterns with PlantUML: Command Pattern appeared first on PetRockBlock.

]]>
https://blog.petrockblock.com/2018/07/02/design-patterns-plantuml-command-pattern/feed/ 0
Design Patterns with PlantUML: Singleton https://blog.petrockblock.com/2018/06/28/design-patterns-plantuml-singleton/ https://blog.petrockblock.com/2018/06/28/design-patterns-plantuml-singleton/#respond Thu, 28 Jun 2018 19:28:30 +0000 https://blog.petrockblock.com/?p=125288 This post gives a brief overview about the Singleton Pattern. The post is part of a series about software design patterns and their UML representations with the help of PlantUML. The article aims at providing a very short description of the general idea of the pattern in the first part. This also involves a descriptive UML …

The post Design Patterns with PlantUML: Singleton appeared first on PetRockBlock.

]]>
This post gives a brief overview about the Singleton Pattern. The post is part of a series about software design patterns and their UML representations with the help of PlantUML.

The article aims at providing a very short description of the general idea of the pattern in the first part. This also involves a descriptive UML diagram. Then, the second part provides the PlantUML code for the diagram so that these posts can also be used as a source of design patterns in PlantUML syntax.

What is the Singleton Pattern?

According to Wikipedia, the Singleton Pattern is a software 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 singleton pattern solves problems like:

  • How can it be ensured that a class has only one instance?
  • How can the sole instance of a class be accessed easily?
  • How can a class control its instantiation?
  • How can the number of instances of a class be restricted?

The singleton design pattern describes how to solve such problems:

  • Hide the constructor of the class.
  • Define a public static operation (getInstance()) that returns the sole instance of the class.

The key idea in this pattern is to make the class itself responsible for controlling its instantiation (that it is instantiated only once).
The hidden constructor (declared private) ensures that the class can never be instantiated from outside the class.
The public static operation can be accessed easily by using the class name and operation name (Singleton.getInstance()).

UML Diagram

The following diagram shows the Singleton Pattern in UML notation. It is based on the corresponding chapter in the book “Head First Design Patterns“:

PlantUML Syntax:
<p>@startuml<br />
title Singleton</p>
<p>class Singleton</p>
<p>Singleton : {static} uniqueInstance<br />
Singleton : // other useful Singleton data …<br />
Singleton : {static} getInstance() : Singleton<br />
Singleton : // other useful Singleton methods()</p>
<p>note right of Singleton<br />
The uniqueInstance<br />
class variable holds our<br />
one and only instance<br />
of Singleton<br />
end note</p>
<p>note left of Singleton<br />
The getInstance() method is static,<br />
which means it’s a class method, so you<br />
can conveniently access this method<br />
from anywhere in your code using<br />
Singleton getInstance(). That’s just as<br />
easy as accessing a global variable, but<br />
we get benefit like lazy instantiation<br />
from the Singleton.<br />
end note</p>
<p>note bottom of Singleton<br />
A class implementing the Singleton<br />
Pattern is more than a Singleton;<br />
it is a purpose class with its<br />
own set of data and methdods.<br />
end note<br />
@enduml</p>

PlantUML Sources

PlantUML is a tool allowing users to create UML diagrams from a plain text language. Here are the PlantUML sources for the above software pattern:


@startuml
title Singleton

class Singleton

Singleton : {static} uniqueInstance
Singleton : // other useful Singleton data ...
Singleton : {static} getInstance() : Singleton
Singleton : // other useful Singleton methods()

@enduml

Other Design Patterns

In another article you find information about how to put together a single-side web application using PlantUML.

Proxy Pattern Design Pattern with PlantUML: Proxy Pattern - This post gives a brief overview about the Proxy Pattern. The post is part of a series about software design ... Read More
State Pattern Design Patterns with PlantUML: State Pattern - This post gives a brief overview about the State Pattern. The post is part of a series about software design ... Read More
Composite Pattern Design Patterns with PlantUML: Composite Pattern - This post gives a brief overview about the Composite Pattern. The post is part of a series about software design ... Read More
Iterator Pattern Design Patterns with PlantUML: Iterator Pattern - This post gives a brief overview about the Iterator Pattern. The post is part of a series about software design ... Read More
Template Pattern Design Patterns with PlantUML: Template Pattern - This post gives a brief overview about the Template Pattern. The post is part of a series about software design ... Read More
Facade Pattern Design Patterns with PlantUML: Facade Pattern - This post gives a brief overview about the Facade Pattern. The post is part of a series about software design ... Read More
Adapter Pattern Design Patterns with PlantUML: Adapter Pattern - This post gives a brief overview about the Adapter Pattern. The post is part of a series about software design ... Read More
Command Pattern Design Patterns with PlantUML: Command Pattern - This post gives a brief overview about the Command Pattern. The post is part of a series about software design ... Read More
Singleton Design Patterns with PlantUML: Singleton - This post gives a brief overview about the Singleton Pattern. The post is part of a series about software design ... Read More
Design Patterns with PlantUML: Abstract Factory Pattern - This post gives a brief overview about the Abstract Factory Pattern. The post is part of a series about software design ... Read More

The post Design Patterns with PlantUML: Singleton appeared first on PetRockBlock.

]]>
https://blog.petrockblock.com/2018/06/28/design-patterns-plantuml-singleton/feed/ 0