Other patterns?

Marco Tedone

unread,

Aug 15, 2010, 1:04:25 PM8/15/10

to jpatterns

Why don’t we add some few, well known, enterprise patterns, such as
MVC, DAO, Business Delegate and Value Object? In MVC we could have
something like @ModelViewController and then, within it, @Model, @View
and @Controller, etc. We could add a new Source, called EE-PATTERNS

Dr Heinz M. Kabutz

unread,

Aug 15, 2010, 1:18:40 PM8/15/10

to jpat...@googlegroups.com

Hi Marco,

yes, good idea. I think we should first finish the GoF patterns
though. We still need to add some Java Docs - it would be useful to
discuss how much we should write in there? - and finish the unit tests.
We also need a tool that can test what annotations are defined for which
classes, so that we can do a proper unit test.

My suggestion would be that we finish one set of patterns properly
before moving onto others.

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

On 8/15/10 8:04 PM, Marco Tedone wrote:
> Why donï¿½t we add some few, well known, enterprise patterns, such as

Marco Tedone

unread,

Aug 15, 2010, 1:25:14 PM8/15/10

to jpat...@googlegroups.com

Heinz, do you mean something like a configuration file (text file or
something) which contains the list of "allowed" annotation for each pattern
annotation? Example, for the @CompositePattern:

org.patterns.gof.CompositePattern=Component(@), Leaf(@), Composite(@)

And for the Singleton pattern:

org.patterns.gof.SingletonPattern=Singleton(@), SingletonMethod(@),
Variation(enum={LAZY, EAGER})

Something like that?

Then when the test runs it loads the file, loads the expected configuration
and checks that the actual code contains the expected configuration?

Regards,

Marco

-----Original Message-----
From: jpat...@googlegroups.com [mailto:jpat...@googlegroups.com] On
Behalf Of Dr Heinz M. Kabutz
Sent: 15 August 2010 18:19
To: jpat...@googlegroups.com
Subject: Re: [jpatterns] Other patterns?

Hi Marco,

yes, good idea. I think we should first finish the GoF patterns though. We
still need to add some Java Docs - it would be useful to discuss how much we
should write in there? - and finish the unit tests.
We also need a tool that can test what annotations are defined for which
classes, so that we can do a proper unit test.

My suggestion would be that we finish one set of patterns properly before
moving onto others.

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

On 8/15/10 8:04 PM, Marco Tedone wrote:

> Why don't we add some few, well known, enterprise patterns, such as

> MVC, DAO, Business Delegate and Value Object? In MVC we could have
> something like @ModelViewController and then, within it, @Model, @View
> and @Controller, etc. We could add a new Source, called EE-PATTERNS
>
>

--
You received this message because you are subscribed to the Google Groups
"jpatterns" group.
To post to this group, send email to jpat...@googlegroups.com.
To unsubscribe from this group, send email to
jpatterns+...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jpatterns?hl=en.

Marco Tedone

unread,

Aug 15, 2010, 1:50:57 PM8/15/10

to jpat...@googlegroups.com

Heinz,

What about an XML file like the attached one to describe patterns? If it
seems ok we could define an XML schema for it, and then use JAXB to
transform the pattern definition in POJOs. A test would then have easy life
to read the POJOs and using introspection validate that the classes contain
actually what they are supposed to contain.

In the attached file I described the @CompositePattern and the
@SingletonPattern. Interesting here are: the re-use of the <pattern> element
for participants; the definition of enumerations as "constraints".

Let me know what you think about it.

Regards,

Marco

-----Original Message-----
From: jpat...@googlegroups.com [mailto:jpat...@googlegroups.com] On
Behalf Of Dr Heinz M. Kabutz
Sent: 15 August 2010 18:19
To: jpat...@googlegroups.com
Subject: Re: [jpatterns] Other patterns?

Hi Marco,

yes, good idea. I think we should first finish the GoF patterns though. We
still need to add some Java Docs - it would be useful to discuss how much we
should write in there? - and finish the unit tests.
We also need a tool that can test what annotations are defined for which
classes, so that we can do a proper unit test.

My suggestion would be that we finish one set of patterns properly before
moving onto others.

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

On 8/15/10 8:04 PM, Marco Tedone wrote:

> Why don't we add some few, well known, enterprise patterns, such as

> MVC, DAO, Business Delegate and Value Object? In MVC we could have
> something like @ModelViewController and then, within it, @Model, @View
> and @Controller, etc. We could add a new Source, called EE-PATTERNS
>
>

--

pattern-documentation-example.xml

Michael Hunger

unread,

Aug 15, 2010, 2:15:59 PM8/15/10

to jpat...@googlegroups.com

heinz could you please explain what you meant with the test?

marco i dont see the value of this xml serialization of the annotation structure. that is what we have the javacode for. if you go for such an approach you would generate the annotation sources from that.
but then you go to string hell. i prefer code completion, static checks etc that's why I write code no a metalanguage that gets translated to code. and at the same time being x times as verbose as the code.

if we want to verify some basic annotation structure we could write a ten line checker that uses reflection or ASM.

Michael

Von meinem iPad gesendet

> <pattern-documentation-example.xml>

Marco Tedone

unread,

Aug 15, 2010, 2:36:27 PM8/15/10

