Site Archive (Complete)
Architecture Blog: Frameworks vs. Libraries
Architecture & Design

Modeling, Managing, Making it Right.

by Jonathan Erickson

... Will they Come?

by Arnon Rotem-Gal-Oz
July 07, 2006

Frameworks vs. Libraries

I was talking with Udi the other day about how a GIS library that was used on a project we were working on together should have been designed as a framework.

This brought about two interesting questions:

  • What is the difference between a library and a framework?
  • Why would you prefer one over the other?

Libraries are the older concept and these are just collection of utility classes/methods your code calsl upon to get some functionality. Frameworks, on the other hand, contain some functionality or flow and calls your code to extend or make the flow a specific one. The principle of frameworks calling your code is known as "Inversion of Control."

There are several mechanisms you can use to provide Inversion of Control including:

  • Subclassing
  • Dependency Injection
  • Template Methods
  • Closures
  • etc.

While frameworks are newer than libraries, they are nonetheless not very new themselves; see, for example, the 1988 paper "Designing Reusable Classes", by Ralph E. Johnson and Brian Foote. (Granted, the examples they give are outdated, but it still provides a very interesting reading.)

Why use a framework instead of a library? For one thing, it is a matter of visousity. When you have a library you need to understand the functionality of each method and it is relativly hard to create complex interactions as you need to invoke many methods to get to the result. Frameworks, on the other hand, contain the basic flow and since you only need to plug in your behavior it is easier to do the right thing. In the GIS example that prompted this discussion, it would be better to have a framework since there a hundreds of interfaces you can use. However, what most users want is an easy way to make a UI entity appear on a map.

The other advantages of frameworks over libraries is flexibility and extensibility. By definition, a framework provides you with the necessary means to extend its behavior. Many times you can even subclass the framework classes and provide completely new functionality.

The disadvantage of frameworks is that temptation to add more and more functionality creates a lot of bloated frameworks which results in immobility and needless complexity.

While frameworks have been over-hyped and "buzzword-ified" (like many other concepts), packing functionality as a framework is still something you should consider when you identify some piece of code as reusable.

Posted by Arnon Rotem-Gal-Oz at 10:43 AM  Permalink

Please log in to post comments.

This is a public forum. CMP Media and its affiliates are not responsible for and do not control what is posted herein. CMP Media makes no warranties or guarantees concerning any advice dispensed by its staff members or readers.

Community standards in this comment area do not permit hate language, excessive profanity, or other patently offensive language. Please be aware that all information posted to this comment area becomes the property of CMP Media LLC and may be edited and republished in print or electronic format as outlined in CMP Media's Terms of Service.

Important Note: This comment area is NOT intended for commercial messages or solicitations of business.


SDMG Websites:, DotNetJunkies, MSDN Magazine, Sys Admin, SD Expo, SqlJunkies, TechNet Magazine, Unixreview