Term of the Week: Framework
Most generally, a framework consists of two parts: a skeletal structure, a more detailed finished work that can be built on; and the blueprint for how that finished work is put together. For instance, consider the framework in a jumbo jet airplane. It not only supports the skin of the aircraft but from it you can see where the wings, fuselage, and other major parts of the finished plane will be. Within the programming community, that concept of a framework is frequently applied in both very broad terms to how projects are developed as well as very specific vendor "frameworks." This brief article looks mostly at the former category, examining just what exactly makes up a framework in software development and concludes with quick looks at a couple of common vendor frameworks.
So, in the most general sense, a programming framework is a set of concepts and methods that describes how projects are developed with it. The concepts of a framework should define the architecture of how projects should be developed within it and the methods should include class libraries and possibly design patterns that are reusable to simplify code creation. Using a framework goes beyond code re-use by cut and paste by also incorporating the models and designs in the re-used components.
Extensibility is another key component of frameworks. That is, the components of the framework need to be general enough that you can build many different things with it. Consider the framework to be like a set of Lego building blocks: With enough blocks and imagination you can build buildings, cars, robots, and spaceships. Contrast this with a model kit, where you can only glue the pieces together in one (useful) way to build one specific toy according to the directions. Unlike Legos, though, a good framework also incorporates the rules for how to use them. In this sense, you might think of the rules of a game, such as dominos, that dictates which sides of the dominos are allowed to fit together. This analogy can further be extended in that there are many different types of dominos and sets of rules the game can be played by, just as with frameworks two different frameworks could be built from the same class libraries but with different patterns and use rules.
A framework doesn't have to be something that a vendor supplies to support their particular products. A framework can be developed by any individual or group to support their own development needs. If you are part of a large development department with a large library of existing code, building a framework to coordinate your efforts, enforce standards, and increase productivity through increased code re-use makes sense. This makes special sense if the business needs that your applications support are highly unique and not well-suited to off-the-shelf code classes.
Finally, some of the very popular and well-known vendor frameworks are Microsoft's .NET Framework and the Struts and Cocoon frameworks for Java. In the .NET Framework, Microsoft provides their "common language runtime" (CLR) that allows developers to work in many different supported languages. The other key ingredient in the .NET Framework is the class library that provides some common functionality in prebuilt packages that developers can tap into. ASP.NET is an example of one of the .NET Framework class libraries.
For Java, both Struts and Cocoon are Apache projects and both areWeb development frameworks. Cocoon's primary claimed advantage is more XML integration at the core. Struts is primarily centered around servlets and JSP.
Jim Minatel is a freelance writer for Developer.com in addition to working with Wiley and WROX publishing.