See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/243763805

How to Design Frameworks

Article · January 1993

CITATIONS READS
24 8,653

1 author:

Ralph Johnson
University of Illinois, Urbana-Champaign
215 PUBLICATIONS 42,584 CITATIONS

SEE PROFILE

All content following this page was uploaded by Ralph Johnson on 22 May 2015.

The user has requested enhancement of the downloaded file.

 Notes for OOPSLA '93

How to Design Frameworks

Ralph E. Johnson
University of Illinois at Urbana-Champaign

Department of Computer Science

1304 W. Springfield Ave.
Urbana, IL 61801

[email protected]
(217) 244-0093
1

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

Frameworks

Interface design and functional factoring constitute the key intellectual

content of software and is far more difficult to create or re-create than
code.
Peter Deutsch

Design of an application or subsystem.

Set of abstract classes and way objects in those classes collaborate.

Use framework to build application by:

• Creating new subclasses
• Configuring objects together
• Modifying working examples

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

 Notes for OOPSLA '93

Frameworks

Framework prescribes how to decompose a problem.

Not just the classes, but the way instances of the classes collaborate.

• shared invariants that objects must maintain, and how they maintain
them
• framework imposes a collaborative model that you must adapt to.

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

Frameworks for user interfaces (MVC, MacApp,Interviews, ET++, etc.),

operating systems, structured drawing editors, persistence, distributed
objects, oscilliscopes, ...

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

Goal of Framework Design

• Build application from preexisting components.

• Use small number of types of components over and over.

• Write as little code as possible

ultimate goal is zero code - build program by direct manipulation.

It shouldn't take a good programmer to build a good program.

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

 Notes for OOPSLA '93

Framework
• is result of domain analysis
• describes how to decompose problem
• represented by a program

Reuse of
• analysis
• design
• code

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

Generalizations Require 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.

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

 Notes for OOPSLA '93

Example-driven Design
Generalization
Examples Framework

Generalization is iterative, and lots of small changes are

interspersed with a few major changes that represent
breakthroughs in ways of looking at the problem.

System
size

Time
To generalize faster:
• get different points of view
• explain/defend current design
7

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

Ideal Way to Develop Framework

Analysis Design Test

1) Analyze problem domain

• Learn well-known abstractions.
• Collect examples of programs to be built from framework.
(Minimum of 4 or 5).
• Deciding whether an example is legitimate depends partly on
your vision for the framework.

2) Design abstraction that can be specialized to cover examples.

• Develop theory to explain these examples.

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

• Each example is a separate application.
• Performing a test means writing software. 8

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

 Notes for OOPSLA '93

Designing Abstractions

Design phase: look for commonalities, represent each idea once.

Good designers know many design patterns, techniques that they know tend
to lead to good designs.
• implies that experience is needed

Rules of thumb indicate ways to change design to fix common problem.

Insight and ingenuity is always useful, but hard to schedule.

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

Why Ideal is Never Followed

Analyzing domain requires analyzing individual examples, and

analyzing examples is already very hard.
• Only practical if examples have already been analyzed.
• Analyzing and implementing examples is large fraction
of the cost of the project.

Typically some applications (the one you want to do next) are

more important than others (the ones you have already
done) so some examples are analyzed more than others.

Old applications work, so there is no financial incentive to

convert them to use new software.

10

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

 Notes for OOPSLA '93

Good Way to Develop Framework

Pick two similar applications that need to be developed and that are
obviously in your application domain.

Make sure your staff has some people who developed earlier applications in
the same domain.

Divide project into three groups:

• framework group • 2 application groups
Both gives and takes software Try to reuse as much
Considers how other applications software as possible
would reuse framework Complains about how hard
Develops documentation and software is to use
training for framework

11

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

Typical Way to Develop Framework

Realize that many applications are similar.

Develop next application in that domain in an OO language.

Try to divide software into reusable and nonreusable parts.

Develop second application reusing as much software as possible.

Surprise! Framework is not very reusable.
Fix it.

Develop third application reusing as much software as possible.

Surprise! Framework is not completely reusable.
Fix it.

... 12

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

 Notes for OOPSLA '93

Problems with Reuse as a Side-effect

Conflicting goals
• get system out on time
• make it reusable

Hard to pay for reusability

Hard to enforce reusability

13

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

Framework for Investing

Ward Cunningham
• portfolio -- collection of instruments
• instrument -- stock, bond, cash fund
• has value, which can change daily
• transactions affect it, and it causes transactions
• transactions
• have a date
• can affect several instruments at once

14

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

 Notes for OOPSLA '93

More on Ward's Framework

Value of instrument at particular date is a function of the transactions that have

occured before that date.

Must be able to recalculate value of instrument at particular date when a

transaction gets posted to an earlier date.

