Object-Oriented Design?
1 Object-Oriented Design?

Object-Oriented Design?

CS 3500, Summer I 2020

Getting in touch

InstructorEmailOffice
Amit Sheshashesh@ccsNI 132C
Clark Freifeldccf@ccsNI 132G
Jason Hemannj.hemann@northeastern326 WVH
Vidoje Mihajlovikjv.mihajlovikj@northeastern132E Nightingale

Things to do now

  • Bookmark: https://course.ccs.neu.edu/cs3500/

  • Sign up for Piazza (instructions on main web page)

  • Register on handins.ccs.neu.edu. Choose your section correctly!

  • Make sure you can access this course on Teams (one for entire course, one for your section)

Resources for the entire semester

Grading

Grade breakdown:

  • 60% homework

  • 1-2% in-class exercises

  • 15% first exam

  • 24% second exam

N.B. exact percentages may change slightly

Homework

  • Seven homeworks: four shorter ones, then three 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 (2 for individual, 2 for group)

    • 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

  • 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

How to use lecture notes

  • Read the recommendations on course web page

  • Fill out ungraded survey for each lecture on handins (you won't be able to submit an assignment if you don't!)

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)
100

But programs get big

YearOSMLoc
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

Topics

  • 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