Top Banner
Week 2 Design Examples and Designing for Change Alex Baker
55

Week 2 Design Examples and Designing for Change Alex Baker.

Dec 19, 2015

Download

Documents

Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: Week 2 Design Examples and Designing for Change Alex Baker.

Week 2Design Examples andDesigning for Change

Alex Baker

Page 2: 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

– 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 Alex Baker.

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 Alex Baker.

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 Alex Baker.

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 Alex Baker.

Information Hiding Made Very Simple

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

2) getElementAt(int i) : Element

Page 7: Week 2 Design Examples and Designing for Change Alex Baker.

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

Page 8: Week 2 Design Examples and Designing for Change Alex Baker.

The Ideal Program

vs.

Page 9: Week 2 Design Examples and Designing for Change Alex Baker.

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 Alex Baker.

Why is there so Much Change?

Designs

Outcomes

Page 11: Week 2 Design Examples and Designing for Change Alex Baker.

Why is there so Much Change?

Designs

Outcomes

Engineering

PhysicsPrinciplesExisting Examples

Page 12: Week 2 Design Examples and Designing for Change Alex Baker.

Why is there so Much Change?

Designs

Outcomes

Software Engineering

PhysicsPrinciplesExisting Examples

Page 13: Week 2 Design Examples and Designing for Change Alex Baker.

Why is there so Much Change?

Designs

Outcomes

Software Engineering

PhysicsPrinciplesExisting Examples

Page 14: Week 2 Design Examples and Designing for Change Alex Baker.

Why is there so Much Change?

Designs

Outcomes

Software Engineering

PhysicsPrinciplesExisting Examples

Page 15: Week 2 Design Examples and Designing for Change Alex Baker.

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 Alex Baker.

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 Alex Baker.

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 Alex Baker.

Reuse

A changing of context

Page 19: Week 2 Design Examples and Designing for Change Alex Baker.

Change Happens

Let’s design for it

Page 20: Week 2 Design Examples and Designing for Change Alex Baker.

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 Alex Baker.

UML Review: Class Diagrams

Class Name

Attribute : 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 Alex Baker.

UML Review: Class Diagrams

Association

Aggregation

Generalization

Composition

Page 23: Week 2 Design Examples and Designing for Change Alex Baker.

A Class Diagram

Page 24: Week 2 Design Examples and Designing for Change Alex Baker.

Example #1: Theseus and the Minotaur

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

Page 25: Week 2 Design Examples and Designing for Change Alex Baker.

Original Theseus Design

Page 26: Week 2 Design Examples and Designing for Change Alex Baker.

Original Theseus Design

What if we want to add “Water” ?

Page 27: Week 2 Design Examples and Designing for Change Alex Baker.

Original Theseus Design

What if we want to add “Water” ?

?

Page 28: Week 2 Design Examples and Designing for Change Alex Baker.

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 Alex Baker.

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 Alex Baker.

TntM 2

Page 31: Week 2 Design Examples and Designing for Change Alex Baker.

TntM 2: Object Interfaces & Inheritance

Page 32: Week 2 Design Examples and Designing for Change Alex Baker.

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 Alex Baker.

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 Alex Baker.

TntM 2

Page 35: Week 2 Design Examples and Designing for Change Alex Baker.

Bonus!

StompOn( stompee )

Or

StompedOn( stomper )

Page 36: Week 2 Design Examples and Designing for Change Alex Baker.

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 Alex Baker.

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 Alex Baker.

A Good Klax Design?

Page 39: Week 2 Design Examples and Designing for Change Alex Baker.

Chiron 2 Architectural Style

Page 40: Week 2 Design Examples and Designing for Change Alex Baker.

C2 Klax

Page 41: Week 2 Design Examples and Designing for Change Alex Baker.

Spelling Klax?

Page 42: Week 2 Design Examples and Designing for Change Alex Baker.

Spelling Klax?

Page 43: Week 2 Design Examples and Designing for Change Alex Baker.

Example #3: Scrabble

Page 44: Week 2 Design Examples and Designing for Change Alex Baker.

Function Overload

Changes to rack

Page 45: Week 2 Design Examples and Designing for Change Alex Baker.

Class Overload

Page 46: Week 2 Design Examples and Designing for Change Alex Baker.

(besides missing details)

Page 47: Week 2 Design Examples and Designing for Change Alex Baker.

Is this a good design?

Page 48: Week 2 Design Examples and Designing for Change Alex Baker.

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 Alex Baker.

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 Alex Baker.

A Nice Approach?

Page 51: Week 2 Design Examples and Designing for Change Alex Baker.

A Nice Approach?

Page 52: Week 2 Design Examples and Designing for Change Alex Baker.

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 Alex Baker.

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 Alex Baker.

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 Alex Baker.

Assignment #1 Continued

[]