Lectures‎ > ‎Week 5:June 27-July 3‎ > ‎

02-Object Oriented Design Principles

Homework required in preparation for this lecture

  1. Introduction to SOLID Principles
    1. Read this paper: Introduction to the Solid Principles of Object Oriented Design
    2. Look at your code and apply one of these principles to one of your classes or methods
    3. Deliverable: Blog post about this change. Show the code before and after the change. Add commentary.
  1. (Pick one or more of) Readings/Watchings
    1. Read/Watch one or more of these papers
    2. And/or Watch/Listen to this lecture about Solid Object Oriented Design and/or Solid Ruby
      1. Even though they refers to Ruby and TDD, you will pick up much good reinforcement
    3. And/or Read this paper: Design Principles and Patterns
    4. And/or Read this paper: Good Design is Easily Learned
    5. Deliverable: Write a blog post explaining one or two principles that you feel you really understand, with code example.

Object Oriented Principles

Learning Objectives

  • Top down and bottom up ways of thinking about good object oriented design
    • Introduction to Design patterns
    • Introduction to SOLID Object Oriented Principles
  • Get a taste of this large topic
    • Come to realize/believe that good design is not accidental and not a God given talent
    • It is something that has a method to it that can be studied and mastered.

Credits

  • This lecture note is full of links. 
  • If you are interested in this topic, look and read as many of these and other papers as you can.
  • I give credit to the authors of all those pages, pdfs and books for what is on this page.

Design Patterns

What is a design pattern?

  • Adress a recurring design problem that arises in specific situation and presents a solution to it
  • Design patterns are not invented, they are discovered by studying successful designs
  • Many software design patterns are programming language independent
  • When we get to SOLID you will see that design patterns encourage SOLID principles, and vice versa
  • Top-down/Bottom-up
  • Specifically, what is refactoring?

Some example patterns: Creational Patterns

Code

Solid Principles

  • More of a top down view
  • Reference: Principles of OO
  • Rules made to be broken. Not hard and fast!

S: Single Responsibility Principle

  • Very simple: Every class should have exactly one responsibility
  • Or, "there should be only one reason for a class to change"
  • Look at: srp.pdf and look at Single Responsibility Principle
  • Hard: deciding what a single responsibility is or is not
  • Why: If there are more reasons to change than one then maintenance is a pain

O: Open Closed Principle

  • Software entities (classes) should be open for extension, but closed for modification
  • In other words, design a class so that it can be extended by subclassing
  • And that it doesn't ever require to be modified in order to be used.
  • Look at: Open Closed Principle and also Simple example of Open Closed Principle or ocp.pdf
  • Following this principle means that users of your class never feel the need to modify it because it is designed to allow them to get what they want through subclassing and parameterization.

L: Liskov Substitution Principle

  • Simple: You should always be able to use the subclass where the base class was expected
  • Or: Subclasses behave nicely when used instead of their base classes.
  • Also: Favor Composition over Inheritance, that way you avoid this mistake.
  • Square-is-a-rectangle problem. Find the right page in this presentation: OO Principles
  • Heres a longer example of Liskov
  • Look at lsp.pdf

I: Interface Segregation Principle

  • Keep interfaces small and cohesive
  • "Clients should not be forced to depend upon interfaces that they do not use."
  • Encapsulate interdependency between classes in the smallest possible interfaces
  • Here's an example: ISP Example
  • Look at isp.pdf

D: Dependency Inversion Principle

  • High level classes/packages/modules should not rely on low level classes/packages/modules
  • Simple example
    • Should your class refer to LocationRecordDatabase or to ILogcationRecordFinder
    • LocationRecordDatabase has code in it to find a certain log record, but it also has database access, and creation and deletion, and update, and many other things.
    • Creating that dependency means that any of the interface of the LocationRecordDatabase changes, then we need to rebuild, or possibly change our class
    • Better to depend on ILocationRecordFinder, which tightens the dependency to only what's related to Finding.
  • This paper discusses the principle: Dependency Inversion Principle
  • Look at dip.pdf

Afternoon Schedule

  • Team Presentations!!!