SE450: Lecture 1 (Basics)

Course: SE450 (Object-Oriented Software Development)

Instructor: James Riely

• Overview of the course
• Adminstrative information
• Objects, classes and their representation in the UML.
  • Functions
  • Static classes
  • Object classes
  • Relations between classes
• Object class taxonomy
  • Data classes
  • Builder classes
  • Collection classes
• Writing tests
• Homework 1

What is this course about?

Programming in the large.

• Programming in the small: client is end-user.
• Programming in the large: client is another programmer.
  • With maintenance, addition of functionality, you may be a client for yourself.
  • Ever look at code you wrote a year ago?
  • Producer/Consumer relation may be cyclic.

This course teaches management of the producer/consumer relationship, emphasizing code structure.

Course homepage: http://fpl.cs.depaul.edu/jriely/450/

• Lecture slides are available in two HTML formats: one slide per page and all slides on one page.
• Lecture slides may not be available before the class.
• Lecture slides may change after class.

http://groups.google.com/group/se450fall2015

• I will reply to messages I receive to the course mailing list.
• The mailing list is archived.
• If you do not wish to receive messages, you may unsubscribe, or subscribe to a digest.

If you want advice about an error, send me email, doing one of the following.

• Include a screenshot showing the error.

• Copy and paste the EXACT TEXT of the error into your email message.

  • Include the code that caused the error, with enough context to understand it
  • Make sure that you clearly indicate the line with the error.

If you have a problem getting a program to work and you want me to look at some of your code in more detail, send me email with the following three things.

1. Your java file as an attachment.

2. A description of how the output of the program is different from what you expected.

3. The output of your program, if it runs.

   • Include in the screenshot, or
   • Copy and poste from the eclipse console

93-100 = A
90-92  = A-
88-89  = B+
83-87  = B
80-82  = B-        
etc...

DePaul's academic integrity policy

http://www.cdm.depaul.edu/onlinelearning/Pages/OnlinePolicies.aspx

If you live in Chicago, you can take the exams at the Loop or Suburban campuses. If you live outside the Chicago area, you will need to find a proctor.

Your online section is paired with an on-campus section. These classes are recorded and uploaded into the Course Management system so you can view them within 24 hours of the live class. The first class is 2015/09/15. The lecture will be available online the following day.

This course requires that you complete a project.

The project must be your work alone.

Project work begins after the midterm.

My coordinates:

• I work at home some days. (Generally I am in the office on days I teach and on Fridays.)

Contact by phone:

• I do not often check voice-mail.

Contact by email:

• I check email about twice a day.
• It may take as long as a few days for me to reply to mail.
• Please check that the email address on your CampusConnect record is correct.

See file:links-main.

Required Books

Object-Oriented Design and Patterns (2e) [Amazon, AddAll] by Cay Horstmann (Wiley, 2005) Online companion to the book: http://horstmann.com/design_and_patterns.html

Java2SE API (Online)

Java Tutorial (Online)

Required Books (Pick one of the following three)

