AN INTRODUCTION

TO DESIGNOr how to work smarter when

building solutions

REVIEW SESSION 2:30 – 3:30 Mondays – focus on problem

solving (with some terminology thrown in upon occasion)

All are welcome although those that were struggling with 139 and now 239 are particularly encouraged to attend

Review tab in Blackboard will contain assignments and schedule for the sessions (up this afternoon)

OUTLINE FOR TODAY Review from lab

Design

REVIEW FROM LAB What did you learn?

What is still fuzzy?

Which command characters signal EOF?UnixDOS

DESIGN Goals

To maximize programmer efficiencyBy

Promoting reuse Breaking a problem down into a series of small

componentsEasy to understandEasy to repair if components are independent

Spending time up front on designRework costs more money than writing it right

the first time

WHY DESIGN? There is no one “right” way to write

code.

There are better designs and poorer designs.

Examine alternatives before proceeding.

SOME DESIGN PRINCIPLES Designs should be modular

Design should follow local standards

Design should look for simplicity

Designs can/should be elegant

Designs should be generalizable to the extent possible

MODULAR Humans can only comprehend so much Localizing code where each “module”

does only one thing makes it easier to write and to maintain

Such design enables teams to break solutions down into pieces that each can do

Promotes reuse – a small solution may be able to be used in many other solutions. A large complex solution must often stand alone.

STANDARDS Help us to understand. Think of language. Our language gives

us a common set of terms with which we can communicate.

Coding standards do the same. Not following standards can lead to your

code not being reused or maintained.

SIMPLE Why write 5 lines of code when one will do?

But avoid cramming 5 different statements into one.

It is simpler to use a library routine than to build one on your own.

Simple code is more easily understood.

Simple code is more likely to be reused.

ELEGANCE There is beautiful code.

Elegant code is studied and is more likely to be reused.

Elegant code is clearly understood.

GENERALIZATION You can write a solution for individual cases

OR

You can find out what those cases have in common and write a solution that will work for all of them

Look for ways to generalize what you are doing ... if the exceptions overwhelm the rule, change the rule.

OBJECT ORIENTED DESIGN Encapsulation – Combining into a well

designed unit data and methods pertaining to an “actor” in a solution.

Requires thinking not about the task to be done, but about the different data to be manipulated.

Divides a problem up into “actors” and the “actions” that those actors take.

CLASSES Should be isolation – information detail

should be hidden from other classes

Methods that are public should provide well known ways of interacting with those objects.

By encapsulation and hiding the details, we can make appropriate changes to the class without affecting the programs that use the class.

CLASSES – EXAMPLES OF PRIVACY Class and instance data – only provide public

access to values that will serve users of the class.

Helper methods – any method that is designed to help other methods of the class and that are not intended for public use should be private

A method should hide how it is accomplishing its task. Documentation should include what we expect to come in (input) and what will be produced (output) and any side effects (exceptions, mutation of data). That is all!

COHESION AND COUPLING Cohesion – The degree to which parts of a

module are related to one another.

In designing good modules you want a high level of cohesion.

Separate input, input validation, calculations and output.

Modules should relate to “real world” as most applications are simulating some real process.

COUPLING The degree to which modules require one

another

We want to reduce the degree of coupling in designing modules.

Modules that access one another’s public data have a high degree of coupling.

Privatizing data and strengthening the use of method interfaces reduces coupling.

OBJECTS Classes are the definition of the

characteristics of some set of objects

An object is one member of the set.

Classes encapsulate data and operations on that data.

Objects know themselves and can answer questions about themselves through methods.

Objects (through the classes that define them) know their own “rules”.

LET’S LOOK AT AN EXAMPLE BaseStat.java