CS 151: Object-Oriented Design October 15 Class Meeting Department of Computer Science San Jose State University Fall 2013 Instructor: Ron Mak

SJSU Dept. of Computer Science Fall 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 Science Fall 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 Computer Engineering Computer Science Department 1..n Course 1..n Student Professor 1..n TA 0..1 «interface» Online

SJSU Dept. of Computer Science Fall 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 Science Fall 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 Science Fall 2013: October 15 CS 151: Object-Oriented Design © R. Mak 6 Model-View-Controller Example alter state update CONTROLLER MODEL VIEW #1VIEW #2 User send command  There can be multiple views of the same model. Each view updates after the model changes.

SJSU Dept. of Computer Science Fall 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 Science Fall 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 click Observer = action listener Notify method = actionPerformed()

SJSU Dept. of Computer Science Fall 2013: October 15 CS 151: Object-Oriented Design © R. Mak 9 Quiz #4 2013Oct15

SJSU Dept. of Computer Science Fall 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 Science Fall 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 Science Fall 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 Science Fall 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 Science Fall 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 Science Fall 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 Science Fall 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 Science Fall 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 Science Fall 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 Science Fall 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 _