Case Studies in GOF Creational Patterns: Case Studies in Software Architecture & Design, #2

By Ramki

Learn and consolidate concepts of GOF Design Patterns, the category of Creational Patterns here.

Each Pattern is explained with a practical real life Case Study.

It is platform neutral and hence can be adopted into any programming language / development platform.

 

We normally do not come across such books with deal the concepts with simplicity and yet with full practical bias.

• Language: English
• Publisher: Ramki
• Release date: Dec 24, 2023
• ISBN: 9798223745235

Ramki

Author :   Ramakrishnan N  (Ramki)   Near 50 years of experience in Software Architecture, Enterprise Architecture Design (UML, others) and Patterns (GOF, Microservices and many more), SOA to Microservices to Cloud Native and few State-of-Art technologies.    Consultant and High-end Trainer to many prestigious International Enterprises   Certified in TOGAF 9 and TOGAF 10   Based at Bangalore, India.       Reachable through : [e-mail]

Book preview

Chapter: Singleton Creational GOF Design Pattern

– Discussion and Case Study

Suppose I have a situation where only one instance is required; how do I restrict the class to have just a single (Singleton) instance?

The solution lies with the Creational GOF Pattern: Singleton Pattern.

No object can lie  alone in an OO design of any software.

That is why classes that are shown in Class Diagram seem to have association  with some other class.

Collaborate with the Class itself; The class controls (through static members) the number of instances created.

It can still have association with other classes which need to make use of the single instance.

Association with itself

Associations from Client class, which uses methods of Singleton Class

Different ice-creams As per OOPS, you can create any number of instances for normal classes

Class Diagram:

Objects of that class:

Here o1, o2 and o3 are object instances of the class

Dropsicle But we need to design this class to produce only one instance, for applying Singleton Pattern.

Class Diagram:

Objects of that class:

Before instantiation:

None

After first call for instance:

After next call for instance:

Only one instance made possible by the code written as per Singleton Pattern

There could be more than one object reference pointing to the same instance:

So, we need to design this class to produce only one instance and no more.

How do we achieve it?

Make use of following OO features:

:unique instance: static Field Attribute, static specified reference / pointer to self: Singleton class

:a visible static operation, getInstance(): to return reference / pointer to such a Singleton; constructor hidden (private or protected): so that instance is created only by the class, restricting one (or any such controlled cardinality)

What is shown above is just a sample design. We will improvise it through a series of steps, including some pseudo code in couple of Case situations and a Case Study.

A small discussion on static at this stage, for those who may not be clear with this facility in OO. After this discussion, we will come back to discussion on Singleton Pattern and pseudo code.

Normally the Field Attributes that are declared in Class

are owned by each of the object instances of the class

The Attribute memory space is one per instance

Disappointed orange Similarly the operations declared in class  are owned by object instances of the class

The operations work on Field Attribute values of specific instance

The  owner of such Field Attributes and methods as members is normally the object Instance.

Conference room vector art Static Field Attributes

Static fields can be declared by using the keyword static

Note the underline shown in UML to indicate static fields

Static Member Functions

The next issue to tackle is that like every other Field Attribute, we have made this static Field Attribute also to be private one. This is in line with the Best Practices of OO.

How can this now be accessed?

Static Methods can be used,

but only to refer to

static Field Attributes

and other static methods 

Static members are methods and Field Attributes that are shared by all instances of a class. Shared data members are useful when multiple objects need to use information that is common to all. Shared class methods can be used without first creating an object instance from a class.

Back to Singleton Pattern discussion

We will have a Field Attribute: which is shown as s. Every such field should be having a type. We will have it as a reference to the same class type: SingletonClass. Also note how UML has a colon representation for this, as shown below.

The effect of a static Field Attribute is that it is created and allocated memory space in the system as and when the runtime system knows about the class. In other words, this Field will have nearly global lifetime.

Usually Class Diagram does not show the constructor and makes us assume more about it. However, in this Pattern the constructor has to be private or protected, which is normally unusual. So, we will show the constructor and another two methods here. Note that the Field Attribute is a static one and the constructor is shown as protected.

The idea of a protected or private constructor is to prevent it being accessed from outside the class. In such a situation, the class will have total control the way instance is created.

Let us note that

1. We have  getInstance() as a method of the class and so it has access to even the private / protected constructor. In other words, if the instance of the class is to be created, the above design suggests that this method can create the instance by calling the constructor that is hidden in its access.

2. Still, getInstance() is public and so can be invoked from outside the class. Since it is both static and public, any other code in this application can invoke it as a static method. Let us assume that first some code in SomeClientClass is invoking it and then some code in SomeOtherClientClass is invoking it next.