Object-Oriented Design?
1 Object-Oriented Design?

Object-Oriented Design?

CS 3500, Spring 2020

Getting in touch

Clark Freifeldccf@ccsNI 132GWed 4:40 — 6:10pm
Thu 2:15 — 4:00pm
or by appointment
Mike Weintraubmaw@ccsNI 132GThu 1:30 — 5:30pm
or by appointment


Grade breakdown:

  • 60% homework

  • 1-2% in-class exercises

  • 15% first exam

  • 24% second exam

N.B. exact percentages may change slightly


  • Eight homeworks: four shorter ones, then four longer ones

  • Usually due at 8:59 PM

  • Self-eval: separate assignment from the "main" assignment. Do not open self-eval until you are done with main assignment.

  • Late policy

    • Four No-Questions-Asked Late Days™

    • Use at most one per assignment

    • No other late work accepted

Academic integrity

  • No illicit collaboration

    • Guideline: words okay, code not okay

    • If unsure, ask!

  • You must submit only your own work

    • If you steal someone else's work, you fail the class

  • You are responsible for protecting your work

    • If someone uses your work, you fail the class

What to expect

  • Time commitment
    • Start early, work often
    • If you are working on same thing for hours, take a step back. You may need some assistance.
  • Testing matters, how/when to test
  • The idea of self-evaluations

Why Object-oriented Design?

Because software
isn't easy

Writing software is hard

Writing good software
is very hard

Simple semantics

(define (f->c f) (* 5/9 (- f 32)))

(f->c 212)

(* 5/9 (- 212 32))
(* 5/9 180)

But programs get big

1993Windows NT 3.14
1994Windows NT 3.57
1996Windows NT 4.011
2000Windows 200029
2001Windows XP40
2003Windows Server 200350
2007Windows Vista50

We compose complex systems from simple parts

We can write programs that we cannot completely understand

Another challenge: change

  • Customers don't know what they want

  • What they want changes

Software development life cycle

  1. Analysis

  2. Design

  3. Implementation

  4. Testing

  5. Deployment

  6. Evaluation

  7. GOTO 1

Software development life cycle in theory

  1. Analysis

  2. Design

  3. Implementation

  4. Testing

  5. Deployment

  6. Evaluation

  7. GOTO 1

Software development life cycle in practice

  1. Cursory analysis

  2. Completely wrong implementation

  3. Slightly less cursory analysis

  4. Wrong-headed design

  5. Some implementation and testing

  6. More analysis and re-design

  7. More implementation and testing

  8. Iterate, iterate, iterate

  9. Deployment

  10. Bug reports (Yay!)

  11. Head scratching

  12. Coffee

  13. Temptation to rewrite from scratch

We need help!

  • How can we deal with complexity?

  • How can we design for flexibility?

One possible answer:
object-oriented design

Object-oriented design

Central concepts:

  • Information hiding

  • Interfaces

  • Polymorphism

Loose coupling

  • Replacement

  • Reuse

SOLID Principles

  • Single responsibility: every object should be responsible for just one focused purpose

  • Open/closed: everything can be open to extension, but closed to modification

  • Liskov substitution: if a type S is a subtype of a type T, then objects of type S can be used anywhere objects of type T can.

  • Interface segregation: no client should be forced to depend on methods it doesn't use

  • Dependency inversion: abstractions should not depend on details; rather the reverse

What makes software “good”?

  • Correctness

  • Efficiency

  • Security, maintainability, robustness, portability, reliability, testability, usability, scalability, ...

“No silver bullet”

There is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity.

—Fred Brooks


  • What are objects all about?

  • Interface polymorphism

  • Data abstraction and encapsulation

  • Client perspective versus implementor perspective

  • Object-oriented terminology

  • Generic polymorphism

More topics

  • Testing and specification

  • Algorithmic efficiency

  • Software archaeology

  • Class diagrams

  • Design patterns