Like I said in my previous Good Software Design research journal entry I am learning about design patterns in SDV701 at the moment and so to reinforce my knowledge I have decided to define and refine what I think design patterns are and how they can be implemented.
What are design patterns?
A design pattern is effectively the solution to a problem ( which could have many possible solutions) which has been discovered and implemented successfully by other developers.
These design patterns are not language specific instead they are general solutions you can modify to your programing language and specific application.
For example when developing a website providing access to sensitive data I as the developer would naturally implement a authentication system such as a login system. However this is actually a design pattern because I have seen authentication systems on many websites many times everyday that concept must have been conceived by one developer/development team originally and others chose to implement it because it looked to be a advantageous way to solve the problem of how to protect the sensitive data from unauthorized users.
We don’t think of an authentication system as a design pattern, but instead we think of it as the natural consequence of deciding the website will hold sensitive data.
Why is this? Well I believe this is because as developers the use of authentication systems has become part of our socially constructed reality, rather than something we consciously regard as a design pattern solution.
By defining that a obvious (or not so obvious solution) is a design pattern we are actually giving the pattern a name, this is the benefit of learning design patterns as you can actually identify them with a name.
Below is the range of pattern categories that Matthias discussed with us in class today:
(Otto, 2017)
Pattern categories:
Analysis patterns– An analysis design pattern is identified when you first go into a business and you spot they want to build a system that has similar needs to other systems you have built/learnt about and so you can take the design patterns used in these similar systems (like the authentication system I was talking about before) and implement them in this new organizations system thereby fulfilling a similar business requirement.
Another good example that Matthias came up with was if you were developing a e-Commerce website you would likely implement a shopping cart concept. Again this is because it has been used in other similar systems to meet a similar business need.
Architectural patterns– These are high level programming concepts for example MVC (Model View Controller).
Another example that Matthias said that I was not aware of was ORM – Object Relational Mapping, which goes from the OO world to relational world which is databases. It maps objects to the relational world of rows and columns in database tables.
Other examples are:
Client-server
Peer to peer
Design pattern categories
These are between the analysis and architectural patterns; design patterns are the building blocks.
Design – > General -> Fundamental design patterns:
e.g. Separation of concerns. You separate out the form stuff from the business stuff.
Expert – Give the responsibility of something such as enrollment to a class that is an ‘expert’ in it such as clsStudent.
High cohesion – How well do things belong together.
Low coupling – If you have two separate classes make sure they do not depend on each other too much, because a high coupling can mean changes to one class inadvertently alter the behavior of other classes.
Polymorphism
Design – > General ->Grasp patterns:
These are the 10 commandments of good Object Oriented programming (which can be found here: https://dzone.com/articles/ten-commandments-of-object-oriented-design)
For example my favorite is the single responsibility principle which states that every class and method must only be responsible for one aspect of the problem domain.
Design – > Gang of four (GoF): We have 22 design patterns that are either structural, creational or behavioral.
What are the benefits of patterns?
- Allow re-usability of proven principles
- Improve developer communication as they give you words to descriptive good practices
What are the cons of patterns?
- You can reuse the idea but you can’t copy and paste the code from one project to another, as design patterns differ slightly in their implementation depending on what system and programming language they are used in
- It is labour intensive as you have to go through your code and replace code multiple times and in multiple places, this isn’t yet automate-able.
What are the criticisms of design patterns?
Design patterns can contain duplicate code thereby violating the once and only once principle.
A example of one of the 22 design patterns:
Singleton: You use this pattern where you only want one instance of a object in your system.
e.g. you only want one instance of:
- Clock
- Current printer
- Database connection – A single database can be accessed by multiple connections simultaneously, but there should only be one pool. e.g. several processors can request access have short connection then the connection is freed up again.
- Printer queue – All jobs for printer, but only one printer queue. Because there would be a risk for conflict if a single system had two printer queues.
In systems where you only want one instance of a object existing at a time, one class must be given the responsibility of ensuring there is only one instance existing. Now the expert fundamental design pattern makes us give the responsibility for something in our system to the class which is the ‘expert’ in this.
Well in the case of singleton design pattern that means giving the responsibility of ensuring there is only one instance of the class we are applying the singleton design pattern to, to the class itself.
In other words singleton pattern moves the responsibility for making sure there is only a single instance object to the class itself.
Using the clock example again the clock class itself must be responsible for making sure there is only one instance of clock, as the clock is a expert in clock.
How to implement singleton?
- Make constructor of the object private. This makes class not instantiable anymore
- Give other classes controlled access to the singleton object via a factory method in the singleton class (it is a generic method that is returning one of its own kind)
The factory method says if the factory method instance is null then create one, therefore the factory method checks if there is a extant singleton object.
The singleton contains a pointer to an instance of itself.
A singleton pattern is lazy meaning it is on demand only, it is only created if the factory method is called.
Now we have transferred the responsibility for managing the number of singleton objects existing in the system to the singleton class we need to consider the multi-user and multitasking ability of the system.
What do I mean by this ? Well when people access the Facebook db at the same time, (which is extremely likely given the number of users that could be connecting to the Facebook database on a single database server at a point in time, just based on the number of worldwide users).
For the database to support both of the queries simultaneously, it does what OS do when running multiple processes on a single processor they multi-thread meaning they split up the processor by timeslice and each slice is handed to each process.
However this can cause an issue with singleton classes as a singleton object can be created more than once at a time, i.e. you can have one singleton objects at a time if the singleton factory method (which the method which is called by other classes when they want an instance of the singleton class; the factory method checks if the singleton object is null (i.e. there are no singleton objects in the system at the moment) and it will instantiate the singleton object if that conditional is meet)
And so at the moment if when the factory method is called in a multi-threading environment we could end up with two singleton objects at the same time which could can crash the system.
What can we do to fix this problem? We need to make the singleton object thread safe.
3. To make the singleton object thread safe Matthias showed us that the most elegantly simple way was the folloing changes:
- You make the singleton object class ‘sealed’ this means you cannot extend (create subclass off the singleton class).
- You also make the singleton declaration atomic meaning it cannot be stopped half way through running if the processors timeslice for that thread is finished meaning you will not end up with two singleton object instances.
e.g.
sealed class clsNameComparer : IComparer //sealed means you can’t extend (set up inheritance) off the singleton object
{
private clsNameComparer() {}
public static readonly clsNameComparer Instance = new clsNameComparer(); //Generates the singleton, that makes the singleton object on demand
public int Compare(clsWork x, clsWork y)
{
string lcNameX = x.Name;
string lcNameY = y.Name;
return lcNameX.CompareTo(lcNameY);
}
}
}
4. Perform a secondary refactoring in the client (the caller of the singleton object)
mySingleton Instance = mySingleton.Instance;
Conclusion
I have found writing this up a good way to think about design patterns in a different way and a way to come up with examples not mentioned in class so it has been a valuable exercise, I hope it has been interesting for you and explained it has simplified this system which is basically just taking a model answer from someone else and adapting it for your own system.
Bibliography:
Otto, M. (2017, Semester). SV701 – Advanced Software Development. NMIT. Retrieved from https://livenmitac-my.sharepoint.com/personal/matthias_otto_nmit_ac_nz/_layouts/15/WopiFrame.aspx?sourcedoc=%7Bd180f53c-726e-4cc7-ae73-661e96d42d2a%7D&action=default
Alex Buckley - IT student and developer 