Dependence Management

Bob Martin says “Object-oriented programming is dependence management.”

See his “Design Principles and Design Patterns” at

http://www.objectmentor.com/resources/articles/Principles_and_Patterns.PDF

Dependence

How can one package depend on another? Reuse a class

• By inheritance

• By instantiation (direct reference) Reuse a variable Reuse a method?

Dependence

If package A depends on package B then you can’t run the tests for A unless you also have B.

“A depends on B” means you can’t use A unless you have B.

“Package A depends on package B” means that something in A depends on something in B.

Cycles of dependence

If package A depends on package B then package B should NOT depend on package A.

If classes C and D both depend on each other, put them in the same package.

Eliminating dependence

The Observer pattern eliminates dependence.

Suppose that “FBIAgent” is an observer of Mobster. Mobster is a subclass of Model, so it can have observers. Class FBIAgent probably depends on class Mobster, but Mobster does not depend on FBIAgent.

Observer Pattern

ObserverObserver

update:update:

SubjectSubject

addDependent: addDependent: removeDependent: removeDependent: changed:changed:

MobsterMobsterrobBankrobBankdriveCardriveCar

FBIAgentFBIAgent

update:update:

observer/observer/dependentdependent

modelmodel

*

Smalltalk base library

GUI library Application

Application GUI SUnit tests

Abstract Server

Bob Martin’s name for “depend on an interface, not on a concrete class”.

Interface

ClientServer

Creation scriptConsumer <<interface>>

ResourceManager

ResrcMgr1

AdapterIntent: Convert the interface of a class into another interface

clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces.

AdapteeAdapterTarget

Adapter

Target

Request()

Client

AdapterRequest()

Adaptee

Adapter

Allows client and adaptee to be unchanged

Adapter is usually ugly

Client Adaptee

Adapter

Mediator

Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.

Example: Insurance policies must be approved before they are issued. There is a procedure (which can change over time, and which is different for different kinds of policies) for approving a policy. This procedure must interact with work queues of managers and with the history that is kept on the customer. Instead of putting this procedure in the insurance policy, put it in a separate object that is easy to change. (This is a “business process”)

Not Mediator

CustomerHistory

InsurancePolicy

Worker

Mediator

Procedure

CustomerHistory

InsurancePolicy

Worker

Mediator

Colleagues

If interaction is main thing that changes, then make the interaction be an object.

Colleague classes become more reusable.

Mediator is the non-reusable part.

Mediator

Procedure

CustomerHistory InsurancePolicy Worker

Business Rule

Domain Objects

Mediator

Colleagues

Application Model

Mediator between widgets and domain model.

PayrollSystemInterface

ListView TextView EmployeePayrollSystem

Façade

Provide a unified interface to a set of interfaces in a subsystem. Define a higher-level interface that makes the subsystem easier to use.

Facade

The Compiler

Scanner

Return Expression

SmalltalkExpression

Compilercompileevaluate

CompiledMethod

AssignmentExpression

Message Expression

...

Parser

Creational Patterns

Factory Method

Factory Object

Abstract Factory

Builder

Prototype

Singleton

Factory MethodDon't (call constructor / send message to class)

directly.

Make a separate function / method to create object.

How to do it: Find every class name in “producer” Extract it (or perhaps “CN new”) into a

method

Factory Method

Results: Localizes dependencies Modules become less coupled Reduces coupling Can lead to parallel class hierarchies

Factory Method

Producer

doSomething

ConcreteProducer

createXXcreateXX

^XX new

doSomething …self createXX...

XX

Factory Object

Problem with factory method -- have to create subclass to parameterize.

Often end up with parallel class hierarchies.

Example: subclass of Tool for each figure you want to create

Alternative: parameterize CreationTool with object that creates figure

Smalltalk automatically creates a factory for every class, the Class!

(Note: Factory Object is generalization of Abstract Factory,Builder, and Prototype. It is not in the book.)