to jpat...@googlegroups.com

Pheeww Mike, that's a relief :-)

Michael Hunger

unread,

Aug 15, 2010, 2:46:22 PM8/15/10

to jpat...@googlegroups.com

So you were just teasing us?

Cheers

Michael

Marco Tedone

unread,

Aug 15, 2010, 4:31:12 PM8/15/10

to jpat...@googlegroups.com

No, I was going along Heinz's suggestion of having a tool to test which
annotations were defined for which class. I probably went a bit too far in
the interpretation. Heinz, what did you have in mind?

Michael Hunger

unread,

Aug 15, 2010, 4:34:31 PM8/15/10

to jpat...@googlegroups.com

that exactly was my question, what does

"a tool to test which annotations were defined for which class"

mean ?

I don't know.

Michael

Dr Heinz M. Kabutz

unread,

Aug 16, 2010, 11:38:50 AM8/16/10

to jpat...@googlegroups.com

Something simple, probably based on reflection. One of the suggestions made, however, was to change the RetentionType to Class - this way our users do not have dependencies to our classes at runtime. I would prefer to keep the retentiontype == runtime, so that we can write some simple reflection tools that can tell us what elements have patterns annotations.

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

Marco Tedone

unread,

Aug 16, 2010, 11:47:16 AM8/16/10

to jpat...@googlegroups.com

+1 on keeping it at runtime.

From: "Dr Heinz M. Kabutz" <he...@javaspecialists.eu>

Sender: jpat...@googlegroups.com

Date: Mon, 16 Aug 2010 18:38:50 +0300

To: <jpat...@googlegroups.com>

ReplyTo: jpat...@googlegroups.com

Michael Hunger

unread,

Aug 16, 2010, 11:50:33 AM8/16/10

to jpat...@googlegroups.com

I found ASM which works on the classfiles a clean and very fast solution
too.

We can also use JavaParser or ANTLR for parsing the source that works too.

Cheers Michael

On Mon, 16 Aug 2010 18:38:50 +0300, "Dr Heinz M. Kabutz"
<he...@javaspecialists.eu> wrote:
> Something simple, probably based on reflection.� One of the
> suggestions made, however, was to change the RetentionType to Class -
this
> way our users do not have dependencies to our classes at runtime.�� I
> would prefer to keep the retentiontype == runtime, so that we can write
> some simple reflection tools that can tell us what elements have
patterns
> annotations.
>
> Regards
>
> Heinz
> --
> Dr Heinz M. Kabutz (PhD CompSci)
> Author of "The Java(tm) Specialists' Newsletter"
> Sun Java Champion

> http://www.javaspecialists.eu [1]

> [8]:

>
> Heinz,
>
> What about an XML file like the attached one to describe patterns? If
> it seems ok we could define an XML schema for it, and then use JAXB
> to transform the pattern definition in POJOs. A test would then have
> easy life to read the POJOs and using introspection validate that the
> classes contain actually what they are supposed to contain.
>
> In the attached file I described the @CompositePattern and the
> @SingletonPattern. Interesting here are: the re-use of the
>

> http://www.javaspecialists.eu [12]

> Tel: +30 69 72 850 460
> Skype: kabutz
>
> On 8/15/10 8:04 PM, Marco Tedone wrote:
>
> Why don't we add some few, well known, enterprise patterns, such as
> MVC, DAO, Business Delegate and Value Object? In MVC we could have
> something like @ModelViewController and then, within it, @Model,
> @View and @Controller, etc. We could add a new Source, called
> EE-PATTERNS
>
> --
> You received this message because you are subscribed to the Google
> Groups "jpatterns" group.

> To post to this group, send email to jpat...@googlegroups.com [13].

> To unsubscribe from this group, send email to

> jpatterns+...@googlegroups.com [14].

> For more options, visit this group at

> http://groups.google.com/group/jpatterns?hl=en [15].

>
> --
> You received this message because you are subscribed to the Google
> Groups
>
> "jpatterns" group.
>

> To post to this group, send email to jpat...@googlegroups.com [16].

> To unsubscribe from this group, send email to
>

> jpatterns+...@googlegroups.com [17].

>
> For more options, visit this group at
>

> http://groups.google.com/group/jpatterns?hl=en [18].

>
> --
> You received this message because you are subscribed to the Google
> Groups "jpatterns" group.

> To post to this group, send email to jpat...@googlegroups.com [19].

> To unsubscribe from this group, send email to

> jpatterns+...@googlegroups.com [20].

> For more options, visit this group at

> http://groups.google.com/group/jpatterns?hl=en [21].

>
> --
> You received this message because you are subscribed to the Google
Groups
>
> "jpatterns" group.
>

> To post to this group, send email to jpat...@googlegroups.com [22].

> To unsubscribe from this group, send email to
>

> jpatterns+...@googlegroups.com [23].

>
> For more options, visit this group at
>

> http://groups.google.com/group/jpatterns?hl=en [24].

>
> --
> You received this message because you are subscribed to the Google
Groups
> "jpatterns" group.
> To post to this group, send email to jpat...@googlegroups.com.
> To unsubscribe from this group, send email to
> jpatterns+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/jpatterns?hl=en.
>
>

Reply all

Reply to author

Forward