Solution:
• cache - keeps value at a particular date
• calculator - given a cache and a set of transactions, computes another
cache
- calculator can compute interest, taxes, etc. as a side effect of
processing transactions.

15

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

Another Example

Accounting at a store
• journal -- collection of accounts
• account -- inventory, accounts payable (vender)
• has value, which can change daily
• transactions affect it, and it causes transactions
• transactions
• have a date
• can affect several accounts at once

16

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

 Notes for OOPSLA '93

Obvious Similarities

Investment system Accounting at a store

• portfolio • journal
• instrument • account
• transactions • transactions

Transactions are similar, and instrument and account are similar.

Each journal defines a new kind of account, and all accounts in a

journal are the same.
The same kind of instruments appear in every portfolio, and a single
portfolio has many kinds of instruments.

17

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

An Inventory Account

An invoice for a purchase increases inventory and increases amount owed to vender.

A sales transaction decreases inventory and increases amount sold to date.

Inventory #384 on hand sold this month this year purchased this month

30 100 1000 30
sales #6 (4) 26 104 1004 30
sales #8 (1) 25 105 1005 30
sales #13 (2) 23 107 1007 30
invoice #5 (50) 73 107 1007 80
sales #24 (1) 72 108 1008 80

18

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

 Notes for OOPSLA '93

Attributes

Each account has a set of attributes.

An attribute can be:

• total of a field taken from the transactions
• month-to-date, year-to-date, etc of another attribute
• function of several other attributes, i.e. inventory on hand is total
purchased - total sold - shrinkage.

Each attribute has a name (SalesMonthToDate).

An attribute is time-dependent, i.e. reading an attribute always requires

specifying a time.

19

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

Transactions

Transactions are just records: set of fields, some of which are multivalued.

Example: VendorInvoice
Vendor,
Date,
set of (Inventory type, Quantity, Price)
Payment due date, discount, etc.
Purchase Order number,
Total (can be computed from other fields)

Constrained Transaction: contains a field that depends on the values of

attributes of accounts

20

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

 Notes for OOPSLA '93

Transactions and Attributes

SalesOverShort SalesTransactions

Shrinkage
Inventory (IJ) Sales (SJ)
Journal Journal
Invoice

Accounts Payable General

Journal (APJ) Ledger (GL)

VenderPayment PayablesAdjustment GeneralLedger

Transaction

Inventory account might have to read value from SalesTransaction,

Invoice, and Shrinkage to compute an attribute.
Each kind of Transaction might give the value a different name.
Adding an attribute to an account requires specifying how to read values
for the attribute from each transaction posting to the account.
21

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

How Accounts is a Framework

Abstract classes - Account, Transaction, Attribute

Way objects interact:

Transaction -> Account - Transaction can post itself to set of Accounts
Account -> Transaction - Account sorts Transactions that are posted to it
Account -> Attribute - Account retrieves the value of an attribute at a
particular time by delegating to the Attribute object
Attribute -> Transaction - Attribute knows how to fetch value from
Transaction

22

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

 Notes for OOPSLA '93

How to use Accounts

Define Transactions and Accounts.

• define the Accounts to which a Transaction is posted

Define fields on Transactions.

Define Attributes on Accounts.

• define way Attribute is computed (+,*, mtd, ytd) by
selecting appropriate subclass of Attribute
• for each Transaction posting to an Account, define how
the Attribute gets a value

23

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

Examples

Good examples are crucial:

• for finding framework
• for teaching framework

Examples define scope of the framework.

Concrete examples abstract framework

24

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

 Notes for OOPSLA '93

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

25

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

What Examples for Accounts?

We've worked most on:

• store
• investment
We have thought about:
• payroll
• personal finance
• banking
• budgeting
We should consider:
• insurance
• manufacturing inventory

Once Accounts can handle several small examples well, scale up.

26

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

 Notes for OOPSLA '93

Process of Framework Design

Framework is generalization of implementation of several problems.

• study solution domain as well as problem domain

• need to look at real programs
• need a wide range of carefully chosen examples
• generalization is the same process that occurs in all object-oriented design
- find common abstractions
- figure how to decompose problem into standard components
- parameterize

There are common patterns of interaction that experts look for.

Example-driven: the examples you choose determine your framework

27

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

Scheduling Development

Software is not reusable until it has been reused.

Reusing software that is not reusable will point out reusability defects.

1) Domain analysis, collect examples (small group)

2) Make preliminary design (small group)
3) Implement examples (many groups)
In addition to the framework design group, there probably needs to be
a group for each example, unless the examples are small.
4) Fix framework and examples (many unhappy groups)

As usual, every order of magnitude increase in the number of users will

illustrate some (reusability) defects that you haven't detected before.

