CS 151: Object-Oriented Design October 15 Class Meeting Department of Computer Science San Jose...

CS 151: Object-Oriented DesignOctober 15 Class Meeting

Department of Computer ScienceSan Jose State University

Fall 2013Instructor: Ron Mak

www.cs.sjsu.edu/~mak

SJSU Dept. of Computer ScienceFall 2013: October 15

CS 151: Object-Oriented Design© R. Mak

2

In-Class Team Exercise: UML Class Diagram

Draw a UML class diagram that captures all of these facts: A university has several departments. Each department has a department chair. Each department teaches several courses. Two of the departments are computer science (CS)

and computer engineering (CMPE). The computer science department teaches the courses

CS 101, CS 102, and CS 103. The computer engineering department teaches the courses

CMPE 101 and CMPE 102. CS 102, CS 103, and CMPE 102 are also online. Each course has a professor, a number of students,

and possibly a graduate student T.A. People have home addresses.

SJSU Dept. of Computer ScienceFall 2013: October 15

CS 151: Object-Oriented Design© R. Mak

3

An Exercise Solution

University Address

Chair

«interface»Graduate

Person

CS 101

CS 102

CS 103

CMPE 101

CMPE 102

ComputerEngineering

ComputerScience

Department1..n

Course1..n

Student

Professor

1..n

TA0..1

«interface»Online

SJSU Dept. of Computer ScienceFall 2013: October 15

CS 151: Object-Oriented Design© R. Mak

4

What Lessons Did We Learn?

“Factor out” common properties and put them into superclasses. Examples: Department, Course, Person Many of these classes should be abstract

(not shown in the suggested solution). But not all: Student

Use marker interfaces to “tag” certain classes that are in different hierarchies. Examples: Online, Graduate

“May have” or “possibly have” means the multiplicity starts with 0. Example: A course possibly has a TA.

SJSU Dept. of Computer ScienceFall 2013: October 15

CS 151: Object-Oriented Design© R. Mak

5

Review: Model-View-Controller Architecture

The user interacts with the controller (via buttons, menus, etc.) to send it commands.

The commands may tell the controller to modify the view directly, or the controller may alter the state of the model.

The altered model causes the view to update how it displays the model’s data.

The user reacts to changes in the view by interacting with the controller to send it new commands._

The user never manipulates the model directly,

only through the controller.

SJSU Dept. of Computer ScienceFall 2013: October 15

CS 151: Object-Oriented Design© R. Mak

6

Model-View-Controller Example

alter state

update update

CONTROLLER

MODEL

VIEW #1 VIEW #2

User

send command

There can be multiple views of the same model. Each view updates after the model changes.

SJSU Dept. of Computer ScienceFall 2013: October 15

CS 151: Object-Oriented Design© R. Mak

7

The Observer Design Pattern

Context An object (the “subject”) generates “events”. One or more other objects (the “observers”) want to be notified

whenever an event occurs.

Solution The subject manages

(attaches and detaches) a collection of observer objects.

Each observer object is instantiated from a class that implements the Observer interface.

Whenever an event occurs, the subject object notifies each observer object by calling the notify() interface method.

From: Object-Oriented Design & Patterns, John Wiley & Sons, 2006.

SJSU Dept. of Computer ScienceFall 2013: October 15

CS 151: Object-Oriented Design© R. Mak

8

The Observer Design Pattern

Therefore, in the MVC architecture, each time the model object (subject) changes (an event), it notifies each of its view objects (observers).

Where have we already seen another example of the observer design pattern? What happens when you click a button in a GUI? The actionPerformed() method of each ActionListener

object that is attached to the button is called. What are the subject, event, observer, and notification

method? Subject = button

Event = button clickObserver = action listenerNotify method = actionPerformed()

SJSU Dept. of Computer ScienceFall 2013: October 15

CS 151: Object-Oriented Design© R. Mak

9

Quiz #42013Oct15

SJSU Dept. of Computer ScienceFall 2013: October 15

CS 151: Object-Oriented Design© R. Mak

10

Review for the Midterm

What it means for software to be well-designed.

Achieving good design via an iterative process.

Encapsulate parts of the design that will change. Refactoring.

Iterative and incremental development. Mini-waterfall per iteration.

Functional specification Functional requirements Nonfunctional requirements Stated and implied requirements

SJSU Dept. of Computer ScienceFall 2013: October 15

CS 151: Object-Oriented Design© R. Mak

11

Review for the Midterm

Use cases UML use case diagram Use case description

Where do classes come from?

Class responsibilities and relationships CRC cards

_

SJSU Dept. of Computer ScienceFall 2013: October 15

CS 151: Object-Oriented Design© R. Mak

12

Review for the Midterm

UML class diagram Relationships Multiplicities Aggregation vs. composition

UML sequence diagram

UML state diagram_

SJSU Dept. of Computer ScienceFall 2013: October 15

CS 151: Object-Oriented Design© R. Mak

13

Review for the Midterm

Javadoc

Designing good classes Example: Day class

Factory method design pattern

Importance of encapsulation_

SJSU Dept. of Computer ScienceFall 2013: October 15

CS 151: Object-Oriented Design© R. Mak

14

Review for the Midterm

Accessors and mutators

Side effects

Mutable and immutable classes Final fields

How good is an interface?_

SJSU Dept. of Computer ScienceFall 2013: October 15

CS 151: Object-Oriented Design© R. Mak

15

Review for the Midterm

Programming by contract Preconditions Postconditions Invariants Assertions

Unit testing JUnit

Regression testing

Design patterns_

SJSU Dept. of Computer ScienceFall 2013: October 15

CS 151: Object-Oriented Design© R. Mak

16

Review for the Midterm

Coding to the interface

Java interfaces Marker interfaces

Polymorphism

Comparable interface type Comparator interface type

Anonymous classes_

SJSU Dept. of Computer ScienceFall 2013: October 15

CS 151: Object-Oriented Design© R. Mak

17

Review for the Midterm

JFrame class JButton class JTextField class

Button actions_

SJSU Dept. of Computer ScienceFall 2013: October 15

CS 151: Object-Oriented Design© R. Mak

18

Review for the Midterm

Inversion of control

Java Timer class

Graphics context Shape interface Animation

Interface as a contract

Strategy design pattern

Dynamic class loading

SJSU Dept. of Computer ScienceFall 2013: October 15

CS 151: Object-Oriented Design© R. Mak

19

Review for the Midterm

Swing development support in NetBeans

Model-view-controller architecture

Observer design pattern_