ITEC324 Principle of CS III

Slides:



Advertisements
Similar presentations
Chapter 17 Failures and exceptions. This chapter discusses n Failure. n The meaning of system failure. n Causes of failure. n Handling failure. n Exception.
Advertisements

Exceptions CSE301 University of Sunderland Harry Erwin, PhD.
11-Jun-14 The assert statement. 2 About the assert statement The purpose of the assert statement is to give you a way to catch program errors early The.
1. Define the concept of assertions. 1 Explain the use of assertions. 2 Create Java program using assertions. 3 Run Java program using assertions. 4 2.
Practice Session 5 Java: Packages Collection Classes Iterators Generics Design by Contract Test Driven Development JUnit.
J-Unit Framework.
 Both System.out and System.err are streams—a sequence of bytes.  System.out (the standard output stream) displays output  System.err (the standard.
Chapter 8 Designing Classes. Assignment Chapter 9 Review Exercises (Written)  R8.1 – 8.3, 8.5 – 8.7, 8. 10, 8.11, 8.13, 8.15, 8.19, 8.20 Due Friday,
Chapter 3 (Horstmann’s Book) Guidelines for Class Design Hwajung Lee.
Software Testing and Quality Assurance
1 TCSS 360, Spring 2005 Lecture Notes Programming by Contract: Pre/Postconditions, Invariants and Assertions Relevant Reading: Object-Oriented Design and.
© 2006 Pearson Addison-Wesley. All rights reserved4-1 Chapter 4 Data Abstraction: The Walls.
Copyright 2006 by Pearson Education 1 Building Java Programs Chapter 8: Classes and Objects.
Information Hiding and Encapsulation
1 Class design guidelines. 2 Encapsulation Classes can be implemented many different ways –each has advantages & disadvantages –improvement/revision always.
CS 2511 Fall  Abstraction Abstract class Interfaces  Encapsulation Access Specifiers Data Hiding  Inheritance  Polymorphism.
CPSC 2100 University of Tennessee at Chattanooga – Fall 2013 Object-Oriented Design & Patterns 2 nd edition Cay S. Horstmann Chapter 3: Guidelines for.
Ranga Rodrigo. Class is central to object oriented programming.
Unit Testing & Defensive Programming. F-22 Raptor Fighter.
Classes and Class Members Chapter 3. 3 Public Interface Contract between class and its clients to fulfill certain responsibilities The client is an object.
Liang, Introduction to Java Programming, Seventh Edition, (c) 2009 Pearson Education, Inc. All rights reserved Chapter 18 Exception Handling.
Assertions Program correctness. Assertions Java statement – enables you to assert an assumption about your program. – An assertion contains a Boolean.
1 Assertions. 2 assertions communicate assumptions about the state of the program, and stop processing if they turn out to be false very often comments.
LinkedList Many slides from Horstmann modified by Dr V.
Guidelines for class design Horstmann ch Noter ch.1.1.
CSC1401 Classes - 2. Learning Goals Computing concepts Adding a method To show the pictures in the slide show Creating accessors and modifiers That protect.
Chapter 3 Guidelines for Class Design. Objective of this chapter Have “bottom up point of view” Learn how to write a single class well.  The classes.
Pre- and postconditions, Using assertions and exceptions 1 Pre- and postconditions Using assertions and exceptions.
Chapter 3 Introduction to Classes and Objects Definitions Examples.
CreatingClasses-SlideShow-part31 Creating Classes part 3 Barb Ericson Georgia Institute of Technology Dec 2009.
Computer Science 209 Software Development Handing Errors and Creating Documentation.
More Java: Static and Final, Abstract Class and Interface, Exceptions, Collections Framework 1 CS300.
PROGRAMMING PRE- AND POSTCONDITIONS, INVARIANTS AND METHOD CONTRACTS B MODULE 2: SOFTWARE SYSTEMS 13 NOVEMBER 2013.
Access Specifier. Anything declared public can be accessed from anywhere. Anything declared private cannot be seen outside of its class. When a member.
The Java Assertion. 2 Assertion A Java statement in JDK 1.4 & newer Intent: enables code to test assumptions. E.g., a method that calculates the a particle’s.
CS 151: Object-Oriented Design September 17 Class Meeting Department of Computer Science San Jose State University Fall 2013 Instructor: Ron Mak
CSE 501N Fall ‘09 10: Introduction to Collections and Linked Lists 29 September 2009 Nick Leidenfrost.
 Description of Inheritance  Base Class Object  Subclass, Subtype, and Substitutability  Forms of Inheritance  Modifiers and Inheritance  The Benefits.
CSE 374 Programming Concepts & Tools Hal Perkins Fall 2015 Lecture 17 – Specifications, error checking & assert.
ITEC324 Principle of CS III
Guidelines for Class Design
External Scope CECS 277 Mimi Opkins.
Modern Programming Tools And Techniques-I
Chapter 13 Exception Handling
Data Abstraction: The Walls
Java and OOP Part 5 – More.
Chapter 6 CS 3370 – C++ Functions.
Objects as a programming concept
Logger, Assert and Invariants
CSE 374 Programming Concepts & Tools
Exceptions, Interfaces & Generics
University of Central Florida COP 3330 Object Oriented Programming
Computer Science 209 Testing With JUnit.
Chapter Three - Implementing Classes
Object Based Programming
Software Construction
CSC 480 Software Engineering
Abstract Class As per dictionary, abstraction is the quality of dealing with ideas rather than events. For example, when you consider the case of ,
Defining Classes and Methods
Test Driven Development
Test Driven Development
CSE 143 Lecture 5 More ArrayIntList:
CS 112 Programming 2 Lecture 02 Abstract Classes & Interfaces (2)
CMPE 135: Object-Oriented Analysis and Design February 21 Class Meeting Department of Computer Engineering San Jose State University Spring 2019 Instructor:
Barb Ericson Georgia Institute of Technology Oct 2005
Computer Science 340 Software Design & Testing
Chapter 11 Inheritance and Encapsulation and Polymorphism
Review for Midterm 3.
Software Construction
CS 240 – Advanced Programming Concepts
Presentation transcript:

ITEC324 Principle of CS III Chapter 3 (Horstmann’s Book) Guidelines for Class Design Hwajung Lee ITEC324 Principle of CS III

Objective of this chapter Have “bottom up point of view” Learn how to write a single class well.  The classes will Be useful Be reusable Increased pride and satisfaction for you, the designer.

Quality of Class Interface Customers: Programmers using the class Criteria: (5Cs) Cohesion Completeness Convenience Clarity Consistency

Cohesion A class is an abstraction of a single concept. A class is cohesive if all of its methods are related to a single abstraction. Methods should be related to the single abstraction Bad example: public class Mailbox { public addMessage(Message aMessage) { ... } public Message getCurrentMessage() { ... } public Message removeCurrentMessage() { ... } public void processCommand(String command) { ... } ... }

Completeness A class interface should support all operations that are a part of the abstraction that the class represents. Potentially bad example: Date start = new Date(); // do some work Date end = new Date(); //How many milliseconds have elapsed?  No such operation in Date class Does it fall outside the responsibility? After all, we have before, after, getTime

Convenience A class should be convenient to use. A good interface makes all tasks possible . . . and common tasks simple. Bad example: Reading from System.in BufferedReader in = new BufferedReader (new InputStreamReader (System.in)); Name = in.readLine(); Why didn't System.in have a readLine method?

Clarity (1) A class interface should be clear to understand to programmers. Confused programmers write buggy code Bad example: Removing elements from LinkedList LinkedList countries = new LinkedList(); countries.add("A"); countries.add("B"); countries.add("C"); ListIterator iterator = countries.listIterator(); while (iterator.hasNext()) System.out.println(iterator.next()); 

Clarity (2) iterator.remove(); //A|BC Iterator between elements is like blinking cursor in a word processor. Thus, if X is added before B: ListIterator iterator = countries.listIterator(); // |ABC iterator.next(); // A|BC iterator.add("France"); // AX|BC Then, to remove first two elements, you can't just "backspace." The remove() method does not remove element to the left of the iterator. Will the following work? iterator.remove(); //A|BC iterator.remove(); //|BC

Clarity (3) In fact, void remove() from API documentation says: Removes from the list the last element that was returned by next or previous. This call can only be made once per call to next or previous. It can be made only if add has not been called after the last call to next or previous.  http://java.sun.com/j2se/1.5.0/docs/api/java/util/ListIterator.html#remove() http://java.sun.com/docs/books/tutorial/ Huh?

Consistency (1) The operations in a class should be consistent with each other with respect to names parameters return values behavior Bad example: new GregorianCalendar(year, month - 1, day) Why is month 0-based?

Consistency (2) Bad example: String class s.equals(t) or s.equalsIgnoreCase(t) But boolean regionMatches(int toffset, String other, int ooffset, int len) boolean regionMatches(boolean ignoreCase, int toffset, String other, int ooffset, int len) Why not regionMatchesIgnoreCase?

Recap (5Cs) Cohesion Completeness Convenience Clarity Consistency

Law of Demeter A method should only use objects that are instance fields of its class parameters objects that it constructs with new A method shouldn't use an object that is returned from a method call

Programming by Contract Spell out responsibilities of caller  of implementer Increase reliability Increase efficiency

Programming by Contract We will look through the ideas on Preconditions Postconditions Exceptions in the Contract Class Invariants Assertions

Preconditions (1) A precondition of a method is a condition that must be fulfilled before the method may be called. Is a condition that the method caller must fulfill.

Preconditions (2) Why do we need to define preconditions? Excessive error checking is costly Returning dummy values can complicate testing Contract metaphor Service provider must specify preconditions If precondition is fulfilled, service provider must work correctly. Otherwise, service provider can do anything When precondition fails, service provider may throw exception return false answer corrupt data

Preconditions (3) Example: /** Remove message at head @return the message at the head @precondition size() > 0 */ Message removeFirst() { return (Message)elements.remove(0); }

Preconditions (4) What is better? (Ex) What should happen if a programmer attempts to remove a message from an empty queue? What is better? MessageQueue can declare this as an error MessageQueue can tolerate call and return dummy value

Postconditions A postcondition of a method is a condition that holds after the method has completed is a conditions that the service provider (the method developer) guarantees In Java doc, you can use @return or @postcondition to represent a postcondition. Example: add() method @postcondition size() > 0 Postcondition of one call can imply precondition of another: q.add(m1); m2 = q.remove(); 

Exceptions in the Contract Exception throw is not an error. It is a part of the contract Example: /** . . . @throws IllegalArgumentException if queue is empty */ public Message removeFirst() { if (count == 0) throw new IllegalArgumentException(); Message r = elements[head]; . . . }

Class Invariants (1) A class invariant is a logical condition that is true after every constructor preserved by every mutator (if it's true before the call, it's again true afterwards) Useful for checking validity of operations

Class Invariants (2) Example: Circular array queue (Ch2/mail/MessageQueue.java) 0 <= head && head < elements.length First check it's true for constructor Sets head = 0 Need precondition size() >= 0 Check mutators. Start with removeFirst() Sets headnew = (headold + 1) % elements.length We know headold + 1> 0 (Why?)  % operator property: 0 <= headnew && headnew < elements.length What's the use of a class invariant? Every array access of the form element[head] is legal!

Assertions (1) An assertions: is a condition that a programmer expects to be true is a mechanism for warning programmers Useful for warning programmers about precondition failure can be turned off after testing Syntax: assert condition; assert condition : explanation; Throws AssertionError if condition false and checking enabled

Assertions (2) Example: public Message removeFirst() { assert count > 0 : "violated precondition size() > 0"; Message r = elements[head]; . . . } How to execute the assertion: During testing, run with java -enableassertions MyProg or Java -ea MyProg

Unit Testing Unit test = test of a single class How to test? Design test cases during implementation Run tests after every implementation change When you find a bug, add a test case that catches it Download the JUnit tool http://junit.sourceforge.net/ http://junit.sourceforge.net/doc/faq/faq.htm

JUnit (1)

JUnit (2) Test class name = tested class name + Test A name of a test method starts with test Example: import junit.framework.*; public class DayTest extends TestCase { public void testAdd() { ... } public void testDaysBetween() { ... } . . . }

JUnit (3) Each test case ends with assertion. Test framework catches assertion failures Example: public void testAdd() { Day d1 = new Day(1970, 1, 1); int n = 1000; Day d2 = d1.addDays(n); assert d2.daysFrom(d1) == n; }

JUnit (4) Day.java DayTest.java Compiling Run javac –classpath .:junit.jar DayTest.java Run java –classpath .:junit.jar –ea junit.swingui.TestRunner DayTest

JUnit (5)

Encapsulation using Private, Public, or Protected: public: a field, method, or class that is accessible to every class. protected: a field, method, or class that is accessible to the class itself, subclasses, and all classes in the same package or directory. private: a field or method that is accessible only to the class in which it is defined. Note that a class can not be declared private as a whole. Encapsulation using Private, Public, Friendly, or Protected: These are always asked in an interview!!! public: a field, method, or class that is accessible to every class. protected: a field, method, or class that is accessible to the class itself, subclasses, and all classes in the same package or directory. friendly: a field, method, or class that is accessible to the class itself and to all classes in the same package or directory. Note that friendly is not a separate keyword. A field or method is declared friendly by virtue of the absence of any other access modifiers. private: a field or method that is accessible only to the class in which it is defined. Note that a class can not be declared private as a whole. Question: Write a class containing a private, public, and friendly field. Then try to access these fields from another class? We need to write two classes: one class with various fields, and a second class to attempt to access these fields. Class AccessTest { // declare each of the fields private int privateNum = 1; public int publicNum = 3; int friendlyNum = 4; } class Tester { // instantiate a methods public static void main(String args[]) { AccessTest a = new AccessTest(); System.out.println(a.privateNum); System.out.println(a.friendlyNum); System.out.println(a.publicNum); } } Variable privateNum in class AccessTest not accessible from class Tester. Good Luck!