Lecture Notes for Concurrent Programming

25 July 2002 - Programming Patterns

Programming Patterns

• Before and After Patterns

• Layering

  • Adapters

  • Subclassing

  • Templates

  • Method Adapters

• Java features

  • Assertions

  • An Assertion Example

The Before and After Patterns

• A common programming pattern: set-up, operate, tear-down.

  • Lock, manipulate, unlock.

  • Precondition, compute, postcondition.

  • Connect, communicate, disconnect.

• Forgetting set-up or tear-down is a common problem.

  • Doing the wrong one is another.

• Synchronized blocks automagically apply the correct pattern.

• Develop programming techniques for doing the same.

  • Concurrency control (lock, unlock).

  • Consistency checking (pre-, postconditions).

Hack the Code

• Straightforward programming works, sorta.

  before() ; method() ; after()
  
  before()
  try { method() }
  finally { after() }
  

• There are problems.

  • Tedious.

  • Error prone; adding or removing calls.

  • Foiled by unchangeable or inaccessible code.

  • Can't be generalized.

Layering

• Use the programmer's friend: indirection.

  • Simplified and generalized applications.

  • Also known as wrapping.

• Interfaces provide indirection in Java.

  interface Widget {
    void ping(int pongs)
    }
  

• Anything that implements an interface will serve.

  • Specify interfaces, not implementations.

• Also need to consider error handling.

  • What exception to throw and when.

Adapters

• Implement the interface using the original implementation.

  class OldWidget implements Widget { . . . }
  
  class NewWidget implements Widget {
  
    private OldWidget oldWidget;
  
    NewWidget(OldWidget ow) { oldWidget = ow }
  
    void ping(int pongs) {
      before() ; oldWidget.ping(pongs) ; after()
      }
    }  
  

• This is a common technique.

  • Also known as proxy, delegate, envelope and letter.

• Delegate manipulation provides flexibility.

• Be careful of extensions to the interface.

  • The adapter may have to cover the extensions too.

Subclassing

• Extend the original implementation to include changes.

  • Relies on subtype polymorphism.

  class OldWidget implements Widget { . . . }
  
  class NewWidget extends OldWidget {
  
    void ping(int pongs) {
      before() ; super.ping(pongs) ; after()
      }
    }  
  

• This too is a common technique.

  • Less flexible than adapters.

• Public method tracking is simpler.

  • The adapter may have to cover the extensions too.

Templates

• Useful when the details vary but the overall form doesn't.

• An abstract class defines the overall form.

  abstract class Widget
    void operation()
      { before() ; function() ; after() }
    abstract void before()
    abstract void function()
    abstract void after()
  

• Subclasses fill in the details.

  class UnsynchronizedWidget extends Widget {
    void before() { }
    void function() { // whatever }
    void after() { }
    }
  
  class Synchronizedwidget extends Widget {
    void before() { mutex.lock() }
    void function() { // whatever }
    void before() { mutex.unlock() }
    }
  

Method Adapters

• Define an interface that provides a single method.

  interface CheckWidget 
  
    bool check(Widget w)
  

• Interface implementations code the method as needed.

  class UnsynchronizedWidgetCheck 
  implements WidgetCheck
  
    bool check(Widget w) 
      return w.check()
  
  class SynchronizedWidgetCheck 
  implements WidgetCheck
  
    void check(Widget w)
      synchronized (w) { return w.check() } 
  

• Runnable-run() is another example.

• A large number of methods can make this approach tedious.

Assertions

• Java 1.4 has assertions.

  • Assertions are not compatible with earlier Java versions.

• assert bool-expr [ : value-expr ] ;

  • bool-expr is a boolean expression.

  • value-expr is a non-void expression.

• If bool-expr is true, nothing happens.

• If bool-expr is false, throw an Assertion Error exception.

  • If value-expr is given, the exception carries the value it produces.

  • The default is to throw no value with the exception.

• Compilation requires the -source 1.4 command-line option.

  • By default, javac assumes pre-1.4 Java source.

• Execution requires the -ea (enable assertion) argument.

  • By default, java does not do assertion checking.

An Assertion Example

$ cat a.java
class a {
  public static void main(String[] args) {
    try { assert false : "Oopsie, an assertion failed!"; } 
    catch (AssertionError ae) {
      System.out.println("Caught an assertion failure: " 
                         + ae.getMessage());
      }
    }
  }

$ javac a.java
a.java:3: warning: as of release 1.4, assert is a keyword, 
and may not be used as an identifier 
    try { assert false : "Oopsie, an assertion failed!"; } 
          ^
a.java:3: not a statement
    try { assert false : "Oopsie, an assertion failed!"; } 
          ^
a.java:3: ';' expected
    try { assert false : "Oopsie, an assertion failed!"; } 
                 ^
2 errors
1 warning

$ javac -source 1.4 a.java

$ java a

$ java -ea a
Caught an assertion failure: Oopsie, an assertion failed!

$ 

try-catch-finally

• A finally clause is always executed.

  • try, finally.

  • try, exception, catch, finally.

    • try, exception, catch, exception, finally.

  • try, exception, finally.

• Always-executed code goes in a finally clause.

  try {
    mutex.lock()
    // whatever
    }
  catch (InterruptedExecution ie) {
    // whatever
    }
  finally {
    mutex.unlock()
    }
  

  • catch clauses are optional.

Points to Remember

• Execute code before and after a method call.

  • Or sometimes not.

• The before-and-after pattern allows for this.

  • Adapters, subclassing, templates.

• Java has assertions.

  • Makes your code irredeemably version 1.4.

• The finally clause always executes.

  • A good place for always executed code.

This page last modified on 22 July 2002.