Design Patterns and Conventions

Collected Java Practices: offers concise presentations of Java practices, tasks, and designs, illustrated with syntax-highlighted code examples. The code examples are available for download. See below for user comments on the site.
Designing Enterprise Applications with the J2EE Platform, Second Edition: official free eBook on JavaEE aplication design;
Java BluePrints, Official Guidelines, Patterns, and Code for End-to-End Java Applications:
contains recommended conventions for structuring applications developed using JavaEE.

The JEE Specification (which can be downloaded from http://java.sun.com/j2ee/1.4/download.html#platformspec) indicates that certain files, such as deployment descriptors, class files, interface files, and other files, must be present as part of an application. However, this specification does not specify a recommended or required directory structure for these files.

The guidelines in this document are intended to assist developers with organizing the files and directories associated with an application in a logical fashion. Organizing your applications as shown in these guidelines will make it easier to manage and maintain a project, especially when multiple developers contribute to the same project or projects are maintained during an extended lifetime. Having a predefined, consistent, standard workspace layout saves time, especially at the onset of a project.

Following these conventions will help developers establish an overall directory structure for applications. The conventions suggest where to place different types of files generally present in an application, such as ant files, test files, compiled code, Java and non-Java source code files, portable and application server-specific deployment descriptors, utility code, binary libraries, documentation files, configuration files, Enterprise Application archive (EAR) files, Web Application archive (WAR) files, copyright and license documents, etc. They also help developers determine how to best separate project files from files that are distributed as part of an application download.

Following these conventions will also help developers package J2EE applications into EAR or WAR files because consistent project structure is helpful for proper packaging using common ant targets.

These conventions, which the Java BluePrints team has followed with its applications (which can be accessed from http://java.sun.com/blueprints/code/index.html), assume that developers use the Ant tool for building projects. Developers using other build tools may have to make slight modifications to the conventions.

Some usefull stuff:

The differences between Decorator Pattern and Proxy Pattern

Observer pattern

Has every design pattern the implementation can be done in many different ways.
For the Observable pattern java provides some utility classes and interfaces to help on the implementation of this pattern.
This utilities provide at least 2 different ways of implementing the design pattern:

Option 1: Using Class java.util.Observable and Interface java.util.Observer;

Dowload source code example

The class java.util.Observable:
This class represents an observable object, or "data" in the model-view paradigm.
So, the model object should extend this class that provides it with methods like:


Modifier and Type	Method and Description
`void`	`addObserver(Observer o)` Adds an observer to the set of observers for this object, provided that it is not the same as some observer already in the set.
`protected void`	`clearChanged()` Indicates that this object has no longer changed, or that it has already notified all of its observers of its most recent change, so that the `hasChanged` method will now return `false`.
`int`	`countObservers()` Returns the number of observers of this `Observable` object.
`void`	`deleteObserver(Observer o)` Deletes an observer from the set of observers of this object.
`void`	`deleteObservers()` Clears the observer list so that this object no longer has any observers.
`boolean`	`hasChanged()` Tests if this object has changed.
`void`	`notifyObservers()` If this object has changed, as indicated by the `hasChanged` method, then notify all of its observers and then call the `clearChanged` method to indicate that this object has no longer changed.
`void`	`notifyObservers(Object arg)` If this object has changed, as indicated by the `hasChanged` method, then notify all of its observers and then call the `clearChanged` method to indicate that this object has no longer changed.
`protected void`	`setChanged()` Marks this `Observable` object as having been changed; the `hasChanged` method will now return `true`.

The java.util.Observer interface:
A class can implement the Observer interface when it wants to be informed of changes in observable objects.
This interface demands only one method implementation:

void     update(Observable o, Object arg)

This method is called whenever the observed object is changed.

Implementation example:

The model:

public class MyModel extends Observable {  
    //propertie 'nome':
    public void setNome(String nome) {          
        this.nome = nome;      
        super.setChanged();  
        //if setChanged() wasn't set, the next method would not do anything:
        super.notifyObservers();        
    }

The view:

public class MyViewA implements Observer {
    @Override
    public void update(Observable o, Object arg) {        
        MyModel model = (MyModel) o;
        //do something
    }

The Controller:

public class Controller {
    public static void main(String[] args) {
        MyModel model = new MyModel("aa", "bb");
        MyViewA view = new MyViewA();        
        model.addObserver(view);
        model.setNome("cc");

Option 2: using events - class java.beans.PropertyChangeSupport and interface java.beans.PropertyChangeListener

Check the topic "The Property Change Listener API" under the "Events" section on the side bar for a example and documentation.

Java

Pages