Learning on the Job

Abstract Factory Type: Object Creational Intent : Provide an interface for creating families of related or dependent objects without specifying their concrete classes.  This will give you the ability to have diverse implementations for a common interface. Rough Description : Abstract Factory is the interface that you define to encapsulate all the objects of a certain family.  From there you can create what are called "Concrete Factory", which actually instantiates the family of objects for you.  Your client or consumer will only know of the interface.  Somewhere in your code, you will set the interface to your Concrete Factory which will do the heavy lifting of instantiating your objects. Applicability A system should be independent of how its products should be created, composed, or represented. A system should be configured with one of multiple families of products. A family of related products need to be configured together, and relations enforced . You

Essential Patterns to Know In the new posts, I'll be focusing on some suggested design patterns and evaluating them based on the components described in the last post. I will be covering: Abstract Factory (Creational) Adapter (Structural) Composite (Structural) Decorator (Structural) Factory Method (Creational) Observer (Behavioral) Strategy (Behavioral) Template Method (Behavioral) The following design patterns have been organized into three categories: Creational, Structural, and Behavioral.  Additionally there are categorize them by the scope of the pattern, if it is on the class (structure) or the object (implementation). Pattern Types Creation Design Patterns deal with how you create objects.  Creational class patterns will defer object creation to subclasses, whereas Creational object patters defer it to another object. Structural Design Patterns deal with the composition of classes and objects.  Structural class patterns use inheritance to compose

What is a Design Pattern? Going through the the design patterns book, one of the introductory paragraphs is to define what a design pattern is and why they exist.  The book splits it up into the following components: Pattern Name and Classification  - All design patterns have a name that is universally recognized and can describe it in a small amount of terms. Intent  - This is a short statement that answers the following What does the pattern do? What is the rationale and intent? What particular design issue or problem are we trying to address? Also Known As  - Other well-known names this algorithm may go as Motivation  - A scenario that illustrates a design problem and how the organization of your code can solve a particular problem. Applicability - In what situations can this pattern be applied Structure  - A graphical representation of classes in the pattern and how they interact between objects Participants  - Classes or objects participating in the design patte

Interfacing with Interfaces One of the first lessons that the design pattern book threw at me was to "Program to an interface, not an implementation".  Having more experience under my belt, I've begun to notice the importance of decoupling requirements and code, such that we can create well-defined, manage-able code. So what does this mean to me?  For a long time, interfaces to me was more boilerplate code that I would have to set up to define an object that I already had.  But as I grew to work on more and more complex systems, its been a godsend to be able to use interfaces to dynamically swap components at run time, and to allow our architecture to be more flexible and robust. How do I use it? One of the greatest uses of interfaces is to facilitate the contract / handler pattern that allows us to decouple our implementation of a service, and allow us to swap in any other service that follows the same spec. Designing Your System for Change Let look into this b