Homework required in preparation for this lecture
Object Oriented Principles
- 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.
- 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.
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
- Specifically, what is refactoring?
Some example patterns: Creational Patterns
- Different ways of creating -- instantiating a class. Question: What is the most basic way?
- Factory Pattern - Choose and return an instance of a class from a number of similar classes based on a data you provide a factory. Here's a bit of code and an abstract factory also
- Singleton Pattern - Ensures that there is one and only one instance of an object, and that it's possible to obtain global access to it from anywhere. Here's a bit of code.
- There are lots of other patterns that have been written up
- 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