Practice session 5
This presentation is the property of its rightful owner.
Sponsored Links
1 / 30

Practice Session 5 PowerPoint PPT Presentation

  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

Practice Session 5

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



Collection Classes



Design by Contract

Test Driven Development


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



Java Packages

  • Declaration:

    • Declared at beginning of class file.

    • Syntax: package PackageName;

  • Example:

  • Folder: Package MyTest

    • Sub-folder: Package Outs1

      • File: Class

      • File: Class Print2java

    • Sub-folder: Package Outs2

      • File: Class


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:

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( ) ); //returns object } }



  • 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.

Practice session 5

PRINCIPLE 1: separate commands and queries


public void add( Object o );

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


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()

Practice session 5

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()

    • 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.

Call order of the functions

Call order of the functions

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

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(); [email protected](this)

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


void push(T obj);

Practice session 5


* 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 [email protected] Object}.

* @pre: none.

* @post: none.




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;


public void setUp() throws Exception {

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



public void tearDown() throws Exception {


Before -> run before each test

After-> run after each test

Practice session 5


public void testPush() {

fail("Not yet implemented");



public void testPop() {

fail("Not yet implemented");



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.

Practice session 5

  • 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….

  • Login