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.

Lecture Schedule

Why object-oriented design?

The essence of objects

Java review

Java safari

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

First exam

Design critique: music models

Class activity: GUI, MIDI basics

MVC code, starter code and code

The Adapter pattern

Commands

The strategy and decorator patterns

Class activity: Strategic FreeCell

Case study: Interpreters

Introduction to JavaScript

JavaScript inheritance and patterns

Exam review

Promises

Final exam

Bonus lecture (Android?)

Thoughts

Looks like it'll be a good semester. One of the main projects of the semester is making a musicplayer (which I've already done in java) so that'll be really fun. Also excited to see javascript at the end of the semester as that's always a mess. It also seems like they're going to have another git tutorial :(.

Why OOD?

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

Analysis
Design
Implementation
Testing
Deployment
Evaluation
GOTO 1

Things don't look like this in practice. In practice they look like:

Cursory analysis
Completely wrong implementation
Slightly less cursory analysis
Wrong headed design
Some implementation and testing
More analysis and re-design
More implementation and testing
Iterate, iterate, iterate
Deployment
Bug reports (yay!)
Head scratching
Coffee
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
Polymorphism
Interfaces

Loose coupling:

Replacement
Reuse

SOLID Principles:

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.

"Good Software":

Correctness
Efficiency
Security
Extensibility
Scalability
Reliability
(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.

Course Topics:

What are objects all about?
Interface polymorphism
Data abstraction and encapsulation
Client perspective vs implementor perspective
Testing
Algorithmic efficiency
Software archeaology
Class diagrams
design patterns