Moving forward on design pattern as I discussed in previous blog about how we can Solving Design Problems by Design Patterns, so let’s discuss our first pattern Singleton Pattern.

Basically its a design pattern which ensures your system will have only one entry point to access it. It’s sometime very important to have exactly one instance e.g. Our database. In that we always want to have only one access point to maintain the security and similarly in some other scenario also it’s possible. Now as a programmer one can ask, how to ensure that a class has only one instance and prevent all other instances? Lets think a bit on this, A global variable/flag (boolean 0,1)? which will keep track of the instances. No a global variable can never keep track of it as it will not be accessible on other modules of our project. Then what? An experience architect would say that the better solution would be to make the class itself responsible for keeping track of its instance. The class itself only can ensure that no other instance of that is created. At this stage it might look very complex to you but think on it and read it carefully.

For php guys lets walk through the following code.. Syntax will not be different in other languages…

class myClass { public function myClass() { ... } public function myMethod() { ... } public function myNewMethod() { ... } ... }

Now what happens if i want to use this class? simply by creating a new object

$classInstance = new myClass();

But we can create many instances for this class and that is what i want to prevent because i am going to show you how you can restrict multiple instances of this class. So how can we do that?

Like i wrote, the class itself will have to keep track of this and so our class becomes

class myClass {
 
//Variable responsible to keep track.
 
private static $m_pInstance;
 
//constructor
 
public function myClass() { ... }
public function myMethod() { ... }
public function myNewMethod() { ... }
...
}

Now one can ask why this “private static” thing is used here. Well it’s simple, i declared it private because a user has nothing to do with this variable and we don’t want it to be accessible and “static” because i want it to be a class variable so that it retains it’s value to keep track of instance of it’s class. Second thing that i will do is, i will make this constructor private. What?? Yes!! because we don’t want this class to be instantiated from outside of this class. By making it public we are allowing everybody to create instance of it, which we don’t want. Well what’s next? Will this guarantee for only one instance? Not yet. So far we have prohibited outsiders to use it directly not even a single time then now we have to implement the way it will be used only once. So to do that, i will add a very weird method to this class which will ensure that nobody can create any second instance of this class. So our new class becomes-

class myClass {
 
//Variable responsible to keep track.
 
private static $m_pInstance;
 
//constructor
 
private function myClass() { ... }
 
public static function createInstance() {
//self is used for accessing class members
if (!self::$m_pInstance)   {
self::$m_pInstance = new myClass();
}
 
return self::$m_pInstance;
 
}
 
public function myMethod() { ... }
public function myNewMethod() { ... }
...
}

after reading above code intention should be clear that we have added this function to keep track of instances of the class. Let me explain me little bit about it, i have created a public function to make it accessible from anywhere and static because we are gonna access a static member of the class and we want this method to be available for use without creating any instance of the class. Rest is about checking for any other instance and allowing a instance to be created. So far so good but how shall we use it? Well it’s simple-

$classInstance = myClass::createInstance();   $response = $classInstance->myMethod();

This was the implementation of singleton pattern. Post your comments for your queries.

Content Source: http://www.raakeshkumar.in/

Today I am going to describe design patterns. The very first question that can arise in anyone’s mind is what is a design pattern? where we use it? why do we use it? hold on… let’s go through this one by one.

What is a design pattern?

In simple sentence, a design pattern is a way to design our software/application. Each design pattern addresses a problem or set of problem and describe a solution for it. So these design patterns help us understand those problems and solve them effectively.

Designing object-oriented software is hard, and designing a good, reusable object-oriented software is even harder. We need to find objects, factor them into classes at the right granularity, define class interfaces and establish relationship among them to make a good software. Our software design should be flexible enough that can handle future problems and for modifications. This means it’s impossible to find exactly right design for any software but we can make it in such a way that can cover maximum solutions for future issues.

Why and where we use it?

It’s one of the most time taking process in any software design, as per my experience. And it takes a long time for someone to learn these design patterns from scratch. An experienced architect never solve any problem from first rules rather they use experience that have helped them in past. Consequently, we find recurring patterns of classes and their communications. These patterns solve some specific design problems and make object-oriented designs more flexible, elegant and reusable, which is the main philosophy behind object oriented systems.

So at this point now we are able to define what is a design pattern? Its a description of communicating objects and classes that are customized to solve a general design problem in a particular context.

So basically a design pattern has following elements –

  1. 1. Problem
  2. 2. Solution
  3. 3. Future consequences

Still one question can come into ones’ mind that How these design patterns solve design problems?

Well its a vast topic and lets walk through it.

Design patterns solve many problems object-oriented designers face.

Followings are few of them –

Designing appropriate objects – The most complex part of any object-oriented design is decomposing a system into objects. This is difficult because of many factors like our object should be reusable, it should address future problems, should be flexible etc. Think of a scenario where an architect designs a bad software, how costly that can be for the organization in future? So design patterns helps you identify your problems and create objects that can capture them.

Determining Object Level – Objects can vary in size. They can represent anything from hardware to the complete application. So how do we decide what should be an object? Design pattern solves this problem also.

In this context let me introduce you with very common terms of object-oriented design. Every operation declared by an object specifies the operation’s name, the objects it takes as parameters, and the return value. This is known as the operation’s signature. The set of all signatures defined by an object’s operations is called the interface to the object. An object’s interface characterizes the complete set of requests that can be sent to the object. An object is the set of operations it can perform and set of states it can be in. There are several kind of design patterns e.g. Abstract, Factory, Singleton etc. I will try to cover them in my next posts.

Content Source: http://www.raakeshkumar.in/