Why Object-Oriented Design?
1 Why Object-Oriented Design?

Why Object-Oriented Design?

CS 3500, Fall 2015

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 XP45
2003Windows Server 200350

We compose complex systems from simple parts

We can write programs that we cannot 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, ...

Efficiency vs. abstraction?

Efficiency via abstraction?

Design

“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

Administrivia

Getting in touch

InstructorBenjamin Lerner
Emailblerner@ccs
OfficeWVH 314
HoursTBA
or by appointment

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

Grading

Grade breakdown:

  • 60% homework

  • 15% first exam

  • 25% second exam

N.B. exact percentages may change slightly

Homework

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

  • Usually due at 11:59 PM

  • Late policy

    • Four No-Questions-Asked Late Days™

    • Use at most two per assignment

    • No other late work accepted

See you next week