Patterns for Successful Object-oriented Framework Development
This chapter is from the book
This chapter is from the book
This chapter is from the book
Andreas Rüping
Introduction
Object-oriented frameworks play an important role in many IT projects these days. Frameworks allow us to reuse not only code, but abstractions and designs as well. Projects typically build a framework with the intention of large-scale reuse.
It’s a difficult job, though. There are things that make framework development particularly hard. Reuse may be a promising goal, but finding abstractions is difficult. Frameworks can easily become too generic and, as a consequence, too complex and difficult to understand. Framework development can use up a lot of time and resources before it pays off.
Moreover, the context for framework development can be difficult. Ideally, a framework evolves from long-term experience acquired while building several similar applications [Brugali+1997] [Johnson+1998]. It’s fairly common, however, for a software development project to decide to build a framework after identifying a potential for reuse across several applications that are going to be developed, although this means that the framework and the applications will have to be developed more or less simultaneously.
Is this even possible? Is there a chance that a framework developed in such a difficult context can live up to its promise—the reuse of code and design?
This chapter presents a collection of patterns that address these questions. It is targeted at software architects and developers who consider building a framework to meet requirements for reuse. The patterns assume an overall context in which framework and application development take place, at least to some extent, simultaneously. Many of the solutions that the patterns recommend actually apply to framework development in general, but they are particularly useful in this specific context.
The patterns address a framework’s architecture, its development process, and questions of team collaboration. I have observed the patterns throughout many projects. The collection isn’t necessarily complete, but it does represent a useful set of core strategies.