Why Design?

To make our applications conducive to change

Without changes Design would not matter

But change is real.

• Changing requirements

• Feature requests

• On-going improvements

• Bug fixes

Why is software

change hard?

Cascading difficulty

• Object systems know too much about each other

  • Changes in one object forces change in another

    • in turn forces change in it’s collaborators

      • Objects expect a tightly knit, arranged world

        • They resist being used in different contexts

          • They are painful to test

            • Duplication then appears to be an

              escape hatch in the face of inflexibility

Object-Oriented Design

• Techniques to manage dependencies

• The art of organizing and arranging code

• Does not predict the future; it preserves your options for accommodating the future

Do One Thing!

Brief intro to Object-Oriented Programming

• Objects have behavior, and may contain data.

• Objects control access to their data.

• Objects invoke each others behavior by passing messages

Messages

• The foundation of OOD

• Define the interactions between objects

Classes

• Most visible structures of OOP

• When you make a class, you are making the box it will eventually be hard to think outside of

• Define a framework and language we use to reason about our code forever

classes ------> messages

 things ------> interactions

We begin with class design

Over time shifting our emphasis from:

Simple to change

• No unexpected side-effects

• Existing code is simple to reuse

• The easiest way to make a change, is to add code that is itself simple to change.

Code Qualites for Change

• T ransparent: There are obvious consequences of change, in code that changes and code that relies on it.

• R easonable: The cost of changing code is proportional to the benefit the change achieves.

• U sable: Existing code can be reused in new and unexpected contexts.

• E xemplary: The code itself should encourage those who change it to perpetuate these qualities.

A class should do the smallest possible useful thing.

Example:

Bicycles and Gears

Interrogate you Classes

• Please Mr. Gear, what is your ratio? (makes sense)

• Please Mr. Gear, what are your gear inches? (a little shaky, depends on wheel, tires)

• Please Mr. Gear, what is your tire size? (nonsense)

• Please Mr. Gear, what is your wheel size? (nonsense)

The smallest useful thing

Reusable classes are pluggable units of well-defined behavior that have few entanglements.

Hard to reuse classes have many entanglements.

You increase your applications chance of breaking unexpectedly if you depend on classes that do too much.

Limit the number of

purposes a class has

... to ONE!

Depend on behavior, not data

If being attached to an instance variable is bad, depending on a complicated data structure is worse.

Extract responsibilities from methods