Exclusively for you!! Trial version of Google Apps, Apply Coupon-CNHPGX6T6QRWGV!!
C#: Singleton Design Pattern
May01

C#: Singleton Design Pattern

Welcome to CodeSpread! We know the existence of a design pattern is dependent on a recurring problem. Once the problem is identified, then a well established solution is proposed theoretically and different implementation techniques were tried and adopted to resolve the problem. Now, These solutions were always available but it took some time to frame them as a design pattern. Today, we will take up one of the design pattern called ‘Singleton’. What does Singleton offer? To answer this, we need to look at the benefits of a ‘normal class’ and a ‘static class’. A normal class can be instantiated ‘n’ number of times in a program and gets the memory allocated to this instance.Plus, these instances can be destroyed to free up the memory. A static class provides a global point of access. Now, Singleton takes advantage of both the benefits defined above. The Singleton pattern restricts the class to be instantiated ONLY once and has a global point of access. In other words, class is static but can be instantiated. We can summarize the Benefits of Singleton Pattern: Instance control: Singleton creates only one instance and prevents any more copies, ensuring that all objects access the single instance. Flexibility: Class controls the instantiation process. Parameters: Singletons can be used as parameters or objects. How it can be implemented? Follow these steps to create a Single pattern. Declare a static object variable. Declare private constructor to avoid new object crection Declare a Public property which can be accessed outside of the class Instantiate an object and assign it to the private variable in getter. public class Singleton { // Private static object. private static Singleton instance; // Private constructor prevent object creation. private Singleton() { } // A public property to access outside of the class to create an object. public static Singleton Instance { get { if (instance == null) { instance = new Singleton(); } return instance; } } } Example: If we are designing a logging system then only one instance of logger is required to handle the log requests coming from different sources. Here, singleton can be applied. Discussion: There is an interesting discussion on stackoverflow over singleton. http://stackoverflow.com/questions/137975/what-is-so-bad-about-singletons Some points from the discussion: They are generally used as a global instance, why is that so bad? Because you hide the dependencies of your application in your code, instead of exposing them through the interfaces. Making something global to avoid passing it around is a code smell. They violate the Single Responsibility Principle: by virtue of the fact that they control their own creation and life-cycle. They inherently cause code to be tightly coupled....

Read More
DI: Dependency Injection Summary
Apr30

DI: Dependency Injection Summary

Here is a summary of Dependency Injection implementation. This ppt is also available for download. Download (PPT, 941KB) You can also check the same ppt on our youtube...

Read More
Simplify Dependency Injection(DI) and Inversion of Control (IoC)
Dec24

Simplify Dependency Injection(DI) and Inversion of Control (IoC)

We have discussed the concept briefly in one of our previous article, SOLID. Today we will try to understand them in detail. Before moving to details,we have to remember one major point, “Inversion of Control is a principle and Dependency Injection is the implementation”. Let’s talk about the principle first. What is Inversion of Control? Wikipedia says “Inversion of control (IoC) is a programming technique, expressed here in terms of object-oriented programming, in which object coupling is bound at run time by an assembler object and is typically not known at compile time using static analysis.” Phew! I didn’t understand a word out of it. It’s the time that we should rephrase it. “Existence of dependent objects should not depend on each other”. It works on the understanding that in our application, we keep on creating objects and sometimes creation of one object is dependent on other object means a tight coupling exists between them. Such scenario is not favorable for the application and should be avoided. We will go with a universal example to explain this scenario. public class Car { private Engine engine; public Car() { engine= new Engine (); } } Just see the dependency between Class Car and object Engine.If we are going to create an object of Class Car, we will get an object of Engine as a package deal. OR if we dispose the car object later, object Engine will also get destroyed. More than that, Car has no control as which type of engine it requires. Now we will apply IoC principle to it. public class Car { private IEngine engine; public Car(IEngine engine) { this.engine= engine; } } We have passed a variable of IEngine to the constructor and with that, creation of object Engine is controlled by object Car so object Car can choose the type of Engine.The important point is object Engine will not be created by object Car and they will be loosely coupled. The purpose of the example is There is a decoupling of the execution of a certain task from implementation. Every module can focus on what it is designed for. Modules make no assumptions about what other systems do but rely on their contracts. Replacing modules has no side effect on other modules.[Wikipedia] What is the importance of IOC? Or Why it is required? We figured out few points which strongly favored IoC Loose coupling: Tight coupling will have lots of problem in real world applications as things tends to change in future so Loose Coupling is the most voted option available. Fast and Easy Deployments: As objects or components are independent, So each of...

Read More