An important facet of system design is the manner in which objects are created. Although far more time is often spent considering the object model and instance interaction, if this simple design aspect is ignored it will adversely impact the entire system. Thus, it is not only important what an object does or what it models, but also in what manner it was created. Since most object-oriented languages and runtimes provide object instantiation (e.g. new, newobj, etc.) and initialization (e.g. constructors) mechanisms, there may be a tendency to simply use these facilities directly without forethought to future consequences. The overuse of this functionality often introduces a great deal of the inflexibility in the system, as the direct use of a language/run-time object instantiation function creates an explicit association between the creator and created classes. While associations are a necessary type of relationship in an object-oriented system, the coupling introduced between classes is extremely difficult to overcome should requirements change (as they always do). Since the need to reduce the inherent coupling associated with instance creation spans systems, it was not uncommon to see the same types of solutions being used in a variety of different applications and frameworks. Formalized within Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley Publishing Company, 1995), these solutions are known as creational patterns. Creational patterns describe object-creation mechanisms that enable greater levels of reuse in evolving systems. One of the most widely used creational patterns is the Factory.
Read On… http://msdn.microsoft.com/en-us/library/ms954600.aspx