Published on

CS 3500 Day 1

  • avatar
    Jacob Aronoff

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.

Course Website

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


The strategy and decorator patterns

Class activity: Strategic FreeCell

Case study: Interpreters

Case study: Interpreters

Introduction to JavaScript

JavaScript inheritance and patterns

Exam review


Final exam

Bonus lecture (Android?)


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

  1. Analysis

  2. Design

  3. Implementation

  4. Testing

  5. Deployment

  6. Evaluation

  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

  9. Deployment

  10. Bug reports (yay!)

  11. Head scratching

  12. Coffee

  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
  • 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