CS 3500 Day 1
Object Oriented Design
This is my first post for OOD, I’m going to be using this as a place to take notes and write code.
They say to use IntteliJ but like almost everything else I’m going to try and only use Sublime Text. I may have to make custom build scripts to match intelliJ projects, but I hate Android Studio (an IntelliJ fork) so I’m really going to try and steer clear from that.
Why object-oriented design?
The essence of objects
Java safari (part 2)
Version control with Git
Introducing the Model, and the Builder pattern
Controllers and Mocks; Class Activity: abstracting I/O
Design critique: testing, toString, Pile abstractions, I/O
Encapsulation and Invariants
Design exercise: Turtles
Inheritance vs. composition
Intro to Performance
Design critique: music models
Class activity: GUI, MIDI basics
MVC code, starter code and code
The Adapter pattern
The strategy and decorator patterns
Class activity: Strategic FreeCell
Case study: Interpreters
Case study: Interpreters
Bonus lecture (Android?)
Software isn’t easy. Writing good software is a tough pursuit. Writing something that converts farenheit to celsius is easy.
(define (f->c F) (* 5/8 (- F 32))) (f->c 212)
Programs get big
- Windows NT 3.1 had 4 million lines of code
- Windows 2000 had 29 million
- Windows server 2003 had 50 million
A lot of software development is maintainance. How do we start thinking about such big programs? These complex parts are all made from simple ones. It’s totally possible to write programs that we cannot completely understand. You can work on one part of a program without understanding the rest. This is only possible with extensibility. Software is ALWAYS bound to change:
- Customers don’t know what they want
- What they want always changes too
- Very few things in the real world are black & white
Software developement life cycle
7) GOTO 1
Things don’t look like this in practice. In practice they look like:
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
10) Bug reports (yay!)
11) Head scratching
13) Temptation to re-write from scratch
One possible answer is object oriented design
OOD is a set of principles to avoid the previous list. What is it? Central concepts:
- Information hiding
- Single responsibility, meaning that each class should have a single responsibility or purpose.
- Open/closed, meaning that interfaces should be open to reimplementation, and that clients should not require modification.
- Liskov substitution, meaning that objects of subtypes may be used anywhere that the supertype can be used.
- Interface segregation, meaning that classes should offer small, specialized interfaces for different kinds of clients.
- Dependency inversion, meaning that details should depend on abstractions rather than abstractions depending on details.
- (insert buzz word)
This course is about hitting more of these things. There’s a special point between efficiency and abstraction. It’s important to understand the code that you wrote.
- What are objects all about?
- Interface polymorphism
- Data abstraction and encapsulation
- Client perspective vs implementor perspective
- Algorithmic efficiency
- Software archeaology
- Class diagrams
- design patterns