Design Patterns

Design patterns are a means of exploiting recurring themes in code development.

"Design patterns correspond to small conceptual ideas which are used as building blocks in the larger scale design process." - https://sourcemaking.com/design_patterns/

Factories, Traits and policies

Not code, rather they are concepts which can be deployed in a chosen language. We are just going to look at a couple of design patterns, and an implementation of each in C++.

Mainly for the purpose of illustrating the relevance of keywords and access specifiers.

Refactoring

This involves changing design of a class hierarchy to move operations and/or data between classes.

It is likely to be, or should be, a common activity in object-oriented programming.

We aren’t thinking of refactoring as adding new functionality. It’s preserving the functionality but changing the implementation through a series of small behaviour conserving transformations. Refactoring could be used to transform from one design pattern to another.

Singleton

The name is somewhat suggestive of the meaning.

Typically there is no upper bound on the number of instances of a class, that is the number of objects of some ADT. But, we can only have one instance or object of a singleton class at a time. This class is realised by making the constructor private or protected.

Click to see Singleton implementation

class Singleton {
private:
static Singleton* instance;
public:
static Singleton* setInstance();
static void Show(){ cout << instance << endl; }
static void TidyUp();
protected:
Singleton(){};
};

Singleton * Singleton::instance = nullptr;

Singleton * Singleton::setInstance()
{
if ( instance == nullptr ) // Allow only one instance.
instance = new Singleton; // Invokes the private constructor
return instance;
}
void Singleton::TidyUp()
{
delete instance; // Delete the sole instance,
instance = nullptr; // and sets the pointer to nullptr.
}

int main()
{
Singleton::Show();
Singleton *eg = Singleton::setInstance();
// eg->setInstance();
eg->Show();
eg->TidyUp();
eg = nullptr;
Singleton::Show();
}

Monostate

The name follows since all instances of the class share the same state. A monostate class contains only private static data members and public non-static member functions. The significance is that another class can be used to control changes to the monostate class, through any instance, and know that those changes will spread to all instances of the monostate class.

The different objects of the monostate class may correspond to use of the same information in different situations/locations. For example with a high score table for a game.

class Admin; // Forward referencing

class Lab {
friend class Admin;
static int labCapacity;
public:
int getLabCapacity() const { return labCapacity; }
};

int Lab::labCapacity = 25;

class Admin {
bool permit;
string passwd; // Don't store strings like this!
public:
Admin(string password);
bool checkPassword(string password);
void setLabCapacity(int cap);
};

Click to see Monostate implementation

Admin :: Admin( string password )
{
if(passwd == "")
passwd = password;
}

bool Admin :: checkPassword( string password )
{
if( passwd == password ) {
cout << "Correct password" << endl;
permit = true;
return (true);
} else {
cout << "Incorrect password." << endl;
return (false);
permit = false;
}
}

void Admin :: setLabCapacity(int numOfStudents)
{
if ( permit )
Lab::labCapacity = numOfStudents;
}

Click to see Main.ccp

int main()
{
Lab lab1, lab2;
Admin admin1("psd1234");
Admin admin2("mypas");

cout << lab1.getLabCapacity() << endl;
cout << lab2.getLabCapacity() << endl;

if (admin1.checkPassword("psd1234"))
admin1.setLabCapacity(30);

cout << lab1.getLabCapacity() << endl;
cout << lab2.getLabCapacity() << endl;

if( admin2.checkPassword("abc111") )
admin2.setLabCapacity(40);

cout << lab1.getLabCapacity() << endl;
cout << lab2.getLabCapacity() << endl;
}

Output:
25
25
Correct password
30
30
Incorrect password
30
30

Monostate vs singleton

Both have only one set of data.

The monostate can have multiple references to that data though.

They differ in transparency.

The monostate pattern is transparent, in the sense the user doesn’t need to modify their behaviour, they still create monostate class objects in the usual way.
Creating the singleton requires non-standard behaviour.

Page updated

Google Sites

Report abuse