Exercises

* None from this chapter since you probably have enough from the current homework.

Reading Assignments

* Ch 10.

Assignment #5

* due Fri, Aug 4.

Midterm #2

* Monday, July 31 (covers all material up to July 28).

Analysis/Design/Implementation

* In modern programming practice, the development of new computer software incorporates 3 phases:

1. Analysis - defining the problem (what)

2. Design - the solution (high level).

3. Implementation - the solution (code).

* For example, in hw#5, the problem is already defined. You need to provide a design and an implementation.

Problem domain and solution domain

Object-oriented design

* A design of a problem solution by focusing on

1. entities (objects), and

2. operations on these objects.

* Common steps

1. identify the objects and operations

2. determine where to place the objects and operations

3. design the driver

4. implementing the design

What is an object?

* a class instance.

* a variable of a built-in type.

* examples:

Complex a;

Item_List b;

int c;

What is an operation?

* any action that manipulates data

* examples:

i++; // built-in operation

list.insert_item(...); // member function

strcmp(..., ...); // global function

A way to find objects and operations

* From the problem statement,

1. nouns may suggest objects

2. verbs may suggest operations

* Determining which nouns and verbs are significant is difficult.

* Examples of nouns from hw#5:

bank, customer, account, account_number, balance,

customer_name, ...

* Examples of verbs from hw#5:

balance, deposit, withdraw, has, close, ...

Object - Bank

* Characteristics

1. name

2. a list of customers

3. a list of accounts

4. ...

* Operations

1. open an account

2. balance of an account

3. deposit to an account

4. ...

Object - Account

* Characteristics

1. account number

2. type

3. balance

4. ...

* Operations

1. open

2. close

3. balance

4. ...

Where to place the objects and operations

* Relationships among the objects

1. has-a relationship (e.g. a customer has a name.)

2. part-of relationship (e.g. an account number is a part of the account.)

* Reasons why it is important to determine the relationships

1. The relationships leads to natural ways to implement the design.

2. They also suggestion where to place the operations.

Which object has primary responsibility for the operation?

* deposit an amount to an account.

1. account (object)

2. amount (object)

3. deposit (operation)

* Compare the following calls

account.deposit(amount); // member function call

amount.deposit(account); // member function call

deposit(accoutn, amount); // global function call

* Which is better?

* If you cannot assign primary responsibility to just one object, the operation is probably a global one. For examples, the driver code has quite a few global functions.

The driver

* does little more than process user commands and delegates tasks to the objects.

Classes vs. objects

* In order to have a bank object, in C++, you need to define a bank class first.

* Following the convention that class names start with an uppercase letter, we may have something like this:

class Bank {

public:

// operations allowed on Bank objects

private:

// characteristics or attributes of Bank objects

};

Bank bank; // where do you expect this to be

// declared?

Classes vs. files

* You also need to decide where to put the classes.

* For example, should the Bank class put in a .h file? If so, you need to encapsulate it with #ifndef ... #endif. Why?

#ifndef BANK_H

#define BANK_H

class Bank {

...

};

#endif

Relationships between classes

* The bank class may need to use services provided by other classes.

// bank.h

class Service {

};

class Bank {

// uses Service

};

//

* Is the above a good style?

Other choices

* include the service provider's specification

// bank.h

#include "service.h"

class Bank {

// can use full services to Service.

};

* just use the type name without the details

// bank.h

class Service;

class Bank {

// can only use a pointer to Service.

};

Summary

* Object-oriented design typically results in layered software.

* Abstract data types (ADTs) play a vital role in these layers of abstraction.

* It is "commonly believed" that object-oriented design leads to easily maintainable programs.

* But we have only a very brief introduction to object-oriented design.

* We have not considered

1. inheritance

2. polymorphism