Welcome to jpatterns.org

Posted byadmin 14 Comments on Welcome to jpatterns.org

Design Patterns are typically encoded into Java code in an ad-hoc fashion.  They are either embedded into the names of the classes or written into the Javadocs.  Unfortunately it is impossible to accurately determine a pattern based solely on the class structure without knowing the intent of the code author.

JPatterns is a collection of annotations that make it easy to communicate the use of (Design)Patterns within your code to your fellow developers and your future self.  We follow the KISS principle by using reasonable defaults for the annotation attributes.  Thus, if you are writing a composite, you can simply specify:

@CompositePattern
public abstract class Contact {
  public abstract void sendMail(String msg);
  public void add(Contact contact) {}
  public void remove(Contact contact) {}
}

Or, if you wanted to, you could also be more explicit, for example

@CompositePattern(role = CompositeRole.COMPONENT,
 participants = {DistributionList.class, Person.class})
public abstract class Contact {
  public abstract void sendMail(String msg);
  public void add(Contact contact) {}
  public void remove(Contact contact) {}
}

Please let us know if you would like to be part of this project by leaving a comment on this website.

Please access the repository here: http://github.com/jexp/jpatterns

Michael Hunger
Heinz Kabutz

14 replies on “Welcome to jpatterns.org”

  1. I would be interested to contribute in this. I think it would be a very nice and useful addition to the annotation weaponry. It would go along very well with and surely after the design patterns webinars. I started by looking at your initial work and the setup already looks promising.

    1. Thanks Marco for the offer – gladly accepted. Have a look around to see how you would like to help.

      1. For example I can see there isn’t much Javadoc documentation and also there isn’t a Developers Reference Guide which explains how to create new classes (or modify existing ones)…In a word the “standards” which have been followed in creating this project.

  3. Why don’t we add the MVC pattern? We could have something like: Model/View/Controller etc. I just downloaded the code and have to get my head around “the standard” with which you are writing new patterns, but it shouldn’t be too complicated to do. We could add a new Source, called J2EE-PATTERNS (or actually EE-PATTERNS, since we are in EE5)

    1. For now we just did the GoF patterns – of which MVC is not one. We need to be careful that we don’t overwhelm users with too many patterns.

      What would you use as a source for JEE Patterns? I have not seen an updated book yet and quite a few of the J2EE patterns are now obsolete.

      1. I would just hand-pick few well-know enterprise patterns, such as DAO, MVC, Business Delegate, Value Object and I’d use as reference (although obsolete for some uses) Core J2EE PATTERNS – Best practices and Design Strategies

  4. It’s a pity that annotations can’t be extended, otherwise we could have had a DefaultPattern as follows:

    package org.jpatterns.core;

    public @interface DefaultPattern {

    Class[] participants() default {};

    String comment() default “”;

    }

    And then any “sub-annotation in a pattern” could have just “extended the above interface (I mean interface extends interface, don’t get me wrong 🙂 )

  5. Hi Heinz,

    I don’t think the participants array is well placed within annotations.
    >From my understanding, given a pattern, the participants are all those
    “pieces” which make the pattern. Let’s take the Composite as example.
    The participants are:

    – Component
    – Leaf
    – Composite

    I do like the idea of @CompositePattern.Component,
    @CompositePattern.Leaft and @CompositePattern.Composite as annotations
    which go on the various participants. But because we have already define
    at a fine grained level the participants by using the above annotations,
    I think it’s redundant to include also the Class[] participants
    attribute in each annotation. Or maybe I’m missing the point here. Is
    the Class[] participants attribute meant to contain all classes involved
    in this pattern? In this case, still I wouldn’t see the utility of this,
    since the number of classes could potentially be huge. It would be
    better to let tools extract the list of participants by simply
    inspecting the annotations.

    Cheers,

    Marco

  6. Another suggestion on the @CompositePattern annotation: I’d like to write something like: @CompositePattern.DefaultMethod(comment=”Needs to be implemented by sub-classes”) on methods in the “Component” which are there because of the interface but they should be implemented by subclasses.

    Regards,

    Marco

  7. For the above my proposition would be:
    @Retention(value = RetentionPolicy.RUNTIME)
    @Target(value = ElementType.METHOD)
    @Documented
    public @interface DefaultMethod {

    String comment() default “”;
    }

    1. Good idea my friend 🙂 I’ll create a page for contributors on jpatterns.org, which will include some information about GIT, Maven, and the mailing list.

      Heinz

  9. Hi Heinz,

    I would like to contribute to this. I would like to know how this works as in how the code be committed, review process etc.

    Thank you,
    Jiten

Comments are closed.