CS 101 (Spring 1999)
Lecture 2
Objects, Outside and In

Quick picks: [ outside ] [ hide details ] [ details ]

Objects from the outside

In the year Software is
1960 Small
1970 Cheap
1980 Efficient
1990 Understandable
1999 Reusable

Observation: When a company produces software, the organization of that software reflects the organization of the company.

Corollary: Software systems are designed with real-world analogies in mind. Resulting systems are more

Idea:

Example: Doctors and Patients

We seek to understand the behavior of the components before we understand their implementation Thus, in this course, we study both design and implementation.

Ideally, a program's design segues to implementation in a number of carefully taken steps. A good anaology is structural architecture
  1. Initial design -- sketch the objects
  2. Design object behavior -- how they interact
  3. Implement a little of each kind of object
  4. Piece a rudimentary system together from the pieces.
  5. Test the prototype
  6. Add detail, test
  7. Keep going until done
  1. Determine the scope of the building
  2. Sketch footprint
  3. Sketch floors and rooms
  4. Interconnect floors and rooms
  5. Build outer shell
  6. Fill in a floor
  7. Fill in the rooms
  8. Add furniture and people

This approach to design can be thought of as

The hard part is arriving at a design that can be extended or reused in the future. It's a matter of taste and aestetics.

Examples (from the doctor's office):

This is why a large software project begins with a set of requirements, so it is clear what is expected of the software.

Objects hide details (Abstraction)

In Java, each kind of object becomes a class. This is shown below for Patient and Doctor.

Return Type Method Name Parameters
Diagnosis visit
Patient p
VitalSigns vs
Return Type Method Name Parameters
String getName

Return Type Method Name Parameters
boolean isBusy
int numSeen
Return Type Method Name Parameters
boolean isAllergic Medicine m
Symptoms getSymptoms
Note the conventions about upper and lower case.

In the above, note how digging into the design reveals the need for more kinds of objects. The method definitions above the line are from the initial thinking. But as we proceed, we find we need the methods below the line.

The decomposition of this problem led to abstraction about symptoms.
This course is largely about using decomposition and abstraction to solve computational problems.

What about the details?

Recall the notion of an algorithm -- a recipe for computing something. In Java and other OO languages, each object contains pieces of the recipe---ideally the pieces that deal with the object.

In the doctor's office:



Last modified 23:06:51 CST 13 January 1999 by
Ron K. Cytron