carfield.com.hk

agile_2010_Cindy_McCracken.pdf

2012-02-20T16:53:02Z

Vernon_2011_1.pdf

2011-12-29T15:35:42Z

StrangeLoop2011-DeanWampler-HeresiesandDogmasinSoftwareDevelopment.pdf

2011-11-29T18:32:38Z

Cheatsheet-Performance-Principles-Patterns-and-Anti-Patterns.pdf

2011-10-21T16:32:50Z

02-Code-Quality.pdf

2011-07-24T16:08:36Z

Object-Oriented.png

2011-07-24T14:36:08Z

practical-file-system-design.pdf

2011-06-30T17:02:38Z

_atlantic_monthly-broken_windows.pdf

2011-03-23T15:58:22Z

testBus.pdf

2010-01-12T17:28:40Z

saga.pdf

2009-07-10T15:08:04Z

Evolving Frameworks_ A Pattern Language.pdf

2009-04-18T19:10:26Z

spec.pdf

2008-09-18T16:54:56Z

Everything.You.Know.is.Wrong.pdf

2008-09-17T15:08:22Z

README.txt

2008-03-17T17:25:16Z

Implementations of GoF Design Patterns in Java and AspectJ
Code base documentation

Overview
========

The goal was to provide parallel implementations in AspectJ and Java that
allow for direct comparisons. It has to be noted that most patterns offer
variability in the implementation approach. We choose the one that appeared
to be the most general. Sometimes, the AspectJ version implements a slightly
different (or additional) case(s). This is because AJ sometimes
allows for additional functionality. Please refer to the web page for a
detailed description of this work.

Example Setup
=============

All pattern examples have a class called Main. This class is the test driver
for the particular example. The Main classes are extensively documented using
ajdoc, usually describing the experimental setup and the assignment of roles
to participants. In most cases, the differences between Java and AspectJ
implementations are also mentioned.

Documentation (ajdoc)
=====================

It is possible to generate the ajdoc documentation for either all examples,
for only the reusable library aspects, or for one particular example. Since
ajdoc shows type names without their package (on the left hand side), multiple
types with the same name (but residing in different packages) may be confused
when the documentation for all examples is generated.
==> Generate documentation for all examples: use the makeDocs batch file.
(1) Change to the directory that you extracted the ZIP archive into. (2)
Type "makeDocs" to generate the HTML documentation in the docs
subdirectory.
==> Generate Documentation for the reusable library aspects: use the provided
makeLibraryDocs batch file. (1) Change to the directory that you extracted
the downloaded ZIP file into. (2) Type "makeLibraryDocs" to generate the
HTML documentation in the docs subdirectory.
==> Generate docs for a single example: use the makeSingleExampleDocs batch
file. (1) Change to the directory that you extracted the downloaded ZIP
file into. (2) Call the batch file. It needs two arguments: the name of
the pattern and the language used. For example, type:
"makeSingleExampleDocs singleton aspectj" or type:
"makeSingleExampleDocs templateMethod java".
Within the ajdoc documentation, we tried to separate type names from our
examples and role names (as presented in GoF). We show roles names in italics
and actual type names in code font. This is reflected in the ajdoc
documentation.

Questions, feedback, suggestions, etc.
The AODP web page is http://www.cs.ubc.ca/labs/spl/aodp.html
Please send all questions, feedback, and suggestions to Jan Hannemann
(jan@cs.ubc.ca). We are very much interested in improving our code.
Please do not hesitate to drop us a line.

Appendix
========

This appendix outlines how to compile and run the examples provided, and how
to generate ajdoc documentation. A number of DOS batch files exist that
automate these tasks somewhat. Note that they only work in Windows
environments. The following is a list of tasks and a description of what
commands accomplish them. For compiling, running and generating documentation,
two options are given. The first one is using a provided script; the second is
the standard command-line option (longer, but will work on all operation
systems).

Set up your system:
1. Install Java and AspectJ
2. Make sure your CLASSPATH contains the current directory (denoted by a
period), e.g. CLASSPATH=.;C:\...
3. Extract the ZIP file into a directory of your choice
4. Change to that directory

Compile Java and AspectJ versions of a design pattern example (e.g. observer).
Choose one:
� makePattern observer
� ajc @examples\observer\files.lst

Run a compiled example (e.g. observer). Choose one:
� testPattern observer (this runs both Java and AspectJ versions)
� java examples.observer.java.Main (for the Java version),
java examples.observer.java.Main (for the AspectJ version)

