Object-Oriented Design?
1 Object-Oriented Design?

Object-Oriented Design?

CS 3500, Fall 2023

Getting in touch

Ben Lernerblerner@ccsWVH 326
Lucia Nunezl.nunez@northeasternMeserve 335
Vidoje Mihajlovikjv.mihajlovikj@northeasternMeserve 309
Amy Gatelya.gately@northeasternMeserve 301

Things to do now


Grade breakdown:

  • 60% homework

  • 1-2% in-class exercises

  • 15% first exam

  • 24% second exam

N.B. exact percentages may change slightly


  • Nine homeworks: four shorter ones, then four longer ones, and one extra credit

  • Usually due at 8:59 PM

  • Examplar: separate assignment from the "main" assignment. Usually due three days after assignment release.

  • Self-eval: another 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 (2 for individual, 2 for group)

    • Use at most one per assignment

    • No other late work accepted


  • Your goal: write examples to separate the working implementations (wheat) from the buggy ones (chaff)

  • Our goal 1: Give you intuition on writing meaningful tests from a specification.

  • Our goal 2: Give you a way to test your assumptions.

  • Grading criteria

    • Correctness: How many tests do not cause the wheat to fail?

    • Thoroughness: How many chaffs cause at least one of the tests to fail?

    • Precision: For each chaff, is there a unique subset of examples that fail on that chaff?

    • Uniqueness: For each test method, did that test method catch a unique subset of chaffs?

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

  • If you are using github, make and keep repo private

What to expect

  • Time commitment
    • Read lecture notes, attend lectures regularly
    • Start early, work often
    • If you are working on same thing for hours, take a step back. You may need some assistance.
  • Lecture -> Assignment correspondence
  • 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