What is the Sin­gle­ton De­sign Pat­tern?

A Sin­gle­ton de­sign pat­tern en­sures that only one in­stance of a class is cre­ated.

OpenSource For You - - Contents - By: Gay­a­tri Venu­gopal Waira­gade The au­thor teaches pro­gram­ming and Web tech­nolo­gies. Her ar­eas of in­ter­est are ac­ces­si­bil­ity, Hindi text pro­cess­ing and ed­u­ca­tion tech­nol­ogy. She can be reached at gay­a­trivenu­gopal3@gmail.com.

Imag­ine a dis­or­gan­ised wardrobe with heaps of clothes in ev­ery sec­tion. How would you or­gan­ise it? When I asked my stu­dents this ques­tion, I got the fol­low­ing an­swers: 1. Empty the wardrobe 2. Ar­range the clothes

• on the ba­sis of the most fre­quently used ones

• or the favourite ones

• or by their type (e.g., In­dian/Western)

3. Fix each sec­tion for each cat­e­gory and ar­range the clothes ac­cord­ingly

If a sim­i­lar prob­lem oc­curs in another con­text, such as when re-ar­rang­ing a book­shelf, the same so­lu­tion can be reused. This is the ba­sic prin­ci­ple be­hind de­sign pat­terns. With re­spect to ob­ject-ori­ented soft­ware en­gi­neer­ing, a de­sign pat­tern de­scribes a re­dun­dant prob­lem and pro­vides a reusable so­lu­tion.

Types of de­sign pat­terns

De­sign pat­terns have been cat­e­gorised by the Gang of Four or GoF (Gamma, Helm, John­son and Vlis­sides) into three types:

1. Creational – Pat­terns that deal with ob­ject cre­ation

2. Struc­tural – Pat­terns that deal with the com­po­si­tion of classes or ob­jects, and their re­la­tion­ships

3. Be­havioural – Pat­terns that fo­cus on how ob­jects dis­trib­ute work, and how each ob­ject work­ing in­de­pen­dently can help achieve a com­mon goal

The Sin­gle­ton de­sign pat­tern

Let us look at the web­site of a restau­rant as an ex­am­ple. The web­site has a menu link ti­tled Menu. Ev­ery time a user clicks on this link, data is re­trieved from the data­base and stored in an in­stance (ob­ject) of a class named ‘Menu’. The class di­a­gram for ‘Menu’ is shown in Fig­ure 1.

The prob­lem here is that on ev­ery sub­se­quent visit to the Menu page, even though the menu de­tails have been fetched once by the same client, the pro­gram fetches them again and stores the de­tails in a new ob­ject. Is there any way that we can re­duce the num­ber of ob­jects cre­ated for this class to one, so that this ob­ject can be shared across all the classes?

One so­lu­tion is to make the ob­ject global. But this is not a rec­om­mended prac­tice in ob­ject-ori­ented pro­gram­ming as this would re­quire track­ing of all the global ob­jects and their cur­rent sta­tus in the pro­gram. Also, it does not sup­port the prin­ci­ple of en­cap­su­la­tion.

The GoF in­tro­duced the Sin­gle­ton pat­tern, wherein only one in­stance/ob­ject of a class is cre­ated. This op­er­a­tion is per­formed in a static mem­ber func­tion of the class. The con­struc­tor of the class is made pri­vate so that this class can­not be in­stan­ti­ated from any­where else ex­cept from within the class it­self. The class di­a­gram is shown in Fig­ure 2. As you can see, the in­stance named ‘sin­gle­ton’ is made pri­vate and static (un­der­lined), and getIn­stance() is again a static mem­ber func­tion that cre­ates and re­turns the in­stance of the class.

The getIn­stance mem­ber func­tion will first check whether the in­stance is null or not. If it is null, it cre­ates a new ob­ject. Oth­er­wise it re­turns the ex­ist­ing ob­ject.

The same process can be used to limit the num­ber of ob­jects to any given num­ber by us­ing a counter to keep track of the num­ber of ob­jects.

There are two ways of in­stan­ti­at­ing the class – ea­ger in­stan­ti­a­tion and lazy in­stan­ti­a­tion.

In ea­ger in­stan­ti­a­tion, the ob­ject is cre­ated when the class is loaded. There­fore, ir­re­spec­tive of whether the ob­ject is used or not, it is cre­ated. The Java code for ea­ger in­stan­ti­a­tion is given be­low: pub­lic class EagerIni­tial­izedSin­gle­ton {

pri­vate static fi­nal EagerIni­tial­izedSin­gle­ton in­stance = new EagerIni­tial­izedSin­gle­ton();

//pri­vate con­struc­tor to avoid client ap­pli­ca­tions to use con­struc­tor

pri­vate EagerIni­tial­izedSin­gle­ton(){}

pub­lic static EagerIni­tial­izedSin­gle­ton getIn­stance(){ re­turn in­stance; } }

On the other hand, lazy in­stan­ti­a­tion cre­ates an ob­ject only when the static mem­ber func­tion is called, as shown be­low:

pub­lic class LazyIni­tial­izedSin­gle­ton { pri­vate static LazyIni­tial­izedSin­gle­ton in­stance; pri­vate LazyIni­tial­izedSin­gle­ton(){}

pub­lic static LazyIni­tial­izedSin­gle­ton getIn­stance(){ if(in­stance == null){ in­stance = new LazyIni­tial­izedSin­gle­ton(); } re­turn in­stance; } }

Any­one who plans to im­ple­ment this pat­tern in their pro­gram needs to take care of two ma­jor points:

The con­struc­tor needs to be made pri­vate so that in no cir­cum­stances can the class be in­stan­ti­ated from any other class.

While cre­at­ing child classes of the sin­gle­ton class, the in­stance must be ini­tialised with the in­stance of the cor­re­spond­ing child class.

Fig­ure 1: Class di­a­gram for ‘Menu’

Fig­ure 2: Class di­a­gram for the Sin­gle­ton de­sign pat­tern (Source: https://en.wikipedia.org/wiki/Sin­gle­ton_­pat­tern)

Newspapers in English

Newspapers from India

© PressReader. All rights reserved.