Generate documentation for all examples. Choose one:
� makeDocs
� ajdoc -private -d docs @allPatterns.lst

Generate documentation for the library aspects. Choose one:
� makeLibraryDocs
� ajdoc -private -d docs ca.ubc.cs.spl.pattern.library

Generate documentation for a single example (e.g. the AspectJ version of the
observer example). Choose one:
� makeSingleExampleDocs observer aspectj
� ajdoc -private -d docs examples.observer.aspectj

View the generated documentation:
� Open the file index.html (located in the docs/ subdirectory) with your
favorite browser.

ExampleOfGoodAPI.pdf

2007-02-26T07:12:12Z

HowToDesignGoodAPI.pdf

2007-02-26T07:10:52Z

dddquickly.pdf

2006-12-18T03:15:44Z

Event-driven Architectures.pdf

2006-06-13T15:09:58Z

AdvancedPrinciplesOfClassDesign.ppt

2006-03-21T10:27:32Z

short present of how to make good API design.pdf

2006-03-21T05:06:12Z

pattern examples.pdf

2004-07-07T16:00:00Z

architect comment pattern.txt

2004-06-08T16:00:00Z

---------- Forwarded message ----------
Date: Thu, 29 Aug 2002 17:16:33 +0200
From: John Favaro
Reply-To: extremeprogramming@yahoogroups.com
To: Yahoo XP Group
Subject: [XP] An architect's comments on patterns

In a recent thread I passed on some comments from my brother, who is an
architect, on the "design-build" paradigm. I had asked him what he knew
about it, since there was interest in the software engineering community as
an analogy to optional scope contracts; and I was interested in hearing at
least one architect's point of view.

The resulting discussion was interesting enough that I decided What The Heck
Let's Go All The Way and I asked my brother another question:

"What do you know about Christopher Alexander? His concept of patterns has
generated a great deal of interest in the software engineering world."

Here is his response:

"He was a kind of guru in the 60's and 70's.

"the 'patterns' refers essentially to 'tradition' ; his basic point being
that over 5,000 years immutable patterns of building and architecture emerge
that we can rely on when taking on a building design; (for example, if you
look at good rooms in domestic settings the best ones always seem to have
windows on two sides, preferably opposite sides) He came up with 'patterns'
instead of 'tradition' because it was Berkeley in the sixties when tradition
was seen as oppressive, euro-centric and 'irrelevant'. He wanted to
catalogue all the patterns of architecture in the history of the world (all
over the world, not just Europe of course) in the belief that there would be
a scientific way to get to good design--therefore avoiding the role of
culture (because culture requires values and judgment and whose culture are
we talking about anyway?) Of course it didn't work because architecture is
an art not a science. And his concept of patterns is ten times more
oppressive than the concept of the context of tradition as the fertile
ground within which innovation thrives (innovation is all about finding the
exception to the rule that changes the way we look at the rules, and
sometimes even the rules themselves). The buildings he actually produced
(not very many, small residences) ended up being ultra-conservative (very
eurocentric, in fact, like little Austrian cottages) and not very
remarkable.

"computer science is a science but I have a feeling that computer
applications are as much an art as a science, since they're about tailoring
to specific needs, making choices and judgments, relating choices to a set
of values on behalf of the client, etc.

"that's why the design-build analogy is big trouble because the intent is to
cut the 'artist' out of the equation--let the accountants drive the choices,
after all it's all cut and dry right?, it's all just science; that's what
the HMO's have done to doctors and medicine; our field went through it after
WWII--you're next.

"run for your life..."

(Yes, he can be a bit provocative and dramatic)

In a second message he added this:

"well, the solution is to train the computer consultants to be responsible
about budget and schedule--that time and money are as potent in creative
possibility as anything else; the solution is not to cut them out of the
picture altogether; that just leads to self-fulfilling ends--assume the
consultant is only interested in design, let him focus on that in the vacuum
of budget and schedule and 'we'll handle that part (even though we don't
know what the hell he's talking about),' thus setting up a relationship of
conflict and misunderstanding from the beginning and encouraging the
designer to be irresponsible and narrowly focused;

"you treat people like children, they're going to act like children;"

Since I saw it first, I guess I get to make the first comments :-)

- after all the opinions expressed by us software guys about the
architecture field, it's kind of funny to see an architect commenting on OUR
field.

