Source and Type

[Alex Gout]

Hi,

I just looked at the code, and I'd like to discuss something.
Im not sure about the source and type attributes. Although the type
attribute might add some useful information in the realms of
structural or creational, non GoF patterns might fall in none of those
categories, or even several. I feel when you introduce an exclusive
type of some sort, it should be orthogonal, or close to it.
I also have doubts about the semantics of the source attribute. Does
it mean where it is first published? The patterns in GoF or Pattern
Oriented Software Architecture are published and discussed in many
places. And as a reference, the GoF book might not be the best read.
Maybe we should add an attribute, so that the programmer can add a
reference. This way, collegues who do not understand the pattern can
refer to some site or book.
This also goes for the package structure. "gof" as a packagename,
really limits the options for future packages.

I was reluctant to send these comments, because I don't have 'better'
options at hand, but I feel at least we should discuss it.

And I think one of the first steps we have to make is compile a
shortlist of a variety of patterns, so we can get a first impression
what is all out there, which ones we wil focus on first and how we can
fit them in a logical structured system.

That's it for me now! Time for some strat abuse.

Regards,
Alex

[Michael Hunger]

Alex,

do you have an github account? I can add you to the project if you'd like.

Regarding the gof thing. You're right, there are several orthogonal things for describing a pattern. But for structuring the packages (and not having every pattern in the root package, I think we should keep that package name.

We add all the orthogonal stuff to the DesignPattern annotation and/or to the JavaDoc of the Pattern annotation itself (@see attribute for books - wikipedia book thingi, and URLs).

Cheers

Michael

[ag...@planet.nl]

Hi!

Thanks for your comment! I created a github account named AlexGout. I
should take a closer look at Git now ;)

Cheers,
Alex

[Dr Heinz M. Kabutz]

Hi chaps,

I'm going to change the command pattern to not have any participants.  If someone wants to specify those, they can use the @PatternDetails() annotation.  I think it will make it easier to use.

package org.jpatterns.gof.command;

import org.jpatterns.*;
import org.jpatterns.gof.composite.CompositePattern;

import java.lang.annotation.*;

/**
 * @author Michael Hunger
 * @since 2010-08-08
 */
@Retention(value = RetentionPolicy.RUNTIME)
// HK: I think we should use RUNTIME so that the information about the patterns is always available, even to Reflection
@Target(value = ElementType.TYPE)
@Documented
@DesignPattern(source = Source.GoF,
    type = Type.BEHAVIORAL,
    urls = {"http://en.wikipedia.org/wiki/Command_pattern",
        "http://home.earthlink.net/~huston2/dp/command.html"},
    refactorings = {
        Refactoring.ExtractParameterObject, // HK: I would leave out the refactorings for now - information overload - we can put that in later
        Refactoring.ExtractMethodObject},
    related = {CompositePattern.class})
// HK: should we really do this?  I would not want to re-document everything that is already in GoF.  The purpose of these annotations should be to document patterns in our code.

public @interface CommandPattern {
  @Retention(value = RetentionPolicy.RUNTIME)
  @Target(value = ElementType.TYPE)
  @Documented
  public @interface Command {
    boolean undoable() default false;
    String comment() default "";
    Class receiver() default void.class; // HK: The command would not know about what receiver it is talking to
  }

  @Retention(value = RetentionPolicy.RUNTIME)
  @Target(value = ElementType.TYPE)
  @Documented
  public @interface ConcreteCommand {
    String comment() default "";
    // HK: This one would know about the receiver it was created for
    Class[] participants() default {};
  }

  @Retention(value = RetentionPolicy.RUNTIME)
  @Target(value = ElementType.TYPE)
  @Documented
  public @interface Invoker {
    String comment() default "";
    Class command() default void.class; // HK: an invoker could potentially have more than one command
    Class[] participants() default {}; // HK: I would prefer this approach, leaving it up to the user to specify as much or as little as he wants
  }

  @Retention(value = RetentionPolicy.RUNTIME)
  @Target(value = ElementType.TYPE)
  @Documented
  public @interface Receiver {
    String comment() default "";
    Class command() default void.class; // HK: the receiver should not know about the commands that are invoking it - look at my example GUIActionTest
    Class[] participants() default {};
  }

  @Retention(value = RetentionPolicy.RUNTIME)
  @Target(value = ElementType.TYPE)
  @Documented
  public @interface Client {
    String comment() default "";
    Class[] participants() default {};
  }
}

Regards

Heinz
-- 
Dr Heinz M. Kabutz (PhD CompSci)
Author of "The Java(tm) Specialists' Newsletter"
Sun Java Champion
http://www.javaspecialists.eu
Tel: +30 69 72 850 460
Skype: kabutz