Thursday, March 3, 2011

Design patterns vs Frameworks

Can someone illustrate what really is the difference between the two?

From stackoverflow
  • A design pattern is a concept, or a receipt for how to get a specific problem done.

    A Framework is code ready for use, usually packaged in a way that makes creating an application much easier.

    It does not make sense to explain the differences because they are two totally different things.

    Dan : Couldn't help myself: "A design pattern is a hack to overcome a deficiency in the source language. A framework is code ready for use..."
  • A design pattern is a well-established design for tackling a problem. A framework is an actual package of code you use to make building applications easier. Note that a framework can and probably will, make use of design patterns.

  • |------------------------|
    |          (------)      |
    |          (ClassA)      |
    |          (------)      |
    | (-----------)          |
    | ((Singleton))          |
    | (-----------)          |
    |         (---------)    |     
    |         ((Factory))    |
    |         (---------)    |
    |                        |
    |                        |
    |------------------------|
    
    Legend:
      |---|  Framework
      (---)  Class
      ()     Design Pattern
    

    A framework is a set of related classes to perform a certain task. Those classes may or may not implement a certain design pattern.

    Dan : Boo for using counting singleton as a design pattern, +1 for nice explanation. :-P
    Vinko Vrsalovic : It is a design pattern, whether it is overused and misused or not. :P Thanks for the upvote.
  • From Object -Oriented Software Development Using Java by Xiaoping Jia:

    Although both design patterns and frameworks are mechanisms used to capyure reusable designs, they are quite different. On the one hand, design patterns are schematic descriptions of reusable designs that are not concrete programs and that are language independent. On the other hand, frameworks are compilable programs written in a specific programming language and often contain abstract classes and interfaces. Design patterns are the architectural building blocks of frameworks. They help make frameworks extendable and reusable. Frameworks usually contain implementations of many cooperating design patterns.

  • Even though they are two very different things, one can argue they both solve a software architecture problem

    • a design pattern solves many software architecture issues (about creation, behavior, concurrency, ...) with different pre-defined design. (design being an implementation of an architecture topic)

    • a framework is based on the Hollywood Principle ("Don't call us, we call you"), where you implement some high level requirements as specified, and leave the framework do the rest of the work, calling your implementations.

    A key difference is the scope cohesion:

    • design pattern have a tight scope:

      • class design patterns (involves classes)
      • business design patterns (involves business workflows)
      • application design patterns (involves applications)
    • framework has a large scope:
      For instance, .NET is a framework composed of:

      • a language (C#)
      • a runtime environment (CLR)
      • a collection of libraries
        Just develop what you need and let the .Net framework call your classes.
  • A design pattern is a standard solution to a well known (design) problem. For example the Factory pattern, and the Abstract Factory pattern offer a blueprint for implementing designs to overcome common problems with instantiating objects.

    A framework on the other hand contains infrastructure which you can use and extend to develop your own solution. For example a model 2 "web application framework" will contain the infrastructure for building web based applications. It will contain the controller, some gui elements and base classes which we can extend to create our model and business logic. Typically it contains plumbing code and interactions which we inherit when we extend from their base classes. Some examples of frameworks are Struts, JSF, Swing Application Framework, JUnit testing framework, etc...

    Going a step ahead there are also libraries, which we use directly from our code. Usually without extending their classes. Log4J would be an example of a library.

  • Frameworks are more specific to a problem definition. In order to write one design patterns can be devised or used where ever applicable.

  • Here is GOF's answer:

    Because patterns and frameworks have some similarities, people often wonder how or even if they differ. They are different in three major ways:

    • Design patterns are more abstract than frameworks. Frameworks can be embodied in code, but only examples of patterns can be embodied in code. A strength of frameworks is that they can be written down in programming languages and not only studied but executed and reused directly. In contrast, the design patterns in this book have to be implemented each time they're used. Design patterns also explain the intent, trade-offs, and consequences of a design.

    • Design patterns are smaller architectural elements than frameworks. A typical framework contains several design patterns, but the reverse is never true.

    • Design patterns are less specialized than frameworks. Frameworks always have a particular application domain. A graphical editor framework might be used in a factory simulation, but it won't be mistaken for a simulation framework. In contrast, the design patterns in this catalog can be used in nearly any kind of application. While more specialized design patterns than ours are certainly possible (say, design patterns for distributed systems or concurrent programming), even these wouldn't dictate an application architecture like a framework would.

0 comments:

Post a Comment