practice session 5 n.
Download
Skip this Video
Download Presentation
Practice Session 5

Loading in 2 Seconds...

play fullscreen
1 / 30

Practice Session 5 - PowerPoint PPT Presentation


  • 66 Views
  • Uploaded on

Practice Session 5. Java: Packages Collection Classes Iterators Generics Design by Contract Test Driven Development JUnit. Java Packages. What is Package? Way to group related class( es ) and interface(s) into one unit Package is basically a folder . Benefits? Code organization

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Practice Session 5' - isabel


Download Now An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
practice session 5

Practice Session 5

Java:

Packages

Collection Classes

Iterators

Generics

Design by Contract

Test Driven Development

JUnit

java packages
Java Packages
  • What is Package?
    • Way to group related class(es) and interface(s) into one unit
    • Package is basically a folder.
  • Benefits?
    • Code organization
      • All classes/interfaces related to one topic, are put under same package name.
    • Allows us to resolve conflicts between class names
      • By splitting the same name classes into two different packages.
    • Controlling class visibility
      • protected classes are visible to other classes inside the package only
      • Not visible to other packages, when imported.
java packages1

MyTest

Outs1

Print2.java

Print1.java

Java Packages
  • Declaration:
    • Declared at beginning of class file.
    • Syntax: package PackageName;
  • Example:
  • Folder: Package MyTest
    • Sub-folder: Package Outs1
      • File: Class Print1.java
      • File: Class Print2java
    • Sub-folder: Package Outs2
      • File: Class Print1.java

Outs2

Print1.java

java packages2
Java Packages
  • How to use them?
    • Use of absolute path of class:
      • Example: MyTest.Outs1.Print1 p1;
    • Using import keyword:
      • Import class:

import MyTest.Outs1.Print1;

      • Import all classes under package:

import MyTest.Outs1.*;

      • Object declaration: Print1 p1;
java collection
Java Collection
  • What is it?
    • A (huge)package of classes:
      • import java.util.Collection;
    • Contains useful data structures:
      • LinkedList
      • Stack
      • ArrayList
      • Vector
      • TreeSet
      • PriorityQueue
      • And much more…

Full API: http://docs.oracle.com/javase/6/docs/api/java/util/Collection.html

collection iterator
Collection Iterator
  • All java.util.Collection data structures return an iterator to their elements.
  • Iterator commands:
    • booleanhasNext()
      • Returns true if there is a next element
    • Object next()
      • Returns the next object element/advances the iterator
    • void remove()
      • Optional operator / not all iterators implement it
      • Removes the element returned by next
using the iterator
Using the Iterator
  • Example:
    • Print all Collection object elements:
  • Code:

