7-1William Barrett, San Jose State University, 2009

Classes and Objects –Robby the Robot

Robby can make machine screws (among other things)– material (steel, brass, plastic)– thread size– length– diameter– type of head (Philips, flathead)

7-2William Barrett, San Jose State University, 2009

Metro-Goldwyn-Mayer, 1956, see http://en.wikipedia.org/wiki/Forbidden_Planet

7-3William Barrett, San Jose State University, 2009

Robby the Robot

PROCEDURAL

function calls must spell out details:– acquire stock– mount in lathe head– cut screw– cut off– send to head press

7-4William Barrett, San Jose State University, 2009

Robby the Robot

OBJECT ORIENTED– tell Robby the material (steel default?)– tell Robby the thread size (6-32 default?)– tell Robby the diameter, length– tell Robby the head style (Philips default?)– tell Robby to make N screws

These are order independentYou don't have to tell Robby how to make screwsRobby can be improved as technology changesDefaults cover the common cases

7-5William Barrett, San Jose State University, 2009

A Real Robbie – almost!

See the RepRap home page for an affordable machine that can generate almost any part in plastic or metal, from a software description of the part:

http://www.reprap.org

• This has several videos showing the machine at work.

7-6William Barrett, San Jose State University, 2009

Why Classes and Objects?

• A well-designed object behaves more like an intelligent actor –– Knows how to initialize oneself– Has default actions, in absence of special instructions– Can accept variations on actions, usually in any order– Carries out operations in response to signals.– Can draw upon other classes and objects for more

specialized activities.– Knows how to close oneself down.

7-7William Barrett, San Jose State University, 2009

7.20 Object-Oriented Analysis

• Object-Oriented Analysis: that phase of program development when the program functionality is determined from the requirements

• It includes

– identification of objects and classes

– definition of each class's attributes

– identification of each class's behaviors

– definition of the relationship between classes

7-8William Barrett, San Jose State University, 2009

Identify Objects and Classes

• Consider the major data elements and the operations on these elements

• Candidates include

– user-interface components (menus, text boxes, etc.)

– I/O devices

– physical objects

– historical data (employee records, transaction logs, etc.)

– the roles of human participants

7-9William Barrett, San Jose State University, 2009

Define Class Attributes and Behaviors

For each class,

– determine the data elements needed by an object of that class

– Determine the behaviors or activities that the class must perform

7-10William Barrett, San Jose State University, 2009

Relationships Between Classes

Possible relationships

– Access ("uses-a")

• A member function creates and uses an object of another class

– Ownership/Composition ("has-a")

• This class contains a declaration of another class.

– Inheritance ("is-a")

• This class inherits another class (section 11.10)

7-11William Barrett, San Jose State University, 2009

WHY CLASSES?

A naive programmer will complain that C++ and its class organization are "too complicated for practical use”.

How should one respond to that?CONSIDER a LARGE software project with

many programmers, trying to write their code independently.

• Most of the group only need to use or review code written by others.

7-12William Barrett, San Jose State University, 2009

SOURCE CODE POOL

Frank

Al

J. P. Bigboss

Sally

7-13William Barrett, San Jose State University, 2009

Why the Complexity

Problems can arise immediately– Coders will "step on each other's toes"

• any function could be changed by anyone• functions also carry module interface information• a function change will likely cripple someone else's work

– Two or more coders may try to change a file at the same time, with disastrous results

– Bugs arise and appear in all sorts of places– Impossible to assign responsibility for code changes,

since anyone can change anything at any time

7-14William Barrett, San Jose State University, 2009

The Discipline

• Break down the project into small, independent modules, e.g. class definitions.

• Files are managed by a source code control system (SCCS), which– keeps track of ALL source code changes– keeps track of WHO did WHAT to the code WHEN– prevents two separate coders from working on the

same file at the same time– manages access rights

• ECLIPSE is a popular modern SCCS

7-15William Barrett, San Jose State University, 2009

Source Code

Control System

Frank

Al

J. P. Bigboss

Sally

Source

Code

Pool

7-16William Barrett, San Jose State University, 2009

Class Designer

The class designer: in charge of thing.h– Writes a thing.h header file with the class

specification for class Cthing– Writes comments in thing.h (how to use it)– Carefully separates private and public

information in the class– Most functions are defined as prototypes– Anyone can borrow thing.h as read-only– Only the class designer can change thing.h

7-17William Barrett, San Jose State University, 2009

Class Implementor

The class implementor: in charge of thing.cpp– creates a separate thing.cpp file that implements the

class functions.– Only the implementor may change thing.cpp, compile it

and save it in the SCCS system as cpp and obj files.– thing.obj can be borrowed by anyone, read-only.– Often, anyone can check out thing.cpp, change it

locally for special tests, but NOT check it back in.

7-18William Barrett, San Jose State University, 2009

Class User

Some other programmer that wants to use a class found in SCCS– copies or includes thing.h from SCCS– writes #include "thing.h" into source code– instantiates the class, Cthing, as needed– calls the class member functions– has the linker import thing.obj from the library– May be in charge of other classes that import

or inherit thing.h

7-19William Barrett, San Jose State University, 2009

Why This Works

Any user can make full use of Cthing, to the extent that public access is permitted.

No user can change thing.h or thing.cpp, as carried in SCCS, without special permission from their author.

• Each programmer is protected against unauthorized changes made by other programmers.

• Managers can control code responsibilities.

7-20William Barrett, San Jose State University, 2009

Why This Works

• Changes in the public functions in cthing.h may require changes in user code, and should be done with great care.– A stable design of the header files (the class

definitions) is therefore important to the success of a large project.

– A change will usually be caught by the compiler on a full system recompilation. Messages can be sent by SCCS to the appropriate software engineers about the change.

• Changes in the functions in cthing.cpp may be made by its author at any time.