Lecture of 10 January 1996

Announcements

• Classes are suspended on Monday 15 January, Martin Luther King Jr. Day.
• Reading Assignment (for lectures starting late on 12 January or 17 January): Pages 37 through 74 of Budd.

Thinking Object-Oriented

• The Power of Metaphor. One can look upon OOP as a form of simulation in which one constructs a program from objects corresponding to real-world material (or conceptual) objects and imbues these objects with the salient state and behavior properties necessary to carry out the intended computation.

  This is why simulation (Simula67) is one of the pillars upon which OOP is based.

  Using this metaphorical idea helps one construct hierarchies of objects to solve large-scale problems rather than finding ways to constrain the flow of control through a large imperative program.

• Machine Code -> Assembly Language -> Procedural Abstraction
• Data Structures -> Structured Programming -> Data Abstraction
• Problem of two stacks -> must associate behavior with data rather than associate data with the behavior.
• Parnas Principle, appropriate use of modules:
  1. One must provide the intended user with all the information needed to use the module correctly, and with nothing more.
  2. One must provide the implementor with all the information needed to complete the module, and nothing more.
• Collision of Data Abstraction and Procedural Abstraction, (procedures become part of the data), adding polymorphism, adding inheritance -> OOP

Responsibility-Driven Design

• Topics
  • Programming in the Large vs. Programming in the Small
  • Responsibility Driven Design
  • Scenarios
  • Components
  • Mechanisms for Component Reuse
  • Finding Classes
• Design is critically important to successful programming.

  Small programs can be conceived of by a single programmer and a simple informal specification can encompass all (or most of the) relevant characteristics of a solution. (Chief programmer team concept is appropriate.)

  Large programs require a team of programmers for whom the most difficult task becomes communication rather than programming. (Design practice and communication strategies are critical because no chief programmer can understand the whole system.

  Miller, G. The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information. The Psychological Review, vol. 63(2), p.86. People don't deal well with large systems containing many different objects. They need hierarchies to simplify the problem.