static void printAll (Collection<Integer> coll) {Iterator<Integer>iter = coll.iterator( ); //returns iterator while (iter.hasNext( )) { //checks if has nextSystem.out.println(iter.next( ) ); //returns object } }

generics
Generics
  • What are they?
    • Generic data structures are data structures that allows the use of any object type.
    • Explicitly declare what object type the data structure is going to use upon declaration, to help finding errors at compilation time.
  • How?
    • java.util.Collection.Stack<Object-Type> stk;
  • Examples:
    • A Stack that holds Integer objects.
      • java.util.Stack<Integer> intStack;
    • A LinkedList holding Student objects:
      • java.util.Collection.LinkedList<Student> studentList;
generics example
Generics Example

Stack<Cow> stackOfCows = new Stack<Cow>()Stack<Float> stackOfFloat = new Stack<Float>()

Cow cow = new Cow()stackOfCows.push(cow);stackOfFloat.push(cow);

design by contract dbc
Design by Contract(DBC)
  • What?
    • An approach for designing software.
    • Expresses contract between specification and implementation.
    • An agreement between two parties: client and supplier.
  • Why?
    • Trustworthy documentation.
    • Strong support for debugging.
    • Facilitate code reuse.
  • Condition Types in DbC:
    • Preconditions
      • Things that must be true before invoking a method
      • No conditions on after invocation.
    • Postconditions
      • Things that must be true after invoking a method
      • No conditions on before invocation
    • Invariants
      • things that must be true before and after any method is invoked
      • Must be true immediatelyafterconstruction.
design by contract example
Design by Contract Example

public interface MyCollection {

/**

* Remove obj from the collection

*

* @require !( obj == null )

*

* @ensure !contains( obj )

*/

public void remove( Object obj );

Precondition disallows null argument.

Postconditionvarifies that method removes ALL occurrences of obj

/**

* @invariant size() >= 0

*/

public interface Queue {

Assures queue size >= 0 always!

design by contract principles
Design by Contract Principles
  • Separate queries from commands
  • Separate basic queries from derived queries.
  • For each derived query, write a postcondition that specifies what result will be returned, in terms of one or more basic queries.
  • For each command, write a postcondition that specifies the value of every basic query.
  • For every query and command, decide on a suitable precondition.
  • Write invariants to define unchanging properties of objects.
slide13

PRINCIPLE 1: separate commands and queries

Commands

public void add( Object o );

public void remove(); //just a command - no result

Queries

public int size();

public Object head();

public boolean isEmpty();

principle 2 separate basic queries and derived queries
PRINCIPLE 2: separate basic queries and derived queries

The choice of basic queries can change as we develop contracts

Basic queries

public int size();

public Object head();

Derived queries

public boolean isEmpty();

-- we can derive isEmpty() from size()

slide15

PRINCIPLE 3: specify derived queries in terms of basic queries

/**

* Is the queue empty?

*

* @ensure return == ( size() == 0 )

*/

public booleanisEmpty();

-- if we know the value of size(), we also know

-- the value of isEmpty()

principle 4 specify postcondition for commands in terms of basic queries
PRINCIPLE 4: specify postcondition for commands in terms of basic queries

/**

* The first element in the queue

*

* @require size() >= 1

* @ensure return == elements().get(0)

*/

public Object head();

postcondition uses basic query .get() for its implementation

principle 5 add preconditions where appropriate
PRINCIPLE 5: add preconditions where appropriate

/**

* The first element in the queue

*

* @require size() >= 1

*/

public Object head();

It wouldn’t make the software better

to pretend that an empty queue has

a head element.

principle 6 specify invariant properties
PRINCIPLE 6: specify invariant properties

/**

* @invariant size() >= 0

*/

public interface Queue {

Aim for properties that:

- help readers build correct conceptual model

test driven development tdd
Test Driven Development (TDD)
  • What?
    • Test cases are first implemented and only then the code necessary to pass these tests are implemented.
  • Why?
    • Code is ensured to be working perfectly without any bugs!
  • Main tool in java: JUnit
junit assert methods
Junit - Assert methods
  • Each assert method has parameters like these: message, expected-value, actual-value
    • assertTrue(String message, Boolean test)
    • assertFalse(String message, Boolean test)
    • assertNull(String message, Object object)
    • assertNotNull(String message, Object object)
    • assertEquals(String message, Object expected, Object actual) (uses equals method)
    • assertSame(String message, Object expected, Object actual) (uses == operator)
    • assertNotSame(String message, Object expected, Object actual)
  • Assert methods dealing with floating point numbers get an additional argument, a tolerance. (for rounding)
  • Each assert method has an equivalent version that does not take a message – however, this use is not recommended because:
    • messages helps documents the tests
    • messages provide additional information when reading failure logs
setup teardown
setUp/tearDown
  • setUp()/tearDown()
    • Functions which will run before and after each test.
    • Example usage:
      • setUp(): creating new objects
      • tearDown(): clearing data, resetting data.
        • If self destruction is good enough, there is no need to implement it.
  • setUpBeforeClass()/tearDownBeforeClass()
    • functions which will run exactly once before and after all the tests.
    • Can be used to initialize objects which will be used throughout the tests.
    • Changes done in first test, can be used as input data for the upcoming one.
junit tests for counter class
JUnit tests for Counterclass
  • public class CounterTest { Counter counter1; public CounterTest() { } // default constructor
  • @Before protected void setUp() { // creates a (simple) test fixture counter1 = new Counter(); }
  • @Test public void testIncrement() {assertTrue(counter1.increment() == 1);assertTrue(counter1.increment() == 2); }
  • @Test public void testDecrement() {assertTrue(counter1.decrement() == -1); }}

Note that each test begins with a brand new counter

This means you don’t have to worry about the order in which the tests are run

test driven development cycle
Test Driven Development Cycle
  • Write the tests and for each Object Under Test (OUT):
    • Define interface
    • Define contract for each method
    • Specify invariant for the object, and for each method, pre and post-conditions.
  • Write the code so it will pass the test
  • Run tests
  • Refactor!
    • Improve the code, more efficient, less repetition, better looking..
  • Repeat

http://www.thecoadletter.com

junit example
Junit - Example
  • Interface:

package spl.util;

/**

* All objects are of type T. Contents are ordered in Last-In-First-Out order.

*/

public interface Stack<T> {

/**

* add the object at the top of the stack. (This is a command.)

* @paramobj

* any non null T object to be added to the stack

* @pre: none.

* @post: this.isEmpty()==false

* @post: this.pop(); this==@pre(this)

* @post: this.pop()== @paramobj

*/

void push(T obj);

slide26

/**

* remove the top object from the stack and returns it.

* @return the topmost object on the stack

* @throws Exception in case the stack is empty

* @pre: this.isEmpty()== false;

* @post: none.

*/

T pop() throws Exception;

/**

* @return True if the Stack is empty, or False if the Stack contains at

* least one {@link Object}.

* @pre: none.

* @post: none.

*/

booleanisEmpty();

}

create class stackimpl
Create Class StackImpl

package spl.util;

public class StackImpl<T> implements Stack<T> {

public void push(T obj) {

}

public T pop() throws Exception {

return null;

}

public booleanisEmpty() {

return false;

}

}

creating a test case
Creating a Test Case

package spl.util;

import static org.junit.Assert.*;

import org.junit.After;

import org.junit.Before;

import org.junit.Test;

public class StackImplTest {

Stack<Integer> stack;

@Before

public void setUp() throws Exception {

this.stack = new StackImpl<Integer>();

}

@After

public void tearDown() throws Exception {

}

Before -> run before each test

After-> run after each test

slide29

@Test

public void testPush() {

fail("Not yet implemented");

}

@Test

public void testPop() {

fail("Not yet implemented");

}

@Test

public void testIsEmpty() {

assertEquals(true, stack.isEmpty());

}

}

  • What happens when we run the tests?
  • All 3 tests fail:
  • testPush and testPop because the methods are not implemented.
  • testIsEmpty since isEmpty returns false, even though the stack is empty.
slide30

Add implementation to isEmpty() to pass the tests.

  • Implement other tests and add the implementation of the methods they test to pass them.
  • Change the interface to include public void remove() and public T top() in addition to pop(), and implement pop() using remove and top, to separate queries from commands.
  • And so on….