Command Pattern

Command Pattern

In a nutshell, we have a group/set of behaviors and want them to treat them uniformly. We want to program them against the single interface. We want the Clients of these related set of behaviors to be treated uniformly. Client is coded against the Interface that the different commands also implement. Client is not aware of different concrete implementation of the commands. Thus these commands can vary their details and implementations and client will be not affected with this.

Usually we have in-memory collections of such commands initialized at the program startup. At start up all the dependencies and context required to the work are loaded at that time. So that command server clients efficiently.  So much of context and dependencies required for a Command Objects to do its job is pre-fetched at start up. Client gets Command Object from HashTable or HashMap holding all command objects and execute their methods to do the work. BCS Bookstore. Commands may be singletons that only one object is enough to do the job.

In a nutshell, we have set of commands, and all are at the same level and we want them to be treated as the same. We do not want big SWITCH statement for the command that we want to execute. The factory or some other mechanism will specify what kind of command we want to execute. Command line applications and the UI Menu based operations are example of such patterns.

Pattern Quotes

A pattern is really a design template ti be used in the design phase. It is most of the time related to the structure of a group of objects or to the way those objects interact together. 

Fundamental to any science or engineering discipline is a common vocabulary for expressing its concepts, and a language for relating them together. The goal of patterns within the software community is to create a body of literature to help software developers resolve recurring problems encountered throughout all of software development. Patterns help create a shared language for communicating insight and experience about these problems and their solutions. Formally codifying these solutions and their relationships lets us successfully capture the body of knowledge which defines our understanding of good architectures that meet the needs of their users. Forming a common pattern language for conveying the structures and mechanisms of our architectures allows us to intelligibly reason about them. The primary focus is not so much on technology as it is on creating a culture to document(see:http://www.visa2003.com) and support sound engineering architecture and design.

When to use Singleton or Class with only static methods

Singleton is used when frequently create the instance of the class with same same Data Members or No Data Members and the Constructor is Parameter less only. We always need object with same data member configuration. Also, this design pattern is imminent, when Context or Data Members of the objects are very expensive to create. For example they involve reading or writing from File, Database, Configuration Files, Loading an Image in the memory, Loading Excel File, Invoking a Web Service. We need to use this class

with same data member configuration. We need to use this class in the same Context.
Singleton is also applicable when we use a Third Party or .NET framework provided class but we use it
with the same Context or Configuration of Data Members. It better to have new class that compose the
Used Class and have Singleton mechanism for the newly created class.

Class with static methods is used when the Class has not Data Members or Context at all and the methods are stand alone and they have no dependency on class data members. then it is always best to have static methods.

Dependency Injection Design Pattern

Dependency Resolution

Dependencies can be injected at compile time (hard-coded), deployment time (configuration based or dependency injection container) at run-time (specified from the UI). Technically, dependencies can be specified in the constructors, property setters and methods. Containing class can have a data member to hold the Strategy object. But .NET provide Funcs/Anonymous  delegates or lambda expressions to refer the method/behavior/strategy that can be passed to class at runtime.

Usually constructors take the arguments while creating the object, these input are the dependencies of the 

object those needed to be full filled before we can get the intended functionality of the object. All dependencies must be specified before invoking the intended functionality of the object.

Alternatively put, software loaded in the RAM is nothing but an object graph loaded in the memory that 

gives us intended functionality. This object graph is composed by different type of relationships among the objects. This web of objects loaded in the memory in the form of object graph is important. This object graph can extend and new objects become the part of object graph as the software is executed and different objects are initialised. Lazy loading of objects is also related to this.

Dependency Injection allow us to compose this object graph dynamically based on the XML files. So the objects are not wired or composed in a hard manner. They are wired and composed based on the XML configuration files. Dependency Injection containers are the composition engines those read the XML configuration files and compose the files accordingly.

Structure Map, Windstle Caster, MEF Managed Extensibility Framework, Unity, are the examples of DI Containers.

Dependency can specified in XML configuration files those can be loaded by DI container or by the Configuration mechnims provided by the development platform. 

Depency can be specifed the GUI control, user select the type of dependency that is needed to be injected.