28

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

 Notes for OOPSLA '93

Design Patterns

Classes in framework can have many relationships between them.

Designers look for design patterns to increase reusability.

Superclass/subclass
Part/whole (component/container)
Builder/product
Delegator/delegatee
Double-dispatching

29

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

Composition vs. Inheritance

Two ways of reusing behavior

• inheritance
• composition

Inheritance
• easy to override inherited methods
• static (easier to reason about)

Composition
• less programming
• change behavior at run-time

One relationship can often be changed to the other.

30

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

 Notes for OOPSLA '93

Another Look at Accounts and Transactions

PurchaseOrder SalesTransaction All Transactions posted to an

Account must handle the
same set of operations.
Shrinkage Thus, all Transactions
Inventory (IJ) posted to an Account can
Journal be thought of as subclasses
Invoice
of a single subclass of
Transaction.
Accounts Payable SinceInvoice is posted to both
Journal (APJ) InventoryAccounts and
PayablesAccounts, it is a
VendorPayment PayablesAdjustment
subclass of both
InventoryTransaction and
PayableTransaction.

Multiple inheritance!
31

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

Simulating M.I. with Composite Objects

Multiple inheritance can always be simulated by dividing an object into pieces.

Sometimes this improves a design.

Idea:
Suppose C is a subclass of S1, S2, ..., Sn. Give C components C1, C2, ...,
Cn, where Ci is a subclass of Si for 0<i<n. Each Ci has a reference to
C, which has a reference to all the Ci, so each component can access
any other.

For Accounts:
Instead of making Invoice be a subclass of InventoryTransaction and
PayablesTransaction, make it be a composite transaction with
subtransactions that are InventoryTransactions and
PayableTransactions.

32

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

 Notes for OOPSLA '93

Composites

A Composite for T is a subclass of T that combines a group of instances of

subclasses of T and lets them act like a single instance of T.

Invoice is a composite Transaction because it combines a group of simpler

Transactions and lets them act like a single instance of Transaction.

Can we find composite Accounts?

Journal, Portfolio are groups of Accounts. Does it make sense to consider
them Accounts?
• what happens when transaction is posted to them?
• what does it mean to query their attributes?

33

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

CompositeAccount

What happens when Bob buys 100 shares of IBM stock?

The transaction "Bob buys 100 shares of IBM stock" is posted to Bob's
Portfolio, which in turn posts a transaction to an IBM stock account
that is part of the portfolio.

The value of Bob's portfolio is the sum of the values of the accounts in it.

What happens when an transaction is posted to a composite account?

• ask the transaction for the name of the component account, and then
post the transaction to the component account

What does it mean to query an attribute of a composite account?

• query that attribute of the component accounts and return the sum

34

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

 Notes for OOPSLA '93

Refactoring to Help Find Composites

If an operation is implemented by performing a second operation

on a component then make sure that the two operations have
the same name.

read file -> read disk

draw picture -> draw elements of picture

For Accounts:
Post transaction to journal -> post transaction to account
Result: CompositeAccount is an account made up of other
accounts.

35

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

Recursion Introduction

The way to find composites.

If message names cannot be identical, make them as similar as possible.

Often requires thinking of a more general name.

Often leads to new abstract superclass.

Classes with a collection of components become composites.

36

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

 Notes for OOPSLA '93

Strategy Object

A strategy is an algorithm represented as an object.

Representing an algorithm as an object means:

• easy to replace one algorithm with another
• can change dynamically
• can make a class hierarchy of algorithms
• can encapsulate private data of algorithm
• can define an algorithm in one place

37

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

Attributes as a Strategy

'Attribute' is responsible for computing the value of an

attribute of an account at a particular point in time.
Different subclasses of Attribute can compute the value in
different ways.

Representing an attribute as an object means:

• easy to change from total to MTD
• can make a class hierarchy of attributes, so it is easy
for a programmer to make a new kind of attribute
• encapsulate indices into tables of intermediate values
• eliminates tag checking, and makes Account smaller

38

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

 Notes for OOPSLA '93

Represent Common Features by Components

Each attribute of an Account:

reads a field from each transaction posted to the Account
applies a function (+) to list of values to produce a single value
if MTD or YTD then selects subset of transactions

Options:
1) Factor commonality into functions in Account, and have each function
representing an attribute call them. Attributes are then simple and
stylized, and so easy to implement.

2) Make attribute an object, which is responsible for extracting a field from

transactions, for knowing which function to apply to values it extracts,
and for knowing which transactions to extract values from.

39

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

Represent Common Features by Components

An alternative to multiple inheritance.

If some feature varies from class to class, but some classes have the
feature in common, then represent the feature as a component. Make
a class hierarchy to represent the variations in the feature.

How to carry out the refactoring:

