1 how to design frameworks -- copyright 2005 by ralph e. johnson how to develop frameworks ralph e....

1

How to Design Frameworks -- Copyright 2005 by Ralph E. Johnson

How to Develop Frameworks

Ralph E. Johnson

Dept. of Computer Science

1304 W. Springfield Ave.

Urbana, IL 61801

http://st-www.cs.uiuc.edu/users/johnson/

[email protected]

(217) 244-0093

2


What is a Framework

?Framework:

• is reusable design of an application or subsystem

• is represented by a set of abstract classes and the way objects in those classes collaborate.

• is overly simple program that can be extended to make real program.

• tells how to decompose a problem into objects.

• is not just the classes, but the way instances of the classes collaborate.

3


What is a Framework?

Just a program - but one that can be easily extended.

Complex pattern - made up of several simpler design patterns.

Inversion of control -- "don't call us, we'll call you".

4


How to Use a Framework

Use framework to build application by:

• Creating new subclasses

• Configuring objects together

• Modifying working examples (editing scripts)

.

5


Parts of a system

Framework

• Framework (abstract classes)

• Library

Application

• Concrete subclasses

• Other classes

• Script (in programming language or in XML)

6


Reasons to Use Frameworks

Framework used

• to simplify existing code

• to build applications quickly

• to make applications more consistent

• to meet standard

• to make maintenance easier

7


Disadvantages of Frameworks

More complex (powerful) than necessary.

Slower and larger than necessary.

Takes time to learn.

Difficult to develop

8


How to Develop Frameworks

Start with applications.

Refactor to simplify designs and share code.

Build more applications.



…

When new applications no longer require refactoring shared code, the framework is done.

9


First Rule of Framework Design

Don't. You don’t really need it.

Don't. Use an existing one.

or

10


Frameworks and XP

Is framework the simplest thing that could possibly work?

• Yes - if you already know it.

• No - if you have to design it.

• Yes - if you are building 20 similar applications.

• No - if it doesn’t quite do what you want and it is not clear how to change it.

Only use a framework when it is cost effective.

• Never know for sure

• Include learning, documentation

11


Theme for Designing Frameworks

Framework design is derived from application design.

Design frameworks to be overly simple and concrete, and refactor to be more reusable.

Refactoring: Improving the Design of Existing Code, Martin Fowler, Addison-Wesley 1999.

Design Patterns: Elements of Reusable Object-Oriented Software, Gamma, Helms, Johnson, Vlissides, Addison-Wesley 1995.

12


Relevant Principles

Frameworks are abstractions: people generalize from concrete examples

Designing reusable code requires iteration

Frameworks encode domain knowledge

Customer of framework is application programmer

13


Generalize from Concrete Cases

People think concretely, not abstractly.

Abstractions are found bottom-up, by examining concrete examples.

Generalization proceeds by

• finding things that are given different names but are really the same,

• parameterizing to eliminate differences,

• breaking large things into small things so that similar components can be found, and

• categorizing things that are similar.

14


Frameworks are Generalizations

Frameworks are OO programs generalized to fit many examples.

Common ideas become abstract classes.

Objects parameterized to make them reusable.

Ad-hoc systems broken down into smaller parts.

Use inheritance to organize class library.

15


Finding Abstract ClassesAbstract classes are discovered by generalizing from concrete

classes.

To give two classes a common superclass:

• give them common interface

+ rename operations so classes use same names

+ reorder arguments, change types of arguments, etc.

+ refactor (split or combine) operations

• if operations have same interface but different implementation, make them abstract

• if operations have same implementation, move to superclass

16


Eliminating Refused Bequest

S

doB

X

doA

doB

doC

Clients never use doC

X

doA

doC

Y

doA

doDY

doA

doD

17


Applying the Composite Pattern

WholePart

*

WholePart *

Component

W

P P

P

W

P PP

W

P P

18


Frameworks Require Iteration

Reusable code requires many iterations.

Basic law of software engineering

If it hasn't been tested, it doesn't work.

Corollary: software that hasn't been reused is not reusable.

19


Frameworks Encode

Domain KnowledgeFrameworks solve a particular set of problems.

Not necessarily application-domain specific, but domain specific. (GUI, distribution, structured drawing editor, business transaction processing, workflow)

If you aren’t a domain expert when you start to build a framework, you will be when you are done!

20


Customers are Application

ProgrammersPurpose of framework is to make it easier to build

applications.

Applications are user stories/test cases of frameworks.

Framework design driven by application design.

21


Up-front Design of Framework

1) Analyze problem domain

• Learn well-known abstractions.

