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 build 2.Make it easy to test 3.Make it easy to maintain 4.Make it easy to change INTUITIVEFLEXIBLE

Desirable Characteristics of a Design Design 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 Design Design 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 objects INTUITIVE 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 principle every 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 change each 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 other objects

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 cohesion Low coupling INTUITIVE FLEXIBLE separates data, operations, and visualization illustrates 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 principle classes 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!

Design principle Don’t repeat yourself data/code should occur once and only once

Design principle Law of Demeter only 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)