You are on page 1of 15

1

CSC 413 - Software Development


4. Object Oriented Design

2/3/18

John Roberts

2
Context

3
Context

• When designing software, we want to be able to be flexible

• Provide reusable software components - “software


integrated circuits”

• Program for change - it’s going to happen

• Focus on the data, not the tasks - the data is less likely to
change, unlike the tasks

• Think about the objects in a system and their responsibilities


- what they will do, NOT how they will do it

3
4
Objected Oriented Programming & Design
Principles

• Encapsulation - Hide details in a class, provide methods

• Polymorphism - Same name, different behavior (based


on actual run time type)

• Inheritance - Capture common attributes and behaviors


in a base class and extend it for different types

• Let’s ask as we go through this content how each of


these principles relates to the concepts we’re discussing

5 Tools for OOD


Overview
• CRC Cards

• Software components

• Plan for change

• Interfaces vs. Implementation

• Abstract Classes

• Naming

• Patterns

6
CRC Cards

• Component - Name (class)

• Responsibility - What it does (methods)

• Collaborators - List of other components this


component deals with (whose services it uses

• Visual tool for OOD - provide us with a means to design


and describe the entities (classes, objects) in our domain
(problem space)

• Note that I don’t need a code editor to use these tools!


6
7
Index Cards

Component Name (Class)

Collaborators
Responsibility of Component List of other components this
component deals with (e.g. whose
services it uses)
What it does (Methods)

8 Note that class diagrams provide the same information as CRC cards; there
Class Diagrams are CASE (Computer Aided Software Engineering) tools for constructing class
• Note the cardinality (1, n) and the association (uses) diagrams (Rational Rose)
Class Class

1 n
Methods/Data Methods/Data
uses

Professor Student

1 n
giveExercise() doExercise()
teach

9
Overview
• CRC Cards

• Software components

• Plan for change

• Interfaces vs. Implementation

• Abstract Classes

• Naming

• Patterns

9
10 Context: Encapsulation
Software Components

• Described by behavior (methods/protocols of class) and


state (information/data of class)

Student

coursesCompleted
State
coursesEnrolledIn

study()
Behavior
doExercise()

10

11
Cohesion

• The degree to which the responsibilities of a single


component form a meaningful unit

• Tasks (behaviors) defined in the unit should be strongly


related

11

12
Coupling

• Coupling is the degree of interdependence between


software modules

• Low coupling refers to a relationship in which one module


interacts with another module through a simple and
stable interface and does not need to be concerned with
the other module's internal implementation

• Reduce coupling as much as possible to minimize


cascading changes!

12
13
Overview
• CRC Cards

• Software components

• Plan for change

• Interfaces vs. Implementation

• Abstract Classes

• Naming

• Patterns

13

14 DRY, SRP
Localize Changes

• Avoids cascading changes to many components when a


slight change occurs in the problem specification

• What’s one way we do this?

14

15 Interfaces, Facade Pattern - reduce dependencies of outside code on the


Try to predict Tension Points inner workings of a library
• Points in the code that are likely to change

• Code these areas carefully to minimize impacts of


change

• What’s one way we do this?

15
16 C++ preprocessor directives and pragmas
Minimize or Isolate Hardware Dependencies

• Porting considerations

• What’s one way we do this?

16

17 SRP
Reduce Coupling Between Components

• Recall coupling is the relationship between software


components

• What’s one way we do this?

17

18
Document Important Design Decisions

• Helps future programmers understand

• the code

• the design philosophy of the system

18
19
Overview
• CRC Cards

• Software components

• Plan for change

• Interfaces vs.
Implementation

• Abstract Classes

• Naming

• Patterns

19

20
Interfaces vs. Implementation

• Other programmers needing to use my component only


need to know what services my component offers

• NOT HOW the services are implemented

• Why?

20

21
Interfaces vs. Implementation

• Other programmers needing to use my component only


need to know what services my component offers

• NOT HOW the services are implemented

• I can change the implementation of a service and the


user’s code is unaffected

21
22
Example

• Professor tells students to study

• Students manage the time, place, resources

• Professor doesn’t manage HOW the student is studying

• Too much responsibility for the Professor

• Student agency means they can change HOW they


study without affecting the Professor’s responsibilities

22

23 Arrays, Linked List


Example

• I might need a list to implement some part of my program

• Another programmer programs the list, providing


behaviors to add items, remove items, etc.

• What are some ways a list can be implemented?

23

24 So I’m yelling at you


Example

• I might need a list to implement some part of my program

• Another programmer programs the list, providing behaviors to


add items, remove items, etc.

• Regardless of Array or Linked List implementation, my code


should simply use the services (behaviors) the implementation
provides without any knowledge as to how the list is implemented

• Successive changes to the implementation do not affect our


code - our code remains unchanged

• THIS IS AN EXTREMELY IMPORTANT CONCEPT

24
25 “the interface” includes other interfaces you have written, in your own project
Program to an Interface, not an Implementation

• Program to the Interface - the implementation should be


irrelevant to your code

• So long as the interface is stable, your code remains


unchanged

• Interfaces specify what behavior is included


without any details on how that behavior is
implemented

25

26 Principle of least information.


Parna’s Principles

• The developer of a software component must provide the


intended user with all the information needed to make
effective use of the services provided by the component,
and should provide no other information.

• The developer of a software component must be


provided with all the information necessary to carry out
the given responsibilities assigned to the component, and
should be provided with no other information.

26

27
Overview
• CRC Cards

• Software components

• Plan for change

• Interfaces vs. Implementation

• Abstract Classes

• Naming

• Patterns

27
28 Context: Inheritance
Abstract Class

• May not be instantiated

• Contains one or more abstract methods - declared, but


has no implementation

• Requires subclasses to provide implementations for the


abstract methods

28

29
Example

• Suppose we are modeling the behaviors of animals, creating


a class hierarchy that starts with a base class called Animal

• Animals can do some different things (fly, dig, walk), but


there are some common operations like eating and
sleeping

• Some common operations are performed by all animals,


but in a different way

• When an operation is performed in a different way, it is a


good candidate for an abstract method, forcing subclasses
to provide a custom implementation
29

https://github.com/sfsu-csc-413-roberts/lecture-4

1 public abstract class Animal {


2 public void eat( Food food ) { 30
3 // do something with food....

Note the use of @Overrides here! Gives us compiler check (and warning if it’s
4 }
5
6 public void sleep( int hours ) {

not right), and makes code more explicit.


7 try {
8 Thread.sleep ( 1000 * 60 * 60 * hours );
9 } catch ( InterruptedException ie ) {
10 /* ignore */
11 }
12 }
13
14 public abstract void makeNoise();
15 }
16
17 public class Dog extends Animal {
18 @Overrides
19 public void makeNoise() {
20 System.out.println( "Bark! Bark!" );
21 }
22 }
23
24 public class Cow extends Animal {
25 @Overrides
26 public void makeNoise() {
27 System.out.println( "Moo! Moo!" );
28 }
30
29 }
31
Abstract Class vs. Interface

• Why not declare an abstract class as an interface,


and have the Dog and Cow implement that interface?

31

32
Abstract Class vs. Interface

• Why not declare an abstract class as an interface,


and have the Dog and Cow implement that interface?

• You’d also need to implement the eat and sleep


methods for each class. Using abstract classes allows
us to inherit the implementation of other (non-abstract)
methods.

• Interfaces cannot provide any method implementations

32

33
Overview
• CRC Cards

• Software components

• Plan for change

• Interfaces vs. Implementation

• Abstract Classes

• Naming

• Patterns

33
34 non native english speakers may not be able to parse your abbreviations!
Naming keep your fellow programmers in mind.
• Use pronounceable, intention revealing names

• Use capitalization to mark the beginning of a new word


within a name: cardReader rather than cardreader

• Examine abbreviations carefully - use meaningful


abbreviations (meaningful to more than just you! I
personally prefer not to use abbreviations)

34

35 the first is the zero


Naming

• Avoid names with several interpretations

• Does the function empty tell whether something is


empty, or empty values the the object?

• Avoid digits within a name - some are easy to misread as


letters (0 or O)

35

36
Naming

• Name functions and variables that yield Boolean values


so they clearly describe the interpretation of a true or
false value

• e.g. PrinterIsReady clearly indicates that a true


value means the printer is working, whereas
PrinterStatus is much less precise

• Take extra care in the selection of names for operations


that are costly and infrequently used. Doing so can avoid
errors caused by using the wrong function.

36
37
Naming

• Why is this important?

37

38
Naming

• Code describes the domain - avoids misunderstandings


when communicating about code (even among non-
technical team members)

• Code is self documenting - reading it yields a reasonable


understanding of functionality without needing a parser!

38

39
Overview
• CRC Cards

• Software components

• Plan for change

• Interfaces vs. Implementation

• Abstract Classes

• Naming

• Patterns

39
40
Software Design Patterns

• Design Patterns: Elements of Reusable Software Design,


Addison Wesley Publishing, 1994 (Amazon)

• This book catalogues 23 Object Oriented design patterns

• Each pattern describes a problem which occurs over


and over again in our environment, and then describes
the core of the solution to that problem in such a way
that you can use this solution a million times over,
without ever doing it the same way twice.

40

41
Why Study Patterns?

• Can reuse solutions

• Gives us a head start in common problem spaces

• Avoids the gotchas later (unanticipated issues)

• No need to reinvent the wheel

41

42
Why Study Patterns?

• Establish Common Terminology

• Design patterns provide a common point of reference

• Easier to say, “We need to use a Strategy here.”

• Provides a higher level perspective

• Frees us from dealing with the details too early

42
43 We’ll look at a few of these this semester
Software Design Patterns

• The book defines 23 patterns in three categories

• Creational patterns deal with the process of object


creation

• Structural patterns deal primarily with the static


composition and structure of classes and objects

• Behavioral patterns deal primarily with the dynamic


interaction among classes and objects

43

44
Software Design Patterns

Creational Structural Behavioral


Abstract Factory Adapter Chain of Responsibility
Builder Bridge Command
Factory Method Composite Interpreter
Prototype Decorator Iterator
Singleton Facade Mediator
Flyweight Memento
Proxy Observer (MVC)
State
Strategy
Template Method
Visitor
44

You might also like