Make a new class to represent the feature.
Add new component to existing classes.
Migrate functions and variables from existing classes to component.

40

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

 Notes for OOPSLA '93

Eliminate Case Analysis

Replace conditional tests of state with polymorphism

• eliminate flags
• encode state in class
• make a subclass for each case
• make an operation for each conditional statement
• eliminate case statements, if statements

Breaks class into smaller classes -- its subclasses.

Example:
Attribute -> MTDAttribute, YTDAttribute, TotalAttribute

41

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

Distributing Algorithm Across Objects and Subclasses

Advantages
• instead of modifying case statements, add a new subclass
• easier to parameterize
• can use inheritance to make new options

Disadvantages
• program is spread out,
+ harder to understand
+ harder to replace algorithm
• state of object can change, but class can not
This means that changing an Attribute from MTD to
YTD requires replacing it.

42

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

 Notes for OOPSLA '93

Designing Attribute Class Hierarchy

Attribute
YTDAttribute
MTDAttribute
TotalAttribute

When objects do not come directly from the problem domain, it is often
hard to design good abstract classes from first principles.

Usually best to design abstract class by generalizing from concrete

subclasses.

43

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

Finding Abstract Classes/

Generalizing Concrete Classes

Create empty superclass, move common code/variables to it.

Problem: how to make common code.

• rename functions to give classes same interface

• decompose functions to factor out differences

Usually code in subclasses is almost, but not quite, the same. Must
abstract out differences, and move the rest to superclass.

Result is that subclasses have more, but smaller, methods.

44

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

 Notes for OOPSLA '93

Decompose Functions

Factor out differences in two functions by:

• Find code sequences in two functions that are different.

• Turn each code sequence into a new function in the same class as the
function containing the code sequence.

• Replace different code sequences with calls to equivalent functions.

45

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

Move Code From Caller into Callee

Law of Demeter says don't operate on contents of another object.

Instead, move code that operates on its contents into the object.

Example
x->foo->fee(a, b) => x->fee(a, b)
Define fee function in class of x that performs fee() on
component.

Extreme case when record is converted into an object.

Rule: convert expressions that manipulate an object into operations

on the object.
This is how to find operations for Attribute.

46

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

 Notes for OOPSLA '93

Interpreter / Little Languages

Need to define one attribute in terms of other attributes:

Average = Total / Count
OnHand = Purchase - Sold - Shrinkage

Idea:
1) make a class hierarchy that represents nodes in abstract syntax tree
(/, -, +, attribute)
2) define a function value(Date) for each class
An AttributeNode knows an Account and Attribute on that Account,
and value(Date) will read the Attribute on that Account for that
date.
value(Date aDate) for a PlusNode will return the sum of the values
for aDate for its two descendents.
3) define +, -, /, etc functions in common superclass to return PlusNode,
DifferenceNode, RatioNode, etc.
47

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

Factory
What should a composite account do if it can't find a component with a
given name?
• report an error -- the transaction is invalid
Example: invoice has an illegal inventory number
• create a component account
Example: buying some stock when you've never owned it before

CompositeAccount has a ComponentFactory that can create the right kind of

component account to handle a transaction.
1) reject every transaction
2) look in large dictionary of possibilities and copy what it finds
(Example of the Prototype pattern.)
3) examine transaction and create instance of Account

Factory: object responsible for creating other objects.

48

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

 Notes for OOPSLA '93

Changing White-box to Black-box

Journal Account
Account (with subaccounts) SimpleAccount
CompositeAccount
(parameterized by its
Portfolio component Accounts and the
Account names it gives them)

Make new Account by defining Make new Account by setting its

attributes as functions in list of Attribute objects.
new Account class.

49

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

Summary of Refactoring

Many reusability bugs can be fixed by a small set of transformations.

Lower level
• moving functions and variables to components
• moving functions and variables to superclass
• breaking functions into smaller functions
• renaming functions, classes, and variables

Higher level
• finding abstract superclasses
• breaking class into components or subclasses
• reuse by inheritance to reuse by components
• eliminating case analysis

50

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

 Notes for OOPSLA '93

Summary of Patterns

There are a set of higher-level design patterns that make systems more reusable
and that are goals of refactorings.

Most design patterns rely on composition and polymorphism

• Composite
• Strategy
• Factory
• Interpreter

Some design patterns rely on inheritance

• Abstract classes with template methods

Design Patterns: Micro-Architectures for Reusable Object-Oriented Software

Erich Gamma, Richard Helms, Ralph Johnson, John Vlissides, in mid 1994.
51

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

Grand Summary

Developing reusable software is hard.

Reusable software developed iteratively

• generalize from concrete examples

• look for design patterns

• refactor to increase reusability

52

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

View publication stats