Head First Design Patterns [Amazon, AddAll] by Eric Freeman, Elisabeth Freeman, Kathy Sierra, Bert Bates (O'Reilly, 1995) ADD intro to DP. Online companion to the book: http://www.oreilly.com/catalog/hfdesignpat/

Design Patterns Explained: A New Perspective on Object-Oriented Design (2e) [Amazon, AddAll] by Alan Shalloway, James R. Trott (Addison-Wesley, 2004) Online companion to the book. Design Patterns Matrix. Pearson site.

Design Patterns [Amazon, AddAll] by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides (Addison-Wesley, 1995) Online companion to the book: http://hillside.net/elements-of-reusable-object-oriented-software-book

Most students prefer Head First Design Patterns, but some prefer Design Patterns Explained. The original Design Patterns is a classic, but out of date; it is a decent reference, but a poor book to learn from for a begginer.

Life is much better with tools.

The big four:

• Program editor. For example, textpad or eclipse.
• Automated build tool. For example, ant or make.
• Automated testing tool. For example, junit or related xunit tools.
• Versioning system. For example, GIT or Microsoft sourcesafe.

See here for notes on installing eclipse and related tooles.

We will discuss subclassing after the midterm.

For now, all classes we write will be direct subclasses of java.lang.Object

Several logical steps

1. Compile -- may compile pieces of program separately, creating multiple object files and "libraries" or "archives" ("jar" file)
2. (Static linking and initialization)
3. Load program into memory
4. Dynamic linking and initialization
5. Run

The first two steps are static -- happen at compile time.

The last three steps are dynamic -- happen at runtime.

Java loads and initializes classes dynamically.

General rule: (load and) initialize class when first needed.

file:Main.java [source] [doc-public] [doc-private]

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 package basics.classLoading; public class Main { private Main() {} // The following is a static initializer. // It will execute the first time a class is used. static { System.out.println("Main initialized"); } static public void main (String[] args) { System.out.print("1. "); C.f(); System.out.print("2. "); C.f(); System.out.print("3. "); D.g(); System.out.print("4. "); D.g(); } } class C { private C() {} static { System.out.print("C initialized; "); } static void f() { System.out.println("C.f()"); } } class D { private D() {} static { System.out.print("D initialized; "); } static void g() { System.out.println("D.g()"); } }

Main initialized
1. C initialized; C.f()
2. C.f()
3. D initialized; D.g()
4. D.g()

What is a function?

file:Main.java [source] [doc-public] [doc-private]

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 package basics.functions; public class Main { private Main() {} static public void main (final String[] args) { //stdlib.Trace.graphvizShowSteps (true); stdlib.Trace.run (); Fun.f(); Fun.g(2); } } class Fun { private Fun() {} static void f() { System.out.println("Fun.f()"); } static void g(final int x) { System.out.println("Fun.g(" + x + ")"); if (x>0) { final int y = x-1; Fun.g(y); } } }

Here is a visualization of the execution at four different point (time moving from left to right).

Fun.f()
Fun.g(2)
Fun.g(1)
Fun.g(0)

        <p>
          Here is an ascii-art version of the third timestep shown.
        </p>          
+---------------------+   +-----------------+   +-----------------+
|  1 : Main.main ARI  |   |  2 : Fun.g ARI  |   |  3 : Fun.g ARI  |
|  -----------------  |   |  -------------  |   |  -------------  |
+---------------------+   +-----------------+   +-----------------+
                          |  x:int = 2      |   |  x:int = 1      |
                          |  y:int = 1      |   |  y:int = 0      |
                          +-----------------+   +-----------------+

Each function call (or activation) creates an instance of the function variables (including parameters).

The variables are stored in an activation record instance (ARI).

The period from activation to return is the lifetime of the ARI.

• Memory is allocated by the system at birth
• Memory is returned to the system at death

We can draw ARI's, including an instance number to distinguish them.

What is an object?

Basic idea: an object is something that may respond to a message.

Further: an object may have state.

The state of the object may be used in generating a reponse to a message.

If an object is mutable, its response may vary over time.

Example: a printer queue.

Curious fact: in a java program, there is no direct way to describe an object.

Java is class-based.

• Classes are described directly.
• Objects are instances of classes.

Most OO-languages are class based -- descendents of simula and smalltalk.

Prototype-based languages work differently.

Let's distinguish two types of classes:

• object classes are instantiable -- they are templates for stamping objects
• static classes are not instantiable -- they are collections of functions

file:Main1.java [source] [doc-public] [doc-private]

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 package basics.objectclass; // A static class public class Main1 { private Main1() {} static public void main (String[] args) { //stdlib.Trace.graphvizShowSteps (true); stdlib.Trace.run (); Circle1 c = new Circle1(1); String s = ((c==null) ? "null" : c.toString()); System.out.println(s); } } // An object class final class Circle1 extends Object { final int radius; public Circle1(int radius) { super(); this.radius = radius; } public String toString() { return "Circle(" + radius + ")"; } }

Java allows some shorthand.

The following declaration is equivalent to the one above.

file:Main2.java [source] [doc-public] [doc-private]

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 package basics.objectclass; // A static class public class Main2 { private Main2() {} static public void main (String[] args) { //stdlib.Trace.graphvizShowSteps (true); stdlib.Trace.run (); System.out.println(new Circle2 (1)); } } // An object class final class Circle2 extends Object { int radius; public Circle2(int radius) { this.radius = radius; } public String toString() { return "Circle(" + radius + ")"; } }

Important: compilers add/remove local variables as they wish (that are not parameters). Some locals get mapped to addresses on the stack and some to registers.

Do not optimize local variables for performance!

Object classes have three kinds of members:

• Constructors specify how to build objects inhabiting the class.
• Methods specify how the object responds to messages.
• Fields specify the state of the object.

file:Main3.java [source] [doc-public] [doc-private]

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 package basics.objectclass; // A static class public class Main3 { private Main3() {} static public void main (String[] args) { //stdlib.Trace.graphvizShowSteps (true); stdlib.Trace.run (); Circle3[] list = new Circle3[3]; for (int i = 0; i < list.length; i++) list[i] = new Circle3 (i*10); for (Circle3 c : list) System.out.println(c); } } // An object class final class Circle3 extends Object { int radius; public Circle3(int radius) { this.radius = radius; } public String toString() { return "Circle(" + radius + ")"; } }

An object diagram is a snapshot of a running system, showing live objects.

Here are the ARIs when executing Circle.toString:

+---------------------+   +---------------------------+
|  0 : Main.main ARI  |   |  1 : Circle.toString ARI  |
|  -----------------  |   |  -----------------------  |
+---------------------+   +---------------------------+
|  c:Circle = c0      |   |  this:Circle = c0         |
|  s:String = null    |   +---------------------------+
+---------------------+

Note the difference between the ARIs.

The ARI for toString has a special variable, this, which identifies the object receiving the message.

This is the main difference between a static method and a non-static method.

Fields can be used to distinguish different objects of a class.

file:Main.java [source] [doc-public] [doc-private]

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 package basics.fields; public class Main { private Main() {} static public void main (String[] args) { //stdlib.Trace.graphvizShowSteps (true); stdlib.Trace.run (); Int x = new Int(42); Int y = new Int(27); System.out.println(x); System.out.println(y); } } final class Int { private final int v; public Int(int v) { this.v = v; } public String toString() { return "Int(" + v + ")"; } }

The object diagram at line 00008 is:

+--------------+   +--------------+      +---------------------+
|   i0 : Int   |   |   i1 : Int   |      |  0 : Main.main ARI  |
|   --------   |   |   --------   |      |  -----------------  |
+--------------+   +--------------+      +---------------------+
|   v:int = 42 |   |   v:int = 27 |      |  x:Int = i0         |
+--------------+   +--------------+      |  y:Int = i1         |
                                         +---------------------+

It is traditional in the UML to show objects, but not ARIs.

This can be confusing.

Although the names given to objects are arbitrary, perhaps the following are more helpful:

+--------------+   +--------------+
|    x : Int   |   |    y : Int   |
|    -------   |   |    -------   |
+--------------+   +--------------+
|   v:int = 42 |   |   v:int = 27 |
+--------------+   +--------------+

Unfortunately, this convention is not always more helpful.

What does the following print?

file:Main.java [source] [doc-public] [doc-private]

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 package basics.swap; public class Main { private Main() {} static public void main (String[] args) { //stdlib.Trace.graphvizShowSteps (true); stdlib.Trace.showBoxedPrimitivesAsPrimitive(false); stdlib.Trace.run (); Integer x = 42; Integer y = 27; Main.swap(x,y); System.out.println(x); System.out.println(y); } static private void swap (Integer a, Integer b) { Integer t = a; a = b; b = t; } }

What does the following print?

file:Main.java [source] [doc-public] [doc-private]

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 package basics.swap; public class Main { private Main() {} static public void main (String[] args) { //stdlib.Trace.graphvizShowSteps (true); stdlib.Trace.showBoxedPrimitivesAsPrimitive(false); stdlib.Trace.run (); Integer x = 42; Integer y = 27; Main.swap(x,y); System.out.println(x); System.out.println(y); } static private void swap (Integer a, Integer b) { Integer t = a; a = b; b = t; } }

Java is call-by-value.

Call by Value Links

Cup Size -- a story about variables by JavaRanch.

Pass-by-Value Please By JavaRanch.

Does Java pass by reference or pass by value? Why can't you swap in Java? By Tony Sintes.

   +--------------+   +--------------+   
   | i0 : Integer |   | i1 : Integer |   
   | ------------ |   | ------------ |   
   +--------------+   +--------------+   
   |   v:int = 42 |   |   v:int = 27 |   
   +--------------+   +--------------+   
                                       
+-----------------+   +-----------------+
|  0 : Main.main  |   |  1 : Main.swap  |
|  -------------  |   |  -------------  |
+-----------------+   +-----------------+
|  x:Integer = i0 |   |  a:Integer = i1 |
|  y:Integer = i1 |   |  b:Integer = i0 |
+-----------------+   |  t:Integer = i0 |
                      +-----------------+

42
27

Java has a reference model for objects. This is like C# are different from C++. In C# terminology, Java objects are boxed, whereas base values are unboxed.

What does the following print?

file:Main.java [source] [doc-public] [doc-private]

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 package basics.valref; public class Main { private Main() {} static public void main (String[] args) { //stdlib.Trace.graphvizShowSteps (true); stdlib.Trace.run (); int vi = 27; MutInt ri = new MutInt(42); int vj = vi; MutInt rj = ri; vi += 1; ri.plus(1); System.out.println(vi); System.out.println(vj); System.out.println(ri); System.out.println(rj); } } final class MutInt { private int v; public MutInt(int v) { this.v = v; } public String toString() { return "MutInt(" + v + ")"; } public void plus(int z) { v += z; } }

Java has a reference model for objects. This is like C# are different from C++. In C# terminology, Java objects are boxed, whereas base values are unboxed.

What does the following print?

file:Main.java [source] [doc-public] [doc-private]

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 package basics.valref; public class Main { private Main() {} static public void main (String[] args) { //stdlib.Trace.graphvizShowSteps (true); stdlib.Trace.run (); int vi = 27; MutInt ri = new MutInt(42); int vj = vi; MutInt rj = ri; vi += 1; ri.plus(1); System.out.println(vi); System.out.println(vj); System.out.println(ri); System.out.println(rj); } } final class MutInt { private int v; public MutInt(int v) { this.v = v; } public String toString() { return "MutInt(" + v + ")"; } public void plus(int z) { v += z; } }

Consider the object diagram after line 00007:

   +--------------+      +-----------------+
   | i0 : MutInt  |      |  0 : Main.main  |
   | ------------ |      |  -------------  |
   +--------------+      +-----------------+
   |   v:int = 42 |      | vi:int = 27     |
   +--------------+      | vj:int = 27     |
                         | ri:MutInt = i0  |
                         | rj:MutInt = i0  |
                         +-----------------+

This phenomenon is called aliasing.

Note that aliasing occurs whenever an object is passed as an argument to a function.

Aliasing mutable values must be handled with care.

28
27
MutInt(43)
MutInt(43)

In the UML, references are usually shown using arrows.

Instead of this:

   +--------------+       +-----------------+
   | i0 : MutInt  |       |  0 : Main.main  |
   | ------------ |       |  -------------  |
   +--------------+       +-----------------+
   |   v:int = 42 |       | vi:int = 27     |
   +--------------+       | vj:int = 27     |
                          | ri:MutInt = i0  |
                          | rj:MutInt = i0  |
                          +-----------------+

We draw this:

   +--------------+       +-----------------+
   | i0 : MutInt  |   ri  |  0 : Main.main  |
   | ------------ | <---- |  -------------  |
   +--------------+   rj  +-----------------+
   |   v:int = 42 | <---- | vi:int = 27     |
   +--------------+       | vj:int = 27     |
                          +-----------------+

   +----------------+
   |   <<static>>   |
   |      Main      |
   +----------------+  
   | + main():void  |
   | -------------  |
   +----------------+

• The class name is not underlined
• Static methods are underlined
• <<static>> is a stereotype
• Method return type follows colon
• May contain static fields, which are also underlined (none shown here)

   +---------------------+
   |       MutInt        |
   +---------------------+
   | - v:int             |
   +---------------------+
   | + MutInt()          |
   | + toString():String |
   | + plus(int):void    |
   +---------------------+

• The class name is not underlined
• Non-static methods are not underlined
• Fields are listed first, methods second
• - is private
• + is public

A static class describes the class itself.

An object class describes the instances of the class.

file:Person.java [source] [doc-public] [doc-private]

01 02 03 04 05 06 07 package basics.aggregation; final class Person { //stdlib.Trace.graphvizShowSteps (true); stdlib.Trace.run (); final private String name; public Person(String name) { this.name = name; } public String toString() { return "Person(" + name + ")"; }; }

Reference to objects of another class:

   +--------+   name  +--------+
   | Person |<>------>| String |
   +--------+         +--------+

In UML, this is called aggregation.

Note that the aggregation refers to the instances of the class, not the class itself.

Class diagrams are static (describe the program text).

file:Person.java [source] [doc-public] [doc-private]

01 02 03 04 05 06 07 08 09 package basics.composition; import java.util.Random; final class Person { static private Random random = new Random(); final private String name; public Person() { name = Integer.toString(random.nextInt()); } //public Person(String name) { name = name.clone(); } public String toString() { return "Person(" + name + ")"; }; }

Exclusive reference to objects of another class:

   +--------+    name  +--------+
   | Person |<@>------>| String |
   +--------+          +--------+

In UML, this is called composition.

Consequences of composition:

• When the person dies, the name dies too
• Name can only be accessed through the person

(Yuck! We've mixed static and non-static members!)

file:Person.java [source] [doc-public] [doc-private]

01 02 03 04 05 06 07 08 09 10 11 12 13 14 package basics.dependency; import java.util.Random; final class Person { final private String name; public Person(String name) { this.name = name; } public String toString() { return "Person(" + name + ")"; }; } class PersonFactory { private PersonFactory() {} static private Random random = new Random(); static public Person randomPerson() { return new Person(Integer.toString(random.nextInt())); } }

   +---------------+
   |   <<static>>  |   <<creates>>   +--------+
   | PersonFactory |- - - - - - - - >| Person |
   +---------------+                 +--------+

This dependency indicates that PersonFactory mentions Person, but holds no references to Person objects.

Typical reasons for a dependency:

• Person is returned by method
• Person is a parameter of a method
• Person is held in a local variable, but not a field

The dichotomy between static-class and object-class is not enforced in java.

Guideline: separate static and object functions into different classes

Example: java.lang.Math is a static class; java.util.Random is an object class.

Note: this guideline is often violated in the java APIs. For example: java.lang.String and all the wrapper classes, such as java.lang.Integer.

It is useful to think of a mixed class in terms of its two functions:

• Static members belong to the class, eg, Integer.MAX_VALUE:int and Integer.parseInt(String):int.

  Access these members using the class name.

• Non-static members belong to the objects, eg, Integer.hashCode():int.

  Access these members using an object reference -- this is the only way you can!

file:Main.java [source] [doc-public] [doc-private]

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 package basics.mixedclass; public class Main { private Main() {} static public void main (final String[] args) { //stdlib.Trace.graphvizShowSteps (true); stdlib.Trace.run (); try { if (args.length != 1) throw new NumberFormatException(); int vx = Integer.parseInt(args[0]); Integer rx = new Integer(vx); System.out.println(" Number: " + rx.toString()); System.out.println("Hashcode: " + rx.hashCode()); } catch (NumberFormatException e) { System.out.println("Error: Bad input"); } } }

  Number: 39
Hashcode: 39

Error: Bad input

Error: Bad input

Error: Bad input

Multiplicities put constraints on number of references held by an object.

Recall java.util.List and java.io.BufferedReader.

   +---------------+
   | <<interface>> |       * +--------+
   |     List      |<>------>| Object |
   +---------------+         +--------+

   +----------------+   0..1 +--------+
   | BufferedReader |<>----->| Reader |
   +----------------+        +--------+

Note: if mutiplicity is 1, then reference must be non-null when constructor terminates.

This may require that we throw and IllegalArgumentException if an argument to the constructor is null.

file:Main.java [source] [doc-public] [doc-private]

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 package basics.checkargs; public class Main { private Main() {} static public void main (final String[] args) { //stdlib.Trace.graphvizShowSteps (true); stdlib.Trace.run (); try { System.out.println(new Person("bob")); System.out.println(new Person(null)); } catch (IllegalArgumentException e) { System.out.println("Error creating Person: " + e); } } } final class Person { final private String name; public Person(String name) { if (name == null) throw new IllegalArgumentException("null name"); this.name = name; } public String toString() { return "Person(" + name + ")"; }; }

   +--------+   name  1 +--------+
   | Person |<>-------->| String |
   +--------+           +--------+

Person(bob)
Exception in thread "main" java.lang.IllegalArgumentException
        at basics.checkargs.Person.<init>(Main.java:13)
        at basics.checkargs.Main.main(Main.java:6)

The diagram describes the relationship of objects without reference to implementation.

The diagram uses associations which may be either dependencies or references.

Associations are more abstract (less specific, less concrete) than dependencies and references.

The diagram also show the use of roles and names in associations.

An association without an arrowhead may be bidirectional.

Reference/Exclusive Reference:

Dependency (no reference):

Association (could be either reference or dependency):

final class D {
  A _xa;
  B _xb;

  D (B xb) {
   _xa = new A();
   _xb = xb;
  }
  void f(C xc) { ... }
}

Draw two diagrams showing the relationships between D and A, B and C.

1. Be as abstract as possible.
2. Be as concrete as possible.

What is testing?

How Google Tests Software

What kinds of testing are there?

For us, the most important distinctions are:

• Automatic/Manual
• Unit/Acceptance

Create a test class. (Test classes are object classes.)

Each test method is treated like a separate program.

import junit.framework.Assert;
import junit.framework.TestCase;
public class TEST1 extends TestCase {
  public TEST1(String name) {
    super(name);
  }
  public void testA() { ... }
  public void testB() { ... }
}

Tests are run more-or-less as:

TEST1 t1 = new TEST1("testA");
t1.setUp();
t1.testA();
t1.tearDown();

TEST1 t2 = new TEST1("testB");
t2.setUp();
t2.testB();
t2.tearDown();

Each test has one of three possible outcomes:

• pass: test ended normally and no assertion failed
• fail: test ended normally at least one assertion failed
• error: uncaught exception thrown before test ended

Rules for a test class:

• class must be public
• class name must include substring ``TEST'' (for ant)
• class must extend junit.framework.TestCase
• constructor must accept String parameter and pass it to super constructor
• non-static methods "public void test...()" are run automatically as tests

junit.framework.Assert is a static class.

The basic assertion method is assertTrue, which comes in two forms:

Assert.assertTrue(boolean):void
Assert.assertTrue(String,boolean):void

If the boolean value is false, then the enclosing test will fail.

In the second form, the String is printed when the assertion is false.

public void testA() { ...
  Assert.assertTrue(x.getColor() == Color.RED)
  Assert.assertTrue("Wrong color!", x.getColor() == Color.RED)
}

I prefer the version without the String. The messages from junit are already informative.

If there are multiple assertions in a single test, then the enclosing test fails if any assertion is false.

See the Junit API.

Assert also contains some useful derived methods:

• Assert.fail():void
  • same as Assert.assertTrue(false)
• Assert.assertFalse(actual:boolean):void
  • same as Assert.assertTrue(!actual)
• Assert.assertEquals(expected, actual):void
  • same as Assert.assertTrue(expected.equals(actual)) for object types
  • same as Assert.assertTrue(expected == actual) for base types
• Assert.assertSame(expected:Object, actual:Object):void
  • same as Assert.assertTrue(expected == actual)
• Assert.assertNotNull(actual:Object):void
  • same as Assert.assertTrue(null != actual)
• Assert.assertNull(actual:Object):void
  • same as Assert.assertTrue(null == actual)

file:PairTEST.java [source] [doc-public] [doc-private]

001 002 003 004 005 006 007 008 009 010 011 012 013 014 015 016 017 018 019 020 021 022 023 024 025 026 027 028 029 030 031 032 033 034 035 036 037 038 039 040 041 042 043 044 045 046 047 048 049 050 051 052 053 054 055 056 057 058 059 060 061 062 063 064 065 066 067 068 069 070 071 072 073 074 075 076 077 078 079 080 081 082 083 084 085 086 087 088 089 090 091 092 093 094 095 096 097 098 099 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 package basics.testing; import static org.junit.Assert.*; import org.junit.Test; import basics.immutabledata.Pair; public class PairTEST { /** * Constructor should throw IllegalArgumentException if either * argument is null. */ @Test public void testConstructor() { try { new Pair<String,String>(null,"cat"); // constructor should have thrown exception fail(); } catch (IllegalArgumentException e) { } try { new Pair<String,String>("dog",null); // constructor should have thrown exception fail(); } catch (IllegalArgumentException e) { } try { new Pair<String,String>(null,null); // constructor should have thrown exception fail(); } catch (IllegalArgumentException e) { } try { new Pair<String,String>("dog","cat"); } catch (IllegalArgumentException e) { // constructor should have succeeded fail(); } } /** * first() and second() should return references to the objects * given to the constructor. */ @Test public void testFirstAndSecond() { Integer i = 42; Integer j = 91; Pair<Integer,Integer> p = new Pair<Integer,Integer>(i, j); assertSame(i, p.first()); assertSame(j, p.second()); } /** * Here is a weaker version of the above test; this version allows * Pair() to clone its arguments. */ @Test public void testFirstAndSecond_WeakerVersion() { Integer i = 42; Integer j = 91; Pair<Integer,Integer> p = new Pair<Integer,Integer>(i, j); assertEquals(i, p.first()); assertEquals(j, p.second()); } @Test public void testToString() { Pair<Integer,Integer> p = new Pair<Integer,Integer>(42, 91); assertEquals("Pair(42,91)", p.toString()); } @Test public void testEquals() { Pair<Integer,Integer> p1 = new Pair<Integer,Integer>(42, 91); Pair<Integer,Integer> p2 = new Pair<Integer,Integer>(42, 91); Pair<Integer,Integer> p3 = new Pair<Integer,Integer>(43, 91); Pair<Integer,Integer> p4 = new Pair<Integer,Integer>(42, 92); assertTrue(p1.equals(p1)); assertTrue(p1.equals(p2)); assertFalse(p1.equals(p3)); assertFalse(p1.equals(p4)); assertFalse(p1.equals(new Object())); } @Test public void testHashCode() { Pair<Integer,Integer> p1 = new Pair<Integer,Integer>(42, 91); Pair<Integer,Integer> p2 = new Pair<Integer,Integer>(42, 91); Pair<Integer,Integer> p3 = new Pair<Integer,Integer>(43, 91); Pair<Integer,Integer> p4 = new Pair<Integer,Integer>(42, 92); assertEquals(p1.hashCode(), p1.hashCode()); assertEquals(p1.hashCode(), p2.hashCode()); assertTrue(p1.hashCode() != p3.hashCode()); assertTrue(p1.hashCode() != p4.hashCode()); } @Test public void testCompareTo() { Pair<Integer,Integer> p1 = new Pair<Integer,Integer>(42, 91); Pair<Integer,Integer> p2 = new Pair<Integer,Integer>(42, 91); Pair<Integer,Integer> p3 = new Pair<Integer,Integer>(43, 91); Pair<Integer,Integer> p4 = new Pair<Integer,Integer>(42, 92); assertTrue(0 == p1.compareTo(p1)); assertTrue(0 == p1.compareTo(p2)); assertTrue(0 > p1.compareTo(p3)); assertTrue(0 > p1.compareTo(p4)); assertTrue(0 == p2.compareTo(p1)); assertTrue(0 < p3.compareTo(p1)); assertTrue(0 < p4.compareTo(p1)); // Using generic types, the following will not compile. // try { // p1.compareTo(new Object()); // // compareTo should have thrown exception // fail(); // } catch (ClassCastException e) { } } }

Taxonomy = classification

It is useful to think of classes in terms of how they are used.

We have already seen a basic taxonomy:

• static class
• object class
• mixed class

Much of this class is about giving names to various kinds of object classes:

• Decorator classes
• Observer classes
• Visitor classes
• ...

We now consider three kinds of object class:

• Data classes (immutable and mutable)
• Builder classes
• Collection classes

We already have seen a basic version: Person.

Here is a more robust example:

file:Main.java [source] [doc-public] [doc-private]

01 02 03 04 05 06 07 08 package basics.immutabledata; public class Main { private Main() {} static public void main (final String[] args) { //stdlib.Trace.graphvizShowSteps (true); stdlib.Trace.run (); System.out.println(new Pair<>(42, "dog")); } }

file:Pair.java [source] [doc-public] [doc-private]

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 package basics.immutabledata; final public class Pair<S extends Comparable<S>, T extends Comparable<T>> implements Comparable<Pair<S,T>> { final private S x; final private T y; public Pair(S x, T y) { if (x == null || y == null) throw new IllegalArgumentException(); this.x = x; this.y = y; } public S first() { return x; } public T second() { return y; } public String toString() { return "Pair(" + x + "," + y + ")"; } public boolean equals(Object thatObject) { if (thatObject == null) return false; if (this == thatObject) return true; // equals should not throw ClassCastException if (!(this.getClass().equals(thatObject.getClass()))) return false; @SuppressWarnings("unchecked") Pair<S,T> that = (Pair<S,T>) thatObject; return x.equals(that.x) && y.equals(that.y); } private int hcode; public int hashCode() { if (hcode == 0) { hcode = 17; hcode = 37*hcode + x.hashCode(); hcode = 37*hcode + y.hashCode(); } return hcode; } public int compareTo(Pair<S,T> that) { // compareTo may throw ClassCastException int ix = x.compareTo(that.x); if (ix != 0) return ix; return y.compareTo(that.y); } }

(42,dog)

• Make all fields final.
• Ensure that fields are correctly initialized by constructor.
• Override equals, hashCode and toString.
  • Follow the recipies in Bloch.
• Consider overriding compareTo.
  • Follow the recipies in Bloch.

An instance of an immutable data class is immutable if the objects passed into the constructor never change.

Pair p1 = new Pair("dog", "cat");
StringBuilder b2 = new StringBuilder("dog");
Pair p2 = new Pair(b2, "cat");
b2.append("ma");
Pair p3 = new Pair(new StringBuilder("dog"), "cat");

Note that p1 is immutable, but p2 is mutable.

What about p3?

Hashcode Links

Java Practices article

Apache HashCodeBuilder

Vipan Singla's comments on hashCode

Brian Goetz's comments on hashCode

Mark Roulo's comments on hashCode

Immutable objects do not change.

Aliasing does not matter!

We can freely copy references without fear that the object will change.

This has several corollaries:

• No need to clone an immutable object.
• No need for an exclusive reference (defensive copy) of an immutable object.
• Concurrency presents no difficulties -- see SE552.
• With extra care == and equals are equivalent -- discussed later.

Guideline: make all data classes immutable

Mutable data classes are useful for building objects incrementally.

This is called the builder pattern.

A builder is an object that is used to create an object of another class. Usually the builder is used to create exactly one other object, then discarded.

The important part of the following example is toPair, which converts the mutable class to the immutable companion class.

   +------------------------+ <<creates>>  +---------------+
   | PairBuilder            |- - - - - - ->| <<immutable>> |
   +------------------------+              |      Pair     |
   | setFirst(Object):void  |              +---------------+
   | setSecond(Object):void |
   | toPair():Pair          |
   +------------------------+

file:Main.java [source] [doc-public] [doc-private]

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 package basics.mutablebasic; import basics.immutabledata.Pair; public class Main { private Main() {} static public void main (final String[] args) { //stdlib.Trace.graphvizShowSteps (true); stdlib.Trace.run (); final PairBuilder<Integer,String> pb1 = new PairBuilder<Integer,String>(); pb1.setFirst(42); pb1.setSecond("dog"); System.out.println(pb1); final Pair<Integer,String> p1 = pb1.toPair(); System.out.println(p1); final PairBuilder<Integer,String> pb2 = new PairBuilder<Integer,String>(); final Pair<Integer,String> p2 = pb2.toPair(); } } final class PairBuilder<S extends Comparable<S>, T extends Comparable<T>> { private S x; private T y; public PairBuilder() { } public void setFirst(S x) { this.x = x; } public void setSecond(T y) { this.y = y; } public Pair<S,T> toPair() { if (x == null || y == null) throw new NullPointerException(); return new Pair<S,T>(x,y); } }

(42,dog)
(42,dog)
Exception in thread "main" java.lang.NullPointerException
        at basics.mutabledata.MutPair.toPair(Main.java:26)
        at basics.mutabledata.Main.main(Main.java:12)

java.lang.StringBuilder is a builder for java.lang.String.

   +---------------------+ <<creates>>  +---------------+
   | StringBuilder        |- - - - - - ->| <<immutable>> |
   +---------------------+              |     String    |
   | append(String):void |              +---------------+
   | toString():String   |
   +---------------------+

Here is an example, showing the usage:

file:Main.java [source] [doc-public] [doc-private]

01 02 03 04 05 06 07 08 09 10 11 12 13 14 package basics.stringbuffer; public class Main { private Main() {} static public void main (String[] args) { //stdlib.Trace.graphvizShowSteps (true); stdlib.Trace.run (); StringBuilder b = new StringBuilder(); b.append("I am "); b.append("a dog"); String s = b.toString(); System.out.println(s); b.append("matic jerk"); System.out.println(s); } }

Mutable classes that are used as data are a pain.

Guidelines:

• Always override toString.
• Consider overriding clone.
  • Follow the recipies in Bloch.
• Be careful with null references!
• Be careful when overriding equals, hashCode and compareTo.
  • hashCode should depend only on immutable attributes.
  • If two objects are equals, they must have the same hashCode.
  • compareTo should return 0 exactly when equals returns true.

When dealing with mutable data objects, there are three choices:

1. leave equals/hashCode alone and do not override compareTo
2. make equals/hashCode/compareTo rely only on immutable data
3. use dangerous equals/hashCode and hope no-one uses the objects as keys in a hash table

In general, solution 1 is probably the best one. In homework 1, I chose option 2.

file:MutPair.java [source] [doc-public] [doc-private]

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 package basics.mutabledata; // Do not override equals or hashCode for mutable data. // Do not make mutable data Comparable. final public class MutPair<S,T> implements Cloneable { private S x; private T y; public MutPair() { } public MutPair(S x, T y) { this.x = x; this.y = y; } public void setFirst(S x) { this.x = x; } public void setSecond(T y) { this.y = y; } public S first() { return x; } public T second() { return y; } public String toString() { return "MutPair(" + x + "," + y + ")"; } // Clone does not play nice with generics because it returns Object. // Deep clone is difficult to implement generically because: // (1) cast to MutPair is allowed, not to MutPair<S,T>; we need the // latter in order to get at the fields. // (2) Cloneable type does not have public clone method, so we // cannot call x.clone() or y.clone(); this would be true even // if we had "MutPair<S extends Cloneable,T extends Cloneable>" public Object clone() { try { return super.clone(); } catch (CloneNotSupportedException e) { throw new InternalError(); } } }

It is possible to lose mutable values in a hashtable.

java.util.Date is mutable and overrides hashCode.

file:basics/hashmutable/Main.java [source] [doc-public] [doc-private]

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 package basics.hashmutable; import java.util.Date; import java.util.Hashtable; // example from http://www.vipan.com/htdocs/hashcode_help.html public class Main { public static void main (String[] args) { //stdlib.Trace.graphvizShowSteps (true); stdlib.Trace.run (); Hashtable<Date,String> map = new Hashtable<Date,String>(); long time = System.currentTimeMillis(); Date dt1 = new Date(time); Date dt2 = new Date(time); map.put(dt1, "blah"); System.out.println("dt1.toString() = " + dt1.toString()); System.out.println("dt2.toString() = " + dt2.toString()); System.out.println("Is dt2.equals(dt)? = " + dt2.equals(dt1)); System.out.println("map.get(dt1) = " + map.get(dt1) ); System.out.println("map.get(dt2) = " + map.get(dt2) ); // Change dt by adding a day to its time dt1.setTime(time + 24*60*60*1000L); System.out.println("\nAfter dt.setTime(newTime):"); System.out.println("dt1.toString() = " + dt1.toString()); System.out.println("dt2.toString() = " + dt2.toString()); System.out.println("Is dt2.equals(dt)? = " + dt2.equals(dt1)); System.out.println("map.get(dt1) = " + map.get(dt1) ); System.out.println("map.get(dt2) = " + map.get(dt2) ); //System.out.println("\nmap = " + map.toString() ); } }

dt1.toString() = Thu Jan 03 12:46:33 EST 2002
dt2.toString() = Thu Jan 03 12:46:33 EST 2002
Is dt2.equals(dt)? = true
map.get(dt1) = blah
map.get(dt2) = blah

After dt1.setTime(newTime):
dt1.toString() = Fri Jan 04 12:46:33 EST 2002
dt2.toString() = Thu Jan 03 12:46:33 EST 2002
Is dt2.equals(dt)? = false
map.get(dt1) = null
map.get(dt2) = null

map = {Fri Jan 04 12:46:33 EST 2002=blah}

A collection may hold references to many other objects.

Usually the objects are of some uniform type, eg, a list of dogs, a set of colors.

The java.util provides several collection classes. (See the java tutorial.)

We may implement our own collections. Usually these make use of the java.util classes.

In the following example, IntegerStack delgates most of its responsibilities to List.

file:IntegerStack.java [source] [doc-public] [doc-private]

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 package basics.collection; import java.util.List; import java.util.ArrayList; import java.util.EmptyStackException; final public class IntegerStack { final private List<Integer> l; public IntegerStack() { l = new ArrayList<Integer>(); } public boolean isEmpty() { return l.isEmpty(); } public void push(Integer x) { if (x == null) throw new IllegalArgumentException(); l.add(x); } public Integer pop() { if (l.isEmpty()) throw new EmptyStackException(); return l.remove(l.size()-1); } }

Here is a good, abstract drawing:

                           +--------------+     *  +---------+
                           | IntegerStack |<>----->| Integer |
                           +--------------+        +---------+

Here is a drawing showing the implementation:

   +--------------+  1     +--------------+     *  +---------+
   |    List      |<----<@>| IntegerStack |<>----->| Integer |
   +--------------+        +--------------+        +---------+

More concrete:

   +--------------+  1     +--------------+     *  +---------+
   |  ArrayList   |<----<@>| IntegerStack |<>----->| Integer |
   +--------------+        +--------------+        +---------+

Too concrete:

   +--------------+     1  +--------------+     *  +---------+
   | IntegerStack |<@>---->|  ArrayList   |<>----->| Integer |
   +--------------+        +--------------+        +---------+

This last diagram obscures the fact that IntegerStack is a collection of Integers.

Revised: 2008/09/10 16:46