CS 3500, Spring 2020
Getting in touch
|Clark Freifeld||NI 132G||Wed 4:40 —|
Thu 2:15 —
or by appointment
|Mike Weintraub||NI 132G||Thu 1:30 —|
or by appointment
Sign up for Piazza (instructions on main web page)
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.
Four No-Questions-Asked Late Days™
Use at most one per assignment
No other late work accepted
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?
Writing software is hard
Writing good software
is very hard
(define (f->c f) (* 5/9 (- f 32))) (f->c 212)
(* 5/9 (- 212 32))
(* 5/9 180)
But programs get big
|1993||Windows NT 3.1||4|
|1994||Windows NT 3.5||7|
|1996||Windows NT 4.0||11|
|2003||Windows Server 2003||50|
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
Software development life cycle in theory
Software development life cycle in practice
Completely wrong implementation
Slightly less cursory analysis
Some implementation and testing
More analysis and re-design
More implementation and testing
Iterate, iterate, iterate
Bug reports (Yay!)
Temptation to rewrite from scratch
We need help!
How can we deal with complexity?
How can we design for flexibility?
One possible answer:
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
Sis a subtype of a type
T, then objects of type
Scan be used anywhere objects of type
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”?
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.
What are objects all about?
Data abstraction and encapsulation
Client perspective versus implementor perspective
Testing and specification