week 2 design examples and designing for change

55
Week 2 Design Examples and Designing for Change Alex Baker

Upload: tim

Post on 25-Feb-2016

36 views

Category:

Documents


3 download

DESCRIPTION

Week 2 Design Examples and Designing 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 - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Week 2 Design Examples and Designing for Change

Week 2Design Examples andDesigning for Change

Alex Baker

Page 2: Week 2 Design Examples and Designing for Change

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, …

Page 3: Week 2 Design Examples and Designing for Change

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, …

Page 4: Week 2 Design Examples and Designing for Change

Emphasis: Changability

Reusable Extensible Maintainable Portable Well-Documented Adaptable

Simplicity Readability Minimalistic Elegant Well-Organized Concise

Efficiency Powerful

Page 5: Week 2 Design Examples and Designing for Change

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

Page 6: Week 2 Design Examples and Designing for Change

Information Hiding Made Very Simple

A List class with:1) getArray() : Array2) getElementAt(int i) : Element

Page 7: Week 2 Design Examples and Designing for Change

Information Hiding Made Very Simple

A List class with:1) getArray() : Array2) getElementAt(int i) : Element

Its too slow, so we switch to a hash table1) Everywhere you call getArray needs changing2) Only List is changed

Little things like this add up

Page 8: Week 2 Design Examples and Designing for Change

The Ideal Program

vs.

Page 9: Week 2 Design Examples and Designing for Change

Why the Emphasis on Changability?

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

Page 10: Week 2 Design Examples and Designing for Change

Why is there so Much Change?

Designs

Outcomes

Page 11: Week 2 Design Examples and Designing for Change

Why is there so Much Change?

Designs

Outcomes

Engineering

PhysicsPrinciplesExisting Examples

Page 12: Week 2 Design Examples and Designing for Change

Why is there so Much Change?

Designs

Outcomes

Software Engineering

PhysicsPrinciplesExisting Examples

Page 13: Week 2 Design Examples and Designing for Change

Why is there so Much Change?

Designs

Outcomes

Software Engineering

PhysicsPrinciplesExisting Examples

Page 14: Week 2 Design Examples and Designing for Change

Why is there so Much Change?

Designs

Outcomes

Software Engineering

PhysicsPrinciplesExisting Examples

Page 15: Week 2 Design Examples and Designing for Change

Why the Emphasis on Changability?

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

You usually just don’t know for sure…

Page 16: Week 2 Design Examples and Designing for Change

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?

Page 17: Week 2 Design Examples and Designing for Change

Changes during Use

Potential breakdowns at several levels

– Customers have needs

– Customers make requests

– Developers provide software

Page 18: Week 2 Design Examples and Designing for Change

Reuse

A changing of context

Page 19: Week 2 Design Examples and Designing for Change

Change Happens

Let’s design for it

Page 20: Week 2 Design Examples and Designing for Change

Our Approach

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

Some overarching lessons

Build up an intuition

Page 21: Week 2 Design Examples and Designing for Change

UML Review: Class Diagrams

Class NameAttribute : Type

Operation (parameter) : Return Type

Attribute : Type

Operation (parameter) : Return Type

Operation (parameter) : Return Type

Page 22: Week 2 Design Examples and Designing for Change

UML Review: Class Diagrams

Association

Aggregation

Generalization

Composition

Page 23: Week 2 Design Examples and Designing for Change

A Class Diagram

Page 24: Week 2 Design Examples and Designing for Change

Example #1: Theseus and the Minotaur

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

Page 25: Week 2 Design Examples and Designing for Change

Original Theseus Design

Page 26: Week 2 Design Examples and Designing for Change

Original Theseus Design

What if we want to add “Water” ?

Page 27: Week 2 Design Examples and Designing for Change

Original Theseus Design

What if we want to add “Water” ?

?

Page 28: Week 2 Design Examples and Designing for Change

Original Theseus Design

?

What if we want to add “Water” ?

How do we fix this?

Page 29: Week 2 Design Examples and Designing for Change

TntM: Changes

Changing the board size

Adding terrain types

Adding more monsters

Adding a second player

“Intelligent elements”

Page 30: Week 2 Design Examples and Designing for Change

TntM 2

Page 31: Week 2 Design Examples and Designing for Change

TntM 2: Object Interfaces & Inheritance

Page 32: Week 2 Design Examples and Designing for Change

TntM: Changes

Changing the board size

Adding terrain types

Adding more monsters

Adding a second player

“Intelligent elements”

Page 33: Week 2 Design Examples and Designing for Change

How far is too far?

Changing board size?

Pushable blocks?

Intelligent elements?

Real time gameplay?

Physics challenges?

Page 34: Week 2 Design Examples and Designing for Change

TntM 2

Page 35: Week 2 Design Examples and Designing for Change

Bonus!

StompOn( stompee )

Or

StompedOn( stomper )

Page 36: Week 2 Design Examples and Designing for Change

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?

Page 37: Week 2 Design Examples and Designing for Change

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

Page 38: Week 2 Design Examples and Designing for Change

A Good Klax Design?

Page 39: Week 2 Design Examples and Designing for Change

Chiron 2 Architectural Style

Page 40: Week 2 Design Examples and Designing for Change

C2 Klax

Page 41: Week 2 Design Examples and Designing for Change

Spelling Klax?

Page 42: Week 2 Design Examples and Designing for Change

Spelling Klax?

Page 43: Week 2 Design Examples and Designing for Change

Example #3: Scrabble

Page 44: Week 2 Design Examples and Designing for Change

Function Overload

Changes to rack

Page 45: Week 2 Design Examples and Designing for Change

Class Overload

Page 46: Week 2 Design Examples and Designing for Change

(besides missing details)

Page 47: Week 2 Design Examples and Designing for Change

Is this a good design?

Page 48: Week 2 Design Examples and Designing for Change

Overengineered?

What change are you designing for?

Multiple point values for a given tile type?

More types of board objects?

Page 49: Week 2 Design Examples and Designing for Change

Overengineered?

Meanwhile:

Board doesn’t actually work

Populating the tiles is likely a hassle

Tilepool vs. Player.currentTiles

Inelegance lead to problems

Page 50: Week 2 Design Examples and Designing for Change

A Nice Approach?

Page 51: Week 2 Design Examples and Designing for Change

A Nice Approach?

Page 52: Week 2 Design Examples and Designing for Change

Scrabble

Can a design accommodate:

– Changes to letter values?

– Changes to bonus squares?

– AI opponents?

– Different dictionaries?

Page 53: Week 2 Design Examples and Designing for Change

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”?

Page 54: Week 2 Design Examples and Designing for Change

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

Page 55: Week 2 Design Examples and Designing for Change

Assignment #1 Continued

[]