- regarding his opinion on Alexander's work ... well, it certainly made for
interesting reading. Whether his opinion is universally shared in the world
of architecture I don't know. One possibility that occurs to me is that my
brother's goals for a successful building might be different from Alexander'
s. What he did seem to be implying, however, is that Alexander ultimately
did not have a lasting influence in the world of architecture. Again, I don'
t know how true that is.

- I did find interesting his insistence on measuring Alexander's ideas by
the buildings that were actually built with them. That meshes well with the
centricity of code artifacts in XP, as the principal measure of results.

- regarding his characterization of the nature of computer applications, I
thought he did pretty well, actually.

- when he starts talking about design-build again, I think this is once more
where the difference between our contexts comes out. As Dan Palanza and
others explained in the earlier thread, XP in particular is doing a lot to
eliminate the antagonistic relationship between design and build in our
context. Likewise the emphasis in agile development on accepted
responsibility for time and budget considerations. The analogy to his
warning about designers working in a vacuum of time and budget constraints
in our situation might be that of *requirements analysts* working in vacuum
of time and budget constraints, something Martin Fowler has also commented
on.

Perhaps the overriding impression I get from all this is that, as others
have written recently, maybe we shouldn't push quite as hard as we do to
find perfect analogies between our world and the architectural world every
single time. Patterns and design-build may not have been successful in the
architectural world (if that's even true) -- but nobody doubts any more that
patterns have been hugely successful in the software world; and it looks
like the design-build paradigm as it is being tailored and applied in the
software world (e.g. with optional scope contracts) will probably be
successful, too. To each his own context.

John

replace Conditional With Visitor.pdf

2004-05-30T16:00:00Z

CommandProtocol.java

2004-03-24T16:00:00Z

package ca.ubc.cs.spl.pattern.library;

/* -*- Mode: Java; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*-
 *
 * This file is part of the design patterns project at UBC
 *
 * The contents of this file are subject to the Mozilla Public License
 * Version 1.1 (the "License"); you may not use this file except in
 * compliance with the License. You may obtain a copy of the License at
 * either http://www.mozilla.org/MPL/ or http://aspectj.org/MPL/.
 *
 * Software distributed under the License is distributed on an "AS IS" basis,
 * WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License
 * for the specific language governing rights and limitations under the
 * License.
 *
 * The Original Code is ca.ubc.cs.spl.patterns.
 *
 * Contributor(s):   
 */
 
import java.util.WeakHashMap;
import java.util.Collection;
import java.util.LinkedList;
import java.util.Iterator;  

import ca.ubc.cs.spl.pattern.library.Command;
import ca.ubc.cs.spl.pattern.library.CommandInvoker;
import ca.ubc.cs.spl.pattern.library.CommandReceiver;

// TODO: This implementation allows only for exactly one command per invoker. 
// That can either stay this way or be replaced with composite (macro) 
// commands, either with or without defined order. [Jan, Oct 29, 2002]

/**
 * This is the abstract <i>Command</i> protocol.
 * 
 * @author  Jan Hannemann
 * @author  Gregor Kiczales
 * @version 1.1, 10/29/02
 * 
 * @see Command
 */

public abstract aspect CommandProtocol { 
    
////////////////////////////////
// Invoker -> Command mapping //
////////////////////////////////

    /**
     * stores the mapping between CommandInvokers and Commands
     */
    
    private WeakHashMap mappingInvokerToCommand = new WeakHashMap();
    
    /**
     * Sets a new command for an invoker
     *
     * @param invoker the object which will invoke the command
     * @param command the command to be set
     * @returns the former command
     */   
     
    public Object setCommand(CommandInvoker invoker, Command command) { 
    	return mappingInvokerToCommand.put(invoker, command); 
    }
    
    /**
     * Removes a command from an invoker
     *
     * @param invoker the object which will no longer invoke the command
     * @param command the command to be removed
     * @returns the former command
     */   
     
    public Object removeCommand(CommandInvoker invoker) { 
    	return setCommand(invoker, null); 
    }


    /**
     * Returns the command for an invoker
     *
     * @param invoker the object for which to return the command 
     * @returns the current command for the invoker
     */   
 
    public Command getCommand(CommandInvoker invoker) { 
    	return (Command) mappingInvokerToCommand.get(invoker); 
    }


/////////////////////////////////
// Command -> Receiver mapping //
/////////////////////////////////

    /**
     * stores the mapping between Coammnds and Receivers
     */
    
    private WeakHashMap mappingCommandToReceiver = new WeakHashMap();
    
    /**
     * Sets a new receiver for a command
     *
     * @param command the command to be set
     * @param receiver the object to be manipulated by the command's 
     *        execute() method
     * @returns the former receiver
     */   
     
    public Object setReceiver(Command command, CommandReceiver receiver) { 
    	return mappingCommandToReceiver.put(command, receiver); 
    }
    
    /**
     * Returns the receiver for a particular command
     *
     * @param invoker the object for which to return the command 
     * @returns the current command for the invoker
     */   
 
    public CommandReceiver getReceiver(Command command) { 
    	return (CommandReceiver) mappingCommandToReceiver.get(command); 
    }


///////////////////////////////////////
// Command Execution via PC & advice //
///////////////////////////////////////


    /**
     * The join points after which to execute the command.
     * This replaces the normally scattered myCommand.execute() calls.
     *
     * @param invoker the object invoking the command
     */

    protected abstract pointcut commandTrigger(CommandInvoker invoker);


    /**
     * Calls <code>executeCommand()</code> when the command is triggered. 
     *
     * @param invoker the object invoking the command
     */ 
     
    after(CommandInvoker invoker): commandTrigger(invoker) { 
        Command command = getCommand(invoker);
    	if (command != null) {
    	    CommandReceiver receiver = getReceiver(command);
        	command.executeCommand(receiver);
        } else {
            // Do nothing: This Invoker has no associated command
        }
    }
    

//////////////////////////////////
// setCommand() via PC & advice //
//////////////////////////////////

    /**
     * The join points after which to set a command for an invoker.
     * This replaces the normally scattered myInvoker.add(Command) calls.
     * The pointcut is provided in addition to the setCommand() method above,
     * to allow all pattern code to be removed from concrete invokers. 
     *
     * This PC is non-abstract, to make it optional for sub-aspcects to define
     * it.
     *
     * @param invoker the invoker to attach the command to
     * @param command the command to be attached to the invoker
     */

    protected pointcut setCommandTrigger(CommandInvoker invoker, Command command);   


    /**
     * Calls <code>addCommand()</code> when a command should be set. 
     *
     * @param invoker the invoker to attach the command to
     * @param command the command to be attached to the invoker
     */ 
     
    after(CommandInvoker invoker, Command command): setCommandTrigger(invoker, command) {                          // TODO: is "before" a better choice? 
    	if (invoker != null)
        	setCommand(invoker, command);  
                                                           // TODO: throw exception in else case?
    }

/////////////////////////////////////
// removeCommand() via PC & advice //
/////////////////////////////////////

    /**
     * The join points after which to remove a command from an invoker.
     * This replaces the normally scattered myInvoker.remove(Command) calls.
     * The pointcut is provided in addition to the removeCommand() method 
     * above, to allow all pattern code to be removed from concrete invokers.
     *
     * This PC is non-abstract, to make it optional for sub-aspcects to define
     * it.
     *
     * @param invoker the invoker to remove the command from
     */

    protected pointcut removeCommandTrigger(CommandInvoker invoker);   
    
    /**
     * Calls <code>removeCommand()</code> when a command should be removed. 
     *
     * @param invoker the invoker to remove the command from
     */ 
     
    after(CommandInvoker invoker): removeCommandTrigger(invoker) {                          // TODO: is "before" a better choice? 
    	if (invoker != null)
        	removeCommand(invoker);  
                                                           // TODO: throw exception in else case?
    }

////////////////////////////////////////////
// Command default method implementations //
////////////////////////////////////////////

    /**
     * Provides a deault implementation for the isExecutable method defined
     * in the Command interface. 
     *
     * @returns true (default implementation). Can be overwritten by concrete
     * aspects or even concrete commands.
     */ 

    public boolean ca.ubc.cs.spl.pattern.library.Command.isExecutable() {
        return true;
    } 
    
////////////////////////////////////////////////////////////////
// Calling specialized execute() instead of generic execute() //
////////////////////////////////////////////////////////////////

    public final void Command.execute() {}    // this prevents anyone from implementing this method instead of the specialized version. Invokers can call it though

    protected pointcut callGenericExecute(Command command): 
        ( call(void Command+.execute())) && target(command);

    after(Command command): callGenericExecute(command) {              // TODO: around?
        command.executeCommand(getReceiver(command));
    }
}

CommandReceiver.java

2004-03-24T16:00:00Z