week 2 design examples and designing for change alex baker

55
Week 2 Design Examples and Designing for Change Alex Baker

Post on 19-Dec-2015

214 views

Category:

Documents


1 download

TRANSCRIPT

Week 2Design Examples andDesigning for Change

Alex Baker

Implementation Design

An implementation design is a road map– understandable, unambiguous, consistent, helpful, …

An implementation design describes a path from system design to the outcome

– correct, complete, concise, verifiable, effective, …

An implementation design describes what the implementers should do

– elegant, partitionable, recomposable, resilient, …

An implementation design is a guide towards future change

– evolvable, …

Emphasis: Changability

Subtle

Requires foresight and careful balancing

An implementation design describes what the implementers should do

– elegant, partitionable, recomposable, resilient, …

An implementation design is a guide towards future change

– evolvable, …

Emphasis: Changability

Reusable Extensible Maintainable Portable Well-Documented Adaptable

Simplicity Readability Minimalistic Elegant Well-Organized Concise

Efficiency Powerful

Changability: Basic Principles

Low Coupling: Reducing interdependency– Changes don’t propagate– Reuse is facilitated

High Cohesion: Grouping functionality– Easier to find things– Metaphor guides decisions

Information Hiding

Information Hiding Made Very Simple

A List class with:1) getArray() : Array

2) getElementAt(int i) : Element

Information Hiding Made Very Simple

A List class with:1) getArray() : Array

2) getElementAt(int i) : Element

Its too slow, so we switch to a hash table1) Everywhere you call getArray needs changing

2) Only List is changed

Little things like this add up

The Ideal Program

vs.

Why the Emphasis on Changability?

Change abounds…– During coding– After use– Reuse for later projects

Why is there so Much Change?

Designs

Outcomes

Why is there so Much Change?

Designs

Outcomes

Engineering

PhysicsPrinciplesExisting Examples

Why is there so Much Change?

Designs

Outcomes

Software Engineering

PhysicsPrinciplesExisting Examples

Why is there so Much Change?

Designs

Outcomes

Software Engineering

PhysicsPrinciplesExisting Examples

Why is there so Much Change?

Designs

Outcomes

Software Engineering

PhysicsPrinciplesExisting Examples

Why the Emphasis on Changability?

Change abounds…– During coding– After use– Reuse for later projects

You usually just don’t know for sure…

Changes During Coding

Refinement of the high level design

Dependencies reveal themselves– Oh, I need to know [X].– I can’t access that data?

‘It turns out this class is HUGE’

Need to redesign as you go Can changes be made within the design?

Changes during Use

Potential breakdowns at several levels

– Customers have needs

– Customers make requests

– Developers provide software

Reuse

A changing of context

Change Happens

Let’s design for it

Our Approach

Lots of examples (3 problems, many solutions, today)

Some overarching lessons

Build up an intuition

UML Review: Class Diagrams

Class Name

Attribute : Type

Operation (parameter) : Return Type

Attribute : Type

Operation (parameter) : Return Type

Operation (parameter) : Return Type

UML Review: Class Diagrams

Association

Aggregation

Generalization

Composition

A Class Diagram

Example #1: Theseus and the Minotaur

http://www.logicmazes.com/theseus.html

Original Theseus Design

Original Theseus Design

What if we want to add “Water” ?

Original Theseus Design

What if we want to add “Water” ?

?

Original Theseus Design

?

What if we want to add “Water” ?

How do we fix this?

TntM: Changes

Changing the board size

Adding terrain types

Adding more monsters

Adding a second player

“Intelligent elements”

TntM 2

TntM 2: Object Interfaces & Inheritance

TntM: Changes

Changing the board size

Adding terrain types

Adding more monsters

Adding a second player

“Intelligent elements”

How far is too far?

Changing board size?

Pushable blocks?

Intelligent elements?

Real time gameplay?

Physics challenges?

TntM 2

Bonus!

StompOn( stompee )

Or

StompedOn( stomper )

Aside: Three Degrees of Support

Is it a good solution?

Can they build that solution?

Can that solution be used to make other good solutions?

Example #2 Klax

Blocks fall from above, use a paddle to catch Deposit blocks in one of 5 columns Try to make lines of 3 in a row or more

http://www.123games.dk/game/puzzle/klax3d/klax_eng.php

A Good Klax Design?

Chiron 2 Architectural Style

C2 Klax

Spelling Klax?

Spelling Klax?

Example #3: Scrabble

Function Overload

Changes to rack

Class Overload

(besides missing details)

Is this a good design?

Overengineered?

What change are you designing for?

Multiple point values for a given tile type?

More types of board objects?

Overengineered?

Meanwhile:

Board doesn’t actually work

Populating the tiles is likely a hassle

Tilepool vs. Player.currentTiles

Inelegance lead to problems

A Nice Approach?

A Nice Approach?

Scrabble

Can a design accommodate:

– Changes to letter values?

– Changes to bonus squares?

– AI opponents?

– Different dictionaries?

Summary

Designing for change is a matter of:– Controlling dependency– Proper encapsulation– Generalizing where you can

Which changes?– What are the biggest change risks?– What kind of program is this, essentially?– Where is “the line”?

Practically:

What is the core we know will be true?– What variations on that will we see?

If there’s something that needs to change:– Can it be changed in one place?– Does anything else need to be changed when it changes?

Can each class ignore its context?

Discipline

Assignment #1 Continued

[]