Applicability

Use factory objects:

when system creates them automatically

when more than one class needs to have product specified

when most subclasses only specialize to override factory method

FigureFactory new

LineFigureFactory

ElipseFigureFactory

RectangleFigureFactory

Figure

LineFigure ElipseFigure RectangleFigure

Prototype

Making a class hierarchy of factories seems wasteful.

The parameters of an object can be as important as its class.

Solution:

Use any object as a factory by copying it to make a new instance.

Advantages

Don't need new factory hierarchy.

Can make new "class" by parameterizing an object

Disadvantages

Requires robust copying

Making Prototype

You have a design in which objects are parameterized by passing in classes. You are making new classes just for their constructors, or you want to make “composite classes”.

Make sure “copy” works. Define “new” as an instance method that returns a copy. Change client to pass in instances instead of classes.

Abstract Factory

Sometimes a group of products are related -- if you change one, you might need to change them all.

Solution:

Make a single object that can make any of the products.

ScrollBar

MotifScrollBar PMScrollBar

WidgitFactoryCreateScrollBarCreateWindow

MotifWidgetFactoryCreateScrollBarCreateWindow

PMWidgetFactoryCreateScrollBarCreateWindow

Making Abstract Factory

Give Producer a component called “Factory” Create class Factory Add instance variable “factory” to Producer Change constructor to have line

factory:=Factory newMove factory methods to Factory

Copy factory method to Factory Change sends of createFoo to “factory

createFoo”

Builder

Complex objects require a lot of work to make.

Solution:

Factory must keep track of partly built product.

Client specifies product by performing series of operations on factory.

Client

WindowBuilderAddScrollBarAddButtonGetWindow

Implementing Builder

WidgitFactoryCreateScrollBarCreateWindow

WindowBuilderAddScrollBarAddButtonGetWindow

PMWidgetFactoryCreateScrollBarCreateWindow

MotifWidgetFactoryCreateScrollBarCreateWindow

Builder can make components using

Factory Method

Abstract Factory, or

Prototype

Making BuilderThere are several places in your system where a

complex object is built. These places need to mention a lot of classes, unless you use a pattern like Abstract Factory.

Constructors get complicated. Perhaps there are a lot of class methods that deal with construction. Construction needs temporary variables.

Make a class that builds the object for you. It hides the concrete classes that are used and temporary variables used during construction.

Result: Producers not coupled with Product. Builder is coupled with Product.

Summary of Factory Patterns

Factory method -- use in simple cases so that you can change product

Abstract factory -- use when there is a set of related products

Builder -- use when product is complex

Prototype -- use when Factory Method is awkward and when classes are not objects, or when you want to specify new "classes" by composition

Singleton

What if you want to make sure that a class has only one instance?

One possibility is global variables. Another is using class methods.

Best solution: store single instance in class variable.

Singleton

The singleton class has a class variable “Instance” and a class method

instance

Instance isNil ifTrue: [Instance := super new].

^Instance

Alternative: make “Instance” a class instance variable.

Managing dependences

Cost of eliminating dependences More abstract Harder to test Harder to understand

It is OK to depend on stable packages.

Stable = doesn’t change = has many dependents

Managing dependences

Subsystem2

Application

Library3

Library1

Library2

Subsystem1

Managing dependences

Application2

Subsystem2

Subsystem1

Application1

Suppose Application2 depends on only a small part of Subsystem1, and that part doesn’t depend on Subsystem2

Managing dependences

Application2

Subsystem2Subsystem3

Application1

Subsystem1

Dependence management

Determines Build times Difficulty of testing Frequency of rebuilding and retesting Ease of reuse

Design patterns help control dependences

Design patterns and refactoring

Patterns are most useful for complex systems.

Add them later by refactoring Keep system simple – no unnecessary

patterns Keep system flexible – all needed

patterns

Next time

More on Observer and creational patterns.