Design. Practices Principles Patterns What are the characteristics of good design? What are good...

Post on 08-Jan-2018

216 views 0 download

description

design a la cs121 noun: a predictive model that captures the essential properties of a thing verb: the practice of “creating” a design to solve some problem LAST TIME

Transcript of Design. Practices Principles Patterns What are the characteristics of good design? What are good...

Design

Design

• Practices• Principles• Patterns

What are the characteristics of good design?

What are good solutions to common design problems?

How do we go about design and what do we produce?

LAST TIME

design a la cs121

• noun: a predictive model that captures the essential properties of a thing

• verb: the practice of “creating” a design to solve some problem

LAST TIME

Forms of models

• Text (hyperlinked)• Prototypes • Mathematical models• Diagrams, charts, graphs

LAST TIME

Design

• Practices• Principles• Patterns

What are the characteristics of good design?

What are good solutions to common design problems?

How do we go about design and what do we produce?

TODAY:Software design

Goals

1. Make it easy to build2. Make it easy to test3. Make it easy to maintain4. Make it easy to change

INTUITIVE FLEXIBLE

Desirable Characteristics of a DesignDesign Grading

• Minimal Complexity – Brooks would argue that complexity is what you need to manage.

• Ease of maintenance• Loose Coupling – hold connections to different parts of

program to a minimum• Extensibility – extend without destroying underlying structure• Reusability – reuse in other systems• High fan-in – high number of classes using this class• Low fan-out – each class should use a low to medium number

of other classes.

Desirable Characteristics of a DesignDesign Grading, cont

• Portability• Leanness – designing so there are no extra parts• Stratification – try to keep levels of decomposition such that

you can view the system at any level and get a constant view• Standard Techniques – do not rely on exotic pieces, or

approaches

Tic Tac Toe

1. As a team go to a board and do a Domain Model/Top Level Design of Tic Tac Toe

2. From that model, decide on your objects/classes.

Design Principles

• Heuristics to create design that has the desired characteristics...

• If we do these, the project will be perfect, and satisfy all the desired Design Characteristics...not really, just has a better chance of success

• Look at ‘most important’ for our project

Design principle

Use real world objectsINTUITIVE

Domain model

Design model

Name 8 or less of the most important “real world” objects in your tic tac toe game.Do your design objects match these?

Real-World Objects

• Start with real-world, build your objects– attributes of that object– operations on that object– operations by that object to other objects– visible object parts– object’s interfaces

Doesn’t look easy, does it?

Design principle

Single responsibility principleevery class/object should have a single responsibility

INTUITIVE (easy to understand)

Can you sum up in one simple sentence the responsibility of each of your tic tac toe classes? – Do so...

Single Responsibility

• Drilled into you via functions in 70 and elsewhere, issue of side effects, etc.

• Carries over to objects, need more than a single game object which does all things.

Design principle

Encapsulate changeeach class should have at most one reason to change,

i.e, should not change because some other class changed

FLEXIBLE What changes in your game?What can you envision changing later?A change in one object should not require changes to n otherobjects

Encapsulation• "the process of compartmentalizing the elements of an

abstraction that constitute its structure and behavior; encapsulation serves to separate the contractual interface of an abstraction and its implementation.”

• The purpose is to achieve potential for change:– the internal mechanisms of the component can be improved without

impact on other components, – the component can be replaced with a different one that supports the

same public interface

Design principle

High cohesionHigh cohesionLow couplingLow coupling

INTUITIVE

FLEXIBLEseparates data, operations, and visualizationillustrates low coupling and high cohesion

Coupling and Cohesion• Coupling is a qualitative measure of the degree to which

classes are connected to one another.– 30 public methods is high coupling

• Cohesion is the “single-mindedness” of a component. Implies that a component or class encapsulates only attributes and operations that are closely related to one another or to the class itself – a focused class, strongly related functionality

Design principle

Open-closed principleclasses should be open to extension but closed to modification

architecture of your game

Open-closed Principle

• want to create a collection of classes so that we can extend the system adding new functionality, without modifying a large number of existing classes

• important in Agile, one aspect of refactoring is to mitigate such modification

HELLO WORLD!HELLO WORLD!

HELLO WORLD!HELLO WORLD!

HELLO WORLD!

Design principle

Don’t repeat yourselfdata/code should occur once and only once

Design principle

Law of Demeteronly talk to your friends

Principle of Least Knowledge

Law of Demeter

• object A can request a service (call a method) of an object instance B, but object A cannot "reach through" object B to access yet another object, C, to request its services

• the LoD is a specific case of loose coupling

crapal chapel

myGame->theBoard->cells[0][0].update()

Summary

• Use real world objects• Single responsibility principle• Encapsulate change• High cohesion/low coupling• Open-closed principle• Don`t repeat yourself (D.R.Y)• Law of demeter (talk only to your friends)