This chapter is from the book
This chapter is from the book
This chapter is from the book
1.4 Using Frameworks
When using a framework it is important to first ensure you get a framework that will give you the most reuse within your intended usage objectives. In other words, you want a framework that is well aligned with your needs. You don't want to spend all your time rewriting core elements of the framework—not only will you be getting very little value from the framework but you will also likely introduce difficult-to-debug errors because you don't understand all of the subtleties involved in the interaction between framework parts. In our planet example, if most of your planets have rings or moons, you probably don't want to use the framework we suggested in the example. As always, it is never that easy. Depending on how much effort you put into the development process, you might find a framework for creating arbitrary gravitational bodies that interact (planets, moons, comets, and so on) or discover a novel way to use our example framework to create two planets, one big and one small, and then place the smaller planet into orbit around the bigger one—voila, you now have a planet with a moon.
When looking for a framework to use, you have to realize that frameworks lie between two extremes: class libraries and applications. Although frameworks can be built on class libraries, they supply more than the class library's independent pieces, such as decimal support, time support, or a group of reusable collections. Frameworks that try to cover too much can become class libraries. And, even worse, these overextended frameworks can often create linkages between elements that make the frameworks difficult to use even as class libraries. On the other side of frameworks are applications. This is where frameworks that are too focused (that is, don't have enough extensibility) end up. This is not to say that any one of these solutions is better than another, only that you should pick the right one for your particular problem.
When should you use a framework? When you see the need to create a number of applications or a highly customizable application (because of the broad customer needs) in a particular domain (or domains) and you see that there is a common core of processes and functions, use a framework. The framework normally embodies the part you hate to reinvent every time you write that application, the part you hate to test every time, the part you would rather pay for once and never have to pay for again. Depending on the size and scope of this core, you'll use either a class library or a framework.
Once you've decided to use a framework and have found a suitable one, you need to integrate the use of the framework into your development process. Frameworks are more than pieces that can be reused when implementing your application. Depending on the scope of the framework, it may establish an underlying architecture to which you need to adhere.
A framework also provides a design for a solution to a domain process—such as a business process. You want to use these processes as soon as possible, taking advantage of the framework's work by reusing it. If you wait until you are implementing the code, you may be able to take advantage of certain pieces, but you won't get the greatest reuse—unless you come up with the same design, which is extremely unlikely. The best way to use a framework is to reuse it as soon as possible in your development process.
If you don't have a development process, it will be difficult if not impossible to use a framework. Our experience is that no matter what type of software you are developing, following some type of process, like the Unified Software Development Process [Jacobson 99] or the Extreme Programming (XP) process [Beck 00], greatly increases a project's chance for success.
The most effective way to use a framework is to add mapping steps to each step in your development process. This mapping involves stopping and taking a look at what the framework provides. If you are developing requirements, look for matching requirements. If you are designing your application, align your design with framework design elements. The key is that you must explicitly incorporate and enforce the mapping process—it is much too easy to skip the mapping step, especially if this is the first time using a framework. The most benefit is gained from a framework if you can map early (see the Map Early, Map Often pattern, Section 9.2). If you map at the requirements level, not only will you be able to reuse the use cases but also the analysis, design, implementation, and testing will have already been done for you. For example, if you are building currency conversion support into your application, your requirements are likely to include the abilities to convert currencies, to have the exchange rate vary daily, and to use different exchange rates for hard currency versus traveler's checks. In the IBM SanFrancisco framework [Monday 99], these requirements, stated more generically, are directly supported by the framework: establishing exchange rates via date or period and supporting exchange rate tables for whatever the user wants to define. We can map from those requirements to the framework requirements and start the reuse at this highest level.
While mapping is key to using a framework, it is also the bane of framework use. You need to know what there is to map to (see the Just Learn It pattern, Section 9.1). You are trying to deliver a product, so you don't have infinite time for the mapping stages. You map to what you know about and what you've discovered so far. How much time can you spend learning and discovering? You should spend as much time as you can up front—before you start using the framework. There's probably a core you have to learn (which the framework documentation should identify); after that you can grow your knowledge over time. Even if you don't understand the entire framework up front and you miss something you could have reused, you will still benefit from the things you did reuse.
You can also use a framework as an example. To support mapping, a framework should provide end-to-end documentation and development artifacts. This level of documentation, if done correctly, gives you, in essence, an in-depth case study of one way to approach a domain through all phases of development, including the patterns used as the framework was developed. Often these patterns can be used completely independently of the framework, especially if they have been truly captured as patterns.