archived | title | date | description | tags | draft | project | |||
---|---|---|---|---|---|---|---|---|---|
true |
CS 3500 Day 1 |
2017-01-10 |
Object Oriented Design |
|
false |
OOD |
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 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
Case study: Interpreters
Introduction to JavaScript
JavaScript inheritance and patterns
Exam review
Promises
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 :(.
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
-
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