Posts tagged: Factory Pattern

Quick and Short: Design Pattern

comments Comments Off
By Ashish Khandelwal, March 10, 2010

This article is written under ‘Quick and Short’ edition. In this article I will explain about verious Design Patterns.

Read more Quick and Short articles.

Design Pattern

Design patterns are recognized solutions to common problems defined originally by the Gang of Four programmers.

Design patterns are tried and tested solutions for recurring problems in a given context. So basically you have a problem context and the proposed solution for the same. Design patterns existed in some or other form right from the inception stage of software development. Let’s say if you want to implement a sorting algorithm the first thing comes to mind is bubble sort. So the problem is sorting and solution is bubble sort. Same holds true for design patterns.

The various patterns are commonly divided into several different groups depending on the nature of the design problem they intend to solve.

Creational Patterns

  • Factory - This pattern is used to create concrete class instances without specifying the exact class type.
  • Abstract Factory – This pattern is used to create concrete class instances without specifying the exact class type. The Abstract Factory Pattern provides a way to encapsulate a group of individual factories that have a common theme.
  • Singleton - This pattern insures that only a single instance of a given object can exist.
  • Builder – This pattern separate the construction of a complex object from its representation so that the same construction process can create different representations.
  • Prototype:- A fully initialized instance to be copied or cloned

Structural Patterns

  • Adapter – Convert the interface of a class into another interface clients expect. Adapter lets the classes work together that couldn’t otherwise because of incompatible interfaces
  • Bridge – Decouples an abstraction from its implementation so that the two can vary independently.
  • Composite – Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.
  • Decorator – Allows an objects behavior to be altered at runtime.
  • Facade – Used to provide a simpler interface into a more complicated portion of code.
  • Proxy – Provides a Placeholder for another object to control access to it.

Behavioral Patterns

  • Flyweight – A fine-grained instance used for efficient sharing.
  • Chain of Responsibility – The chain of responsibility pattern is a way of communicating between objects.
  • Command - Encapsulates a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations.
  • Iterator – Provides a way to sequentially access aggregate objects without exposing the structure of the aggregate.
  • Mediator – The mediator pattern encapsulate the interaction between a set of objects.
  • Memento – Allows you to save the state of an object externally from that object.
  • Observer – Allows a single object to notify many dependent objects that its state has changed.
  • State – Allows an object to change its behaviour when its internal state changes.
  • Strategy – Allows multiple algorithms to be used interchangeably at runtime.
  • Visitor – The visitor design pattern enables us to create new operations to be performed on an existing structure.
  • Template Method -  Defines the skeleton of an algorithm then lets subclasses implement the behaviour that can vary.
  • Interpreter - A way to include language elements in a program.

——————————————————————————————————————————————————————

Readers are requested to add comment, and add more information in case they want.

Read more Quick and Short articles.

VN:F [1.7.2_963]
Rating: 5.0/5 (1 vote cast)

Factory Pattern

By Ashish Khandelwal, September 14, 2009
There are many cases in the Framework where you can obtain a new instance of a struct or class without calling its constructor yourself. The System.Convert class contains a host of static methods that work like this. To convert an integer to a Boolean, for example, you can call Convert.ToBoolean and pass in the integer. The return value of this method call is a new Boolean set to “true” if the integer was non-zero and “false” otherwise. The Convert class creates the Boolean for you with the correct value. Other type conversion methods work similarly. The Parse methods on Int32 and Double return new instances of those objects set to the appropriate value given only a string.
This strategy for creating new object instances is known as a Factory pattern. Rather than invoking the object’s constructor, you can ask the object factory to create the instance for you. That way, the factory class can hide the complexity of object creation (like how to parse a Double out of a string). If you wanted to change the details of creating the object, you’d only have to change the factory itself; you would not have to change every single place in the code where the constructor is called. Read more »
VN:F [1.7.2_963]
Rating: 0.0/5 (0 votes cast)

Discover the Design Patterns You’re Already Using in the .NET Framework

By Ashish Khandelwal, September 14, 2009
Recently, Microsoft has placed increasing emphasis on design patterns. If you are unfamiliar with patterns, suddenly being inundated with new terms and foreign-looking UML diagrams can be overwhelming. This emphasis on patterns, however, doesn’t represent a shift in methodology so much as a change in vocabulary. The Microsoft® .NET Framework base class library (BCL) already makes extensive use of patterns, and you are probably familiar with the most common ones, even though you might not realize it yet.
In this article, I’ll cover a basic overview of several common design patterns and how they are used in the BCL and other areas of the .NET Framework. In doing so, you can discover some of the motivation for why the Framework is designed the way it is, as well as make the abstract concepts of the patterns themselves more intuitively understandable.
Most of the patterns I’ll be covering come from the canonical reference, Design Patterns by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, (Addison-Wesley, 1995). These authors are collectively known as the Gang of Four. The Gang of Four didn’t invent these patterns, but they documented and formalized the good work others had been doing since the beginning of software development. Read more »
VN:F [1.7.2_963]
Rating: 0.0/5 (0 votes cast)