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