OO Design

A quick intro to OO Design.

Transcript

1. Object Oriented Design By Josh Comer Graphics from OpenClipArt.org
2. Why Object Oriented? There are many approaches to software design: • Procedural (C, FORTRAN) • Functional (Haskell, OCaml, Clojure) • Object Oriented (Java, Objective-C) Java is designed to be an Object Oriented (OO) language. OO allows developer to easily create abstractions and reason about their software.
3. A Few Things to Remember • There isn't a single correct way to design your software. • Good OO design is tricky, so don't worry if you don't get it perfect the first time. Programming is not about typing, it's about thinking. The sooner you realize that, the sooner you'll become a better programmer. -Rich Hickey
4. How to communicate design When working with other people on a project, everyone needs to be on the same page. UML was created to allow people to clearly communicate software design. By using UML, we can spend more time thinking and less time explaining.
5. Class Diagram Class Name + fieldOne : int - fieldTwo : String ~ FieldThree : float # FieldFour : Object + methodOne(int a, int b) : int - methodTwo() : void Title is bold for concrete classes; italics for abstract classes; and surrounded by <> for interfaces Fields are listed along with their type. + Public - Private ~ Package # Protected Methods include parameters (with types) and the type of the return value
6. Class Level Relationships java.lang.Exception java.lang.SQLException java.io.IOException java.lang.RuntimeException Generalization (IS-A)
7. Class Level Relationships java.util.List java.util.ArrayList java.util.Vector java.util.LinkedList Realization (IS-A)
8. Instance Level Relationships Bank Account Bank Dependency
9. Instance Level Relationships java.util.Scanner java.io.InputStream Aggregation Scanner in = new Scanner(System.in); //System.in is a static InputStream
10. Instance Level Relationships Car Carburetor Composition
11. Where to start when designing 1. Understand the requirements (almost to the point of memorization) 2. Try to list out all of the potential objects required to fulfil the requirements 3. Look for overlaps in your defined objects 4. Map out your software using UML ◦ Remember to keep extensibility and maintenance in mind 5. Double check that your design meets the original requirements
12. Program to an 'interface', not an 'implementation' -Gang of Four "Program to an interface" really means "Program to a supertype". -Head First Design Patterns
13. Design Principles The following design principles are important to keep in mind when designing OO software: • Open Closed Principle (OCP) • Don't Repeat Yourself (DRY) • Single Responsibility Principle (SRP) • Liskov Substitution Principle (LSP)
14. Let's design something... An RPG
15. Things in an RPG • Player ◦ Class ◦ Inventory ◦ Money ◦ Equipment • Items ◦ Weapons ◦ Spells ◦ Money ◦ Armour • Monsters ◦ Equipment ◦ Type ◦ Drop Items • NPC ◦ Conversation • Dungeons ◦ Treasure Chests ◦ Monsters
16. Not all objects are "real" It is easy to only design for objects that have real world counterparts. You will find when designing software that "real" objects are typically in the minority. Examples of non-"real" objects are: • Streams (Input, Output, etc) • Connection Managers • Data Structures