• Collect examples of programs to be built from framework. (Minimum of 4 or 5).

2) Design abstraction that covers examples.

3) Test framework by using it to solve the examples.

• Each example is a separate application.

• Performing a test means writing software.

Analysis Design Test

22


Typical Way to Develop Framework

Notice that many applications are similar.

Develop next application in that domain in an OO language.

Divide software into reusable and nonreusable parts.

Develop next application reusing as much software as possible.

Surprise! Framework is not very reusable.

Fix it.

23


My Way to Develop Framework

Start with applications.





…

When new applications no longer require refactoring shared code, the framework is done.

24


Nine Steps in Developing Frameworks

1) Three Examples

2) White-box Framework

3) Component Library

• Build applications and add components to library

4) Hot Spots

• Separate Changeable from Stable Code

• Reduce the amount of code that is written.

• Eliminate duplication, split classes/methods into parts that vary and parts that don’t.

• Design Patterns

25


Nine Steps in Developing Frameworks

5) Pluggable Objects

6) Fine-grained Objects

7) Black-box Framework

8) Visual Builder

9) Language Tools

http://st-www.cs.uiuc.edu/users/droberts/evolve.html

26


White-box vs. Black-box

Black-box

Customize by configuring

Emphasize polymorphism

Must know interfaces

Complex, harder to design

Easier to learn, requires less programming.

White-box

Customize by subclassing

Emphasize inheritance

Must know internals

Simpler, easier to design

Harder to learn, requires more programming.

27


Examples

Good examples are crucial:

• for finding framework

• for teaching framework

Examples define scope of the framework.

Concrete examples abstract framework

28


Finding Examples

Start with similar examples.

• should illustrate features that framework must support

• provides a base for generalization

Eventually examples should cover wide range.

• minimize number of examples

Look for examples that will break the framework.

• perhaps they will define limits of framework

• perhaps they will lead to generalization

• avoid lots of special cases

29


Advantages of Black-box FrameworksReplace reuse by inheritance with reuse by object

composition

-> change behavior without defining new classes.

Ultimate black-box framework lets you plug objects together with visual language.

Application development doesn't require programming.

30


Disadvantages of Black-box Framework

Black-box frameworks harder to design and harder to make powerful.

Black-box framework tends to have

• more kinds of objects

• more artificial kinds of objects

• more complex relationships between objects

• more objects

Not-quite-ultimate framework forces you to debug more complex system.

31


Visual Builder

It is easy to draw pictures of an application made from a black-box framework.

It is easy to generate code from a picture for a black-box framework.

It is easy to make special-purpose visual programming languages for black-box frameworks.

Visual programming languages let non-programmers build applications.

32


Language Tools

Warning! New languages require new tools.

Do you really want to support debuggers, testing tools, performance analyzers, configuration management?

Is this new environment any better than the old one?

33


Hints for Framework Design

Use object composition instead of inheritance

Incrementally apply patterns / lazy generalization

Framework should work out of the box

34


Size Matters

Must decide which frameworks to build.

Must schedule new releases.

Documentation.

Training

Small Large

When you spot an abstraction that looks useful, generalize.

Periodically take time to clean up your design.

Explain design to your peers when they need to understand it.

35


Strategic Concerns

Developing a framework is expensive, so look before you leap.

• Framework development requires long term commitment.

• Pick frameworks that will give you competitive advantage.

• Start small and work up.

- get experience with OOP

- select and train good abstractors

- build small frameworks first

- generalize existing systems

36


Customers are Crucial

Framework development is easiest if all the developers are working on the same team.

If framework users are on a different team, make sure the initial set succeed.

First set of customers are really part of the development team.

• their input is critical

• they will suffer from redesign of framework

• they must feel that their contribution to framework is important

37


Reuse Scenarios

Ideal: Successive versions of your framework meet the needs of a growing customer base.

Actual: Projects may customize the initial framework, and even start competing streams of development.

38


Dealing with Iteration

Don't claim framework is useful until your customers say it is. This will take two or three versions.

Keep customer base small while framework is evolving.

A successful framework is a living framework, evolve it to meet new customer needs.

Don't constantly tinker. Plan releases and coordinate with customers.

39


Documentation and Training

Documentation for framework costs several times usual

• how to use

• how to extend / how it works

Software must be understandable to be usable.

Improving documentation can make software more reusable.

40


Documentation and Training

Base documentation on examples.

Must debug documentation and training.

Documenting system shows how to change it.

Framework developers must be intimately involved.

1 how to design frameworks -- copyright 2005 by ralph e. johnson how to develop frameworks ralph e....

Documents