Patterns
ag...@planet.nl
I thought it wouldn't hurt to get a list of patterns. So, I started by
summing up the patterns in GoF and POSA.
GoF patterns :
Behavioral patterns
Chain of responsibility
Command
Interpreter
Iterator
Mediator
Memento
Observer
State
Strategy
Template method
Visitor
Creational patterns
Abstract factory
Builder
Factory method
Prototype
Singleton
Structural patterns
Adapter
Bridge
Composite
Decorator
Facade
Flyweight
Proxy
-------------------------------------------------------------------------
Pattern-oriented Software Architecture(Buschmann et.al.)
Whole-Part
Master-Slave
Proxy
Command Processor
View Handler
Counted Pointer
Forward-Receiver
Client-Dispatcher-Server
Publisher-Subscriber
Layers
Pipes and Filters
Blackboard
Broker
MVC
Presentation-Abstraction-Control
Microkernel
Reflection
Dr Heinz M. Kabutz
my suggestion is that we start by just doing all the GoF patterns and
perhaps 3 of the PoSA patterns, so that we can see that they will be
possible. I would be worried about overloading the vocabulary at this
point. I'll have a look at the PoSA book later, but is their Proxy
similar to the GoF Proxy?
Michael, when are you coming back from your leave? We are going
completely crazy here with the magnets that you gave us :-) We spend
hours (literally) trying to construct all sorts of shapes. I tried the
wand, but could not get used to it. Also, we don't have very many IR
devices in our home. Maybe I'll take it to JavaOne and give it to
someone who will find more use for it?
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
Michael Hunger
I'm back from my leave now, sorry, it took a bit longer than expected.
Your suggestion is sensible. Let's share the work and go through that this week.
Glad you like the magnets, I have another 20.000 around, so if you need more, just tell me.
I recently did a really crazy shape, one that I saw on youtube:
http://www.youtube.com/watch?v=o9eiS1i4lqY
and
http://www.youtube.com/watch?v=5HNJB0vMq6w
this one is also cool
http://www.youtube.com/watch?v=wOv0AkphLhE
Good idea with the wand but first we should perhaps get it working for your macbook, so you can give it away after using it in your talk at java one :)
I put one of the magnetic balls at the end of the wand and now have it dangling from the whiskey shelf above our couch, so I just grab it when I need a remote and put it back right afterwards. Works great.
Cheers
Michael
Michael Hunger
Back to the core:
I looked at your approach and I like it, the only drawback is that I have to look at the annotation elements to see the role.
That's why I'll try a different approach with the "test" command pattern.
Have the roles be declared inside a main "CommandPattern" annotation.
@interface CommandPattern {
@interface Invoker {
}
}
i.e. CommandPattern.Invoker
so you can either declare this structure being part of the CommandPattern in general (w/o) specifying details, or you could do detailed specs for the roles.
(we could also leave the first part out by not defining a @Target (imho)
WDYT ?
I would also like to keep the annotation on the pattern annotation that provides metadata about the Pattern.
Things that we could include there:
DesignPattern
Pattern Type
Source (I'm not sure if the packaging (although I'd keep that) is such an good way to document the source
Doc-URL (e.g. wikipedia entry or whatever)
refactorings (aka refactoring to patterns) that can lead to this pattern
Annotation[] relatedPatterns
more ... (things taken from the pattern formats that are around there)
Michael Hunger
also got all tests running, so that maven can run tests and install.
added easymock for connection testing.
Pushed all to github.
Cheers
Michael
Dr Heinz M. Kabutz
can we standardize on date formats in the code? Either 2010-08-09 (yyyy-MM-dd) or 9 Aug 2010? I usually don't write dates into my code.
Also, I prefer two spaces for indentation, whereas you are using 4. I've been using 2 for many years, but don't mind changing to 4 for this project. However, we need to be consistent. Do you know how to export the code formatting rules from IntelliJ so we can include them in the project?
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
Michael Hunger
Could you reformat the project with your settings and push that?
Michael
Dr Heinz M. Kabutz
I usually don't write dates nor authors into my source code as comments. For ego-less programming it should not matter who wrote what. Also, all of that information is available in the GIT source control in far more detail than I would care to maintain manually. Anyway, I've complied to your standard for now, as we are all trying to figure out how to do this.
Now, some comments about the CommandPattern annotation.
1. I think we should make all our annotations Retention RUNTIME. The reason is that they are then always available, even during reflection. Do you know of a technical reason why we should rather use CLASS?
2. I love the inner annotations approach. @CommandPattern.Invoker reads much better than @CommandPattern(role = CommandPatternType.INVOKER)
3. I think that users should find it very easy to specify information, so every attribute should have defaults.
4. I don't like it that we are repeating common information over and over. For example the attribute "comment" and in my annotations "participants". How about if we define a separate annotation for additional information that you might want to define for your pattern? For example
@CommandPattern.Invoker
@PatternInfo(comment="This is a terrible pattern, always results in lots of classes", participants={MyReceiver.class, SewerageTank.class})
5. In my AdapterPattern annotation, I have different types of adapters: object, class, dynamic. Any bright ideas of how / where to specify that if we use inner annotations? Or should we leave out that information altogether?
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
Dr Heinz M. Kabutz
Could you please check out your CommandPattern.java file and have a look at my comments in the file?
Also, I think all annotations that we define should have the @Documented meta-annotation.
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
Michael Hunger
I would suggest we create a FileTemplate in IDEA for creating new
Annotations, then we can keep the common format and won't forget anything.
I'm at the client right, now so I'll do this this evening.
Cheers
Michael
On Mon, 09 Aug 2010 12:03:31 +0300, "Dr Heinz M. Kabutz"
<he...@javaspecialists.eu> wrote:
> Some more comments.
>
> Could you please check out your CommandPattern.java file and have a
look
> at my comments in the file?
>
> Also, I think all annotations that we define should have the
@Documented
> meta-annotation.
>
> Regards
>
> Heinz
> --
> Dr Heinz M. Kabutz (PhD CompSci)
> Author of "The Java(tm) Specialists' Newsletter"
> Sun Java Champion
> http://www.javaspecialists.eu [1]
> Tel: +30 69 72 850 460
> Skype: kabutz
>
> On 8/9/10 11:08 AM, Michael Hunger wrote:
> Sure, on both, I can remove the date and adapt the code intendation, I
> switch mine to 2.
>
> Could you reformat the project with your settings and push that?
>
> Michael
>
> Am 09.08.2010 um 09:51 schrieb Dr Heinz M. Kabutz:
>
> Hi Michael,
>
> can we standardize on date formats in the code? Either 2010-08-09
> (yyyy-MM-dd) or 9 Aug 2010? I usually don't write dates into my code.
>
> Also, I prefer two spaces for indentation, whereas you are using 4. I've
> been using 2 for many years, but don't mind changing to 4 for this
project.
> However, we need to be consistent. Do you know how to export the code
> formatting rules from IntelliJ so we can include them in the project?
> Regards
>
> Heinz
> --
> Dr Heinz M. Kabutz (PhD CompSci)
> Author of "The Java(tm) Specialists' Newsletter"
> Sun Java Champion
>
> http://www.javaspecialists.eu [2]
Michael Hunger
we can leave of author and date information.
It is just that I've seen it in the JDK, many libs etc. And people don't
have access to the git repo when just reading javadoc :)
Regarding the information repetition:
Normally you would annotate the annotation (the pattern annotation) for
that
Most people are not familiar with the annotation on annotation approach.
That's why most
uses rather have an annotation as parameter
@CommandPattern(info = @PatternInfo(comment="",....))
but that means you still have to have at least one duplicated parameter.
Regarding the adapter, as this is a part of the pattern itself, I would
create separate pattern annotations for those.
Michael
> http://www.javaspecialists.eu [1]
> Tel: +30 69 72 850 460
> Skype: kabutz
>
> On 8/9/10 11:08 AM, Michael Hunger wrote:
> Sure, on both, I can remove the date and adapt the code intendation, I
> switch mine to 2.
>
> Could you reformat the project with your settings and push that?
>
> Michael
>
> Am 09.08.2010 um 09:51 schrieb Dr Heinz M. Kabutz:
>
> Hi Michael,
>
> can we standardize on date formats in the code? Either 2010-08-09
> (yyyy-MM-dd) or 9 Aug 2010? I usually don't write dates into my code.
>
> Also, I prefer two spaces for indentation, whereas you are using 4. I've
> been using 2 for many years, but don't mind changing to 4 for this
project.
> However, we need to be consistent. Do you know how to export the code
> formatting rules from IntelliJ so we can include them in the project?
> Regards
>
> Heinz
> --
> Dr Heinz M. Kabutz (PhD CompSci)
> Author of "The Java(tm) Specialists' Newsletter"
> Sun Java Champion
>
> http://www.javaspecialists.eu [2]
Dr Heinz M. Kabutz
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
Michael Hunger
and with the JetBrains guys at our disposal :) we could for instance get
their UML plugin recognize the annotations?
What would you put in the other packages ?
Cheers Michael
On Mon, 09 Aug 2010 16:06:46 +0300, "Dr Heinz M. Kabutz"
<he...@javaspecialists.eu> wrote:
> Should we perhaps use org.jpatterns.annotations as our root
> package? Hopefully we can get enough traction to eventually build some
> interesting tools around the annotations.
>
> Regards
>
> Heinz
> --
> Dr Heinz M. Kabutz (PhD CompSci)
> Author of "The Java(tm) Specialists' Newsletter"
> Sun Java Champion
> http://www.javaspecialists.eu [1]
> Tel: +30 69 72 850 460
> Skype: kabutz
>
> http://www.javaspecialists.eu [3] [1]
Dr Heinz M. Kabutz
org.jpatterns.tools
org.jpatterns.?
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
Michael Hunger
somewhere else.
We should also do a minimal jar (just few k) that only contains the
annotations and nothing else.
Michael
On Mon, 09 Aug 2010 17:24:05 +0300, "Dr Heinz M. Kabutz"
<he...@javaspecialists.eu> wrote:
> org.jpatterns.annotations
> org.jpatterns.tools
> org.jpatterns.?
>
> Regards
>
> Heinz
> --
> Dr Heinz M. Kabutz (PhD CompSci)
> Author of "The Java(tm) Specialists' Newsletter"
> Sun Java Champion
> http://www.javaspecialists.eu [1]
> Tel: +30 69 72 850 460
> Skype: kabutz
>
> On 8/9/10 4:49 PM, Michael Hunger wrote:
> I hope so too,
> and with the JetBrains guys at our disposal :) we could for instance
get
> their UML plugin recognize the annotations?
>
> What would you put in the other packages ?
>
> Cheers Michael
>
> On Mon, 09 Aug 2010 16:06:46 +0300, "Dr Heinz M. Kabutz"
> [2] wrote:
>
> Should we perhaps use org.jpatterns.annotations as our root
> package? Hopefully we can get enough traction to eventually build some
> interesting tools around the annotations.
>
> Regards
>
> Heinz
> --
> Dr Heinz M. Kabutz (PhD CompSci)
> Author of "The Java(tm) Specialists' Newsletter"
> Sun Java Champion
> http://www.javaspecialists.eu [3] [1]
> Tel: +30 69 72 850 460
> Skype: kabutz
>
Alex Gout
Dr Heinz M. Kabutz
Could you have a look at the pom.xml file? I had to fiddle to get it to work with Java 5 sources. I'm not a Maven expert so may have put in too much fluff.
Also, could you change it so that the jpatterns-1.0.jar file is stuck in the root directory, this way it can be updated whenever we run Maven?
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
Alex Gout
I made a first attempt for an annotation. I took a simple one
(Singleton) and created a test also. Creating this test, I was not
sure what really to test...
Any advice is very welcome.
For the singletone pattern I chose a variation EAGER and LAZY, but
maybe I should have taken volatile, synchronized, singletonholder,
other? Or add threadsafe and not threadsafe as choice?
Please let me know your thoughts.
Annotation:
package org.jpatterns.gof.singleton;
=========
import org.jpatterns.*;
import java.lang.annotation.*;
/**
* @author Alex Gout
* @since 2010-08-08
*/
@Retention(value = RetentionPolicy.RUNTIME)
@Target(value = ElementType.TYPE)
@Documented
@DesignPattern(type = Type.CREATIONAL)
public @interface SingletonPattern {
Variation variation() default Variation.LAZY;
@Retention(value = RetentionPolicy.RUNTIME)
@Target(value = ElementType.METHOD)
@Documented
public @interface SingletonMethod {
}
public enum Variation {
LAZY, EAGER
}
}
============
Singleton mock:
package org.jpatterns.gof.singleton;
/**
* @author Alex Gout
* @since 2010-08-09
*/
@SingletonPattern(variation = SingletonPattern.Variation.EAGER)
public class Singleton {
private static Singleton INSTANCE = new Singleton();
private Singleton(){
}
@SingletonPattern.SingletonMethod
public static Singleton getInstance(){
return INSTANCE;
}
}
==========
test class:
package org.jpatterns.gof.singleton;
import org.junit.Test;
import static junit.framework.Assert.assertSame;
/**
* @author Alex Gout
* @since 2010-08-08
*/
public class SingletonTest {
@Test
public void testSameInstance() {
Singleton singleton = Singleton.getInstance();
Singleton singleton2 = Singleton.getInstance();
assertSame(singleton, singleton2);
Dr Heinz M. Kabutz
I think the LAZY / EAGER variations are enough. Nice work :-) Remember
to "git push" your changes up to the server.
I'd like to add some tests to differentiate between eager and lazy
singletons. Something like:
package org.jpatterns.gof.singleton;
import org.junit.Test;
import static junit.framework.Assert.assertSame;
/**
* @author Alex Gout
* @since 2010-08-08
*/
public class EagerSingletonTest {
@SingletonPattern(variation = SingletonPattern.Variation.EAGER)
public class EagerSingleton {
private final static EagerSingleton INSTANCE = new EagerSingleton();
private EagerSingleton() { }
@SingletonPattern.SingletonMethod
public static EagerSingleton getInstance(){
return INSTANCE;
}
}
@Test
public void testEagerness() {
assertNotNull(EagerSingleton.INSTANCE);
assertNotNull(EagerSingleton.getInstance());
}
}
and
package org.jpatterns.gof.singleton;
import org.junit.Test;
import static junit.framework.Assert.assertSame;
/**
* @author Alex Gout
* @since 2010-08-08
*/
public class LazySingletonTest {
@SingletonPattern(variation = SingletonPattern.Variation.LAZY)
public class LazySingleton {
private volatile static LazySingleton INSTANCE;
private LazySingleton() { }
@SingletonPattern.SingletonMethod
public static LazySingleton getInstance(){
LazySingleton result = INSTANCE;
if (result == null) {
synchronized(LazySingleton.class) {
result = INSTANCE;
if (result == null) {
INSTANCE = result = new LazySingleton();
}
}
}
return result;
}
}
@Test
public void testLaziness() {
assertNull(LazySingleton.INSTANCE);
assertNotNull(LazySingleton.getInstance());
assertNotNull(LazySingleton.INSTANCE);
}
}
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
Dr Heinz M. Kabutz
I've created empty annotations for all of the GoF patterns (except for
Singleton, waiting for Alex to submit his).
Now that we are storing the enums inside the annotations, we have lots
of packages with a single class. I think we should get rid of the
subpackages and store all the GoF patterns in org.jpatterns.gof. Any
objections?
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
Michael Hunger
Michael
> --
> 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.
>
Alex Gout
No objections, good idea.
-- Alex
Op 9 aug 2010, om 20:12 heeft Dr Heinz M. Kabutz het volgende
geschreven:
> Hi chaps,
Alex Gout
I was struggling with Git, I got some nasty connection errors. Now I
see my commit of the Singleton actually worked, but somehow I managed
to get a merge though, which I really cannot explain. Anyhow... I hope
this is not too serious. First thing I did was pulling Heinz'
additions, then I tried to commit mine.
Sorry.. I hope I didn't make a bad mistake!
Op 9 aug 2010, om 20:12 heeft Dr Heinz M. Kabutz het volgende
geschreven:
> Hi chaps,
Alex Gout
I will update the tests tomorrow, or you can do it if you still have
time ;)
-- Alex
Op 9 aug 2010, om 19:33 heeft Dr Heinz M. Kabutz het volgende
geschreven:
> Hi Alex,
Dr Heinz M. Kabutz
directory that we can delete or move to perhaps a doc directory?
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
Dr Heinz M. Kabutz
too bad.
You should use the ssh connection, rather than http.
g...@github.com:jexp/jpatterns.git
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
Michael Hunger
initial clone:
git clone g...@github.com:jexp/jpatterns.git
then:
do your local changes & local commits (repeat as often as you'd like):
git add <files> or git add .
git commit -m"message"
if you want to share/push changes
first pull last public state
(--rebase is better than normal pull because it first fetches the clean remote branch and then _reapplies_ your commits one after another on top of that, instead of doing a big merge of the remote branch on top of your changed HEAD state.
git pull --rebase origin master
then push your changes
git push origin master
Done.
Cheers
Michael
Michael Hunger
You did correctly with the maven for source/test versions.
If I understood you correctly you want one jar in the root directory? What for?
It is in target after maven install and also in your local repository,
so if you ever want to use jpatterns in a different project you just include the dependency in your pom (or ivy, gradle, grapes or whatever build tool) like
<dependency>
<groupId>org.jpatterns</groupId>
<artifactId>jpatterns</artifactId>
<version>1.0</version>
</dependency>
Nothing else needed.
We should look into pushing it to mvnrepository.com but I have to look that up, then it is globally available.
Michael
Michael Hunger
another thing: do we want to keep the gifs in the source directory or do we want to do a separate directory with them.
We should also use javadoc in the annotations and there include an <img src=""/> to the source of the images so that they'll be included in generated javadoc.
(there are also maven plugins for that if we want to provide javadoc besides the jar file)
Michael
Am 09.08.2010 um 22:49 schrieb Michael Hunger:
Michael Hunger
Good question: I'd rather repeat what is in the books because then people could reuse jpatterns (annotations + javadoc) as a compact DesignPatterns catalogue that is always at hand, within your IDE.
And people don't have to write that themselves but they can look it up if they want to.
Btw. is there a really good site for documented design patterns out there? (Besides wikipedia?), perhaps we should/could create sth like that at jpatterns.org ? (just an idea for community involvement).
Michael
Michael Hunger
I would merge them, to PatternInfo.
and I would set their target to Annotation, so that the Pattern annotation itself is documented.
WDYT ?
Michael
Michael Hunger
jpatterns.core
and the PatternComment + PatternParticipants to jpatterns.doc
I added javadoc to the pom, so you can mvn javadoc:javadoc for generating javadoc.
we could also create a maven site that is automatically updated at mvn release and could contain javadoc, jars to download, mvn info etc. (hosted at jpatterns.org)
I would like to move the build number to 0.1 or sth like that and also have the current dev labeled as snapshot.
We can then do a release with mvn release (that increases the build # and pushes non-snapshot versions to mvnrepository).
Michael
Dr Heinz M. Kabutz
what I'd like to do is give our users one jar file to download, instead of having to build it themselves.
There must be better ways of doing that though. Does github have support for managing the distribution of builds?
Do you think we should start with version 1.0 or perhaps 0.1 to indicate that it is still in the experimental stage and subject to major changes?
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
Dr Heinz M. Kabutz
We should probably also have some javadoc for the 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
Michael Hunger
They have to be in src/main/ressources for maven to copy them to the target.
Exactly that was what I meant.
Sure there is a simple way to build it and store it in a certain location.
The question is at what times do we want to build it? Everytime or just at "release" times.
If we build it at release times and push it to mvnrepository.com there is a simple way for people to download just the jar.
Here is a howto:
http://maven.apache.org/guides/mini/guide-central-repository-upload.html
what license do we want to use for jpatterns?
Michael
Dr Heinz M. Kabutz
I will move the classes to the correct packages as you suggested.
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
Michael Hunger
But for external people release versions should be enough.
Michael
You just have to install maven. But don't do that now.
ag...@planet.nl
I always use wikipedia for reference to patterns, and what else uncle
google gives me. If we could have our own set of documentation, liek
you said we could distribute that as doc to have handy in your IDE.. I
like the idea. We could then also add a link to jpatterns for even
extended documentation or example(code).
I would not have the gifs in the sourcetree itself, but in a separate
package. I feel it gives more freedom to change/relocate/extend all
this graphical documention in one go. Also, this prepares the package
structure for adding others sorts of documentation.
Thanks for your explanation of the Git workcycle. I read a short
manual and the refcard from DZone, but your information is the link I
was missing ;)
I tried the ssh url, but I got some error about a certificate. I will
take a closer look at it later.
Unfortunatly I cant invest as much effort as you guys, I hope that is
not a problem ;)
You go fast....
-- Alex
On Aug 9, 11:17 pm, Michael Hunger <Michael.Hun...@jexp.de> wrote:
> I would also suggest moving DesignPattern and the three enums to
> jpatterns.core
>
> and the PatternComment + PatternParticipants to jpatterns.doc
>
> I added javadoc to the pom, so you can mvn javadoc:javadoc for generating javadoc.
>
> we could also create a maven site that is automatically updated at mvn release and could contain javadoc, jars to download, mvn info etc. (hosted at jpatterns.org)
>
> I would like to move the build number to 0.1 or sth like that and also have the current dev labeled as snapshot.
>
> We can then do a release with mvn release (that increases the build # and pushes non-snapshot versions to mvnrepository).
>
> Michael
>
> Am 09.08.2010 um 23:12 schrieb Michael Hunger:
>
> > Regarding PatternComment & PatternParticipants:
>
> > I would merge them, to PatternInfo.
>
> read more »
Dr Heinz M. Kabutz
I prefer:
@PatternParticipants(String.class)
@PatternComment("This code is an obtuse reverse anti-pattern")
to
@PatternInfo(participants=String.class, comment="This code is an obtuse reverse anti-pattern")
I tried setting the target to Annotation only, but that would only apply to the annotation class itself, IOW
public @interface MyAnnotation {}
Not to where we use it.
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
Dr Heinz M. Kabutz
Yes, I will move the gifs somewhere else. Now that all the patterns are in one directory it's looking ugly.
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
Dr Heinz M. Kabutz
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
Michael Hunger
Sorry then I was thinking in the wrong terms about ElementType.ANNOTATION. (not good) having metadata on top of metadata would have been much cooler.
Michael
Dr Heinz M. Kabutz
What license do you guys suggest? LPGL?
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
Michael Hunger
Hmm it seems to be more complicated than this for maven central upload :(
They have a 4 week delay for manual updates. otherwise one is required to use one of the public forges.
Currently approved Forges:
• Apache (open to Apache Projects)
• Codehaus (open to Codehaus Projects)
• Sonatype Forge (open to any OSS Project)
• Fusesource Forge (Focused on FUSE related projects)
I'd suggest codehaus but have to look if they integrate with github (otherwise we would have to use the git-svn bridge to update their repo).
The advantage of that is that the public forges have automated builds and we don't have to setup anything.
Although sonatype also reads good: http://nexus.sonatype.org/oss-repository-hosting.html (They do just repo hosting that is synced to mvn-central).
Michael
Dr Heinz M. Kabutz
Yes, let's set up a project on Codehaus and use the git-svn bridge. I'm beginning to like GIT and don't really want to go back to SVN :-)
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
Dr Heinz M. Kabutz
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
Michael Hunger
http://junit.sourceforge.net/cpl-v10.html
Michael
But perhaps your're right first and we just add the jar to github and serve it from there as first step.
and do the repo-publishing stuff a bit later, we have to finish the patterns first.
Michael
Dr Heinz M. Kabutz
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/10/10 12:17 AM, Michael Hunger wrote:
Michael Hunger
Michael
On Tue, 10 Aug 2010 14:31:41 +0300, "Dr Heinz M. Kabutz"
<he...@javaspecialists.eu> wrote:
> Moved the classes as suggested and added UML to some of the javadocs,
> together with intents. Also filled in the related for some annotations.
>
> Regards
>
> Heinz
> --
> Dr Heinz M. Kabutz (PhD CompSci)
> Author of "The Java(tm) Specialists' Newsletter"
> Sun Java Champion
> http://www.javaspecialists.eu [1]
> Tel: +30 69 72 850 460
> Skype: kabutz
>
> We should also use javadoc in the annotations and there include an to
the
> source of the images so that they'll be included in generated javadoc.
>
> (there are also maven plugins for that if we want to provide javadoc
> besides the jar file)
>
> Michael
>
> Am 09.08.2010 um 22:49 schrieb Michael Hunger:
>
> basic workflow should be sth like the following:
>
> initial clone:
> git clone g...@github.com:jexp/jpatterns.git [2]
>
> then:
>
> do your local changes
> http://www.javaspecialists.eu [7] [1]
> Tel: +30 69 72 850 460
> Skype: kabutz
>
> On 8/9/10 4:49 PM, Michael Hunger wrote:
> I hope so too,
> and with the JetBrains guys at our disposal :) we could for instance
>
> get
>
> their UML plugin recognize the annotations?
>
> What would you put in the other packages ?
>
> Cheers Michael
>
> On Mon, 09 Aug 2010 16:06:46 +0300, "Dr Heinz M. Kabutz"
> [2] wrote:
>
> Should we perhaps use org.jpatterns.annotations as our root
> package? Hopefully we can get enough traction to eventually build some
> interesting tools around the annotations.
>
> Regards
>
> Heinz
> --
> Dr Heinz M. Kabutz (PhD CompSci)
> Author of "The Java(tm) Specialists' Newsletter"
> Sun Java Champion
> http://www.javaspecialists.eu [8] [3] [1]
> To post to this group, send email to jpat...@googlegroups.com [9].
> To unsubscribe from this group, send email to
> jpatterns+...@googlegroups.com [10].
> For more options, visit this group at
> http://groups.google.com/group/jpatterns?hl=en [11].
>
> --
> 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 [12].
> To unsubscribe from this group, send email to
> jpatterns+...@googlegroups.com [13].
> For more options, visit this group at
> http://groups.google.com/group/jpatterns?hl=en [14].
>
> --
> 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 [15].
> To unsubscribe from this group, send email to
> jpatterns+...@googlegroups.com [16].
> For more options, visit this group at
> http://groups.google.com/group/jpatterns?hl=en [17].
>
> --
> 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 [18].
> To unsubscribe from this group, send email to
> jpatterns+...@googlegroups.com [19].
> For more options, visit this group at
> http://groups.google.com/group/jpatterns?hl=en [20].
>
> --
> 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 [21].
> To unsubscribe from this group, send email to
> jpatterns+...@googlegroups.com [22].
> For more options, visit this group at
> http://groups.google.com/group/jpatterns?hl=en [23].
>
> --
> 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.
>
>
> Links:
> ------
> [1] http://www.javaspecialists.eu
> [2] mailto:g...@github.com:jexp/jpatterns.git
> [3] mailto:g...@github.com:jexp/jpatterns.git
> [4] http://www.javaspecialists.eu
> [5] http://www.javaspecialists.eu
> [6] mailto:he...@javaspecialists.eu
> [7] http://www.javaspecialists.eu
> [8] http://www.javaspecialists.eu
> [9] mailto:jpat...@googlegroups.com
> [10] mailto:jpatterns+...@googlegroups.com
> [11] http://groups.google.com/group/jpatterns?hl=en
> [12] mailto:jpat...@googlegroups.com
> [13] mailto:jpatterns+...@googlegroups.com
> [14] http://groups.google.com/group/jpatterns?hl=en
> [15] mailto:jpat...@googlegroups.com
> [16] mailto:jpatterns+...@googlegroups.com
> [17] http://groups.google.com/group/jpatterns?hl=en
> [18] mailto:jpat...@googlegroups.com
> [19] mailto:jpatterns+...@googlegroups.com
> [20] http://groups.google.com/group/jpatterns?hl=en
> [21] mailto:jpat...@googlegroups.com
> [22] mailto:jpatterns+...@googlegroups.com
> [23] http://groups.google.com/group/jpatterns?hl=en
Alex Gout
X-Mailer: Apple Mail (2.936)
Return-Path: ag...@planet.nl
X-OriginalArrivalTime: 10 Aug 2010 11:53:09.0001 (UTC) FILETIME[99F42790:01CB3882]
Hi,
Yes I agree. It's a new project, lets first set it up. Many details
are in the process of evolution, let them settle in first.
I'm curious why JUnit would have such a special license?
Alex Gout
Awesome, the work you guys do in hours. Anyway, I set up my public rsa
key, so I can use the ssh connection now. Thx Heinz for completing the
Singleton tests, looks very good. Also, in the proxy example I noticed
the Lutefisk again. I'm just wondering if it's the same thing I ate
(at least tried to eat) in Sweden last summer. It was called
Sürstrumming. It's herring in a tin, that has fermented for at least
three months. They open it when the tin looks swollen from the gasses
inside. Can't open it inside, because the house will smell for weeks.
Well, I tried to eat it the Swedish way, with potatoes, onions, tomato
and some creme-fresh on bread.. but no luck. Just fry me a chicken...
I like GitHub. Im also considering putting my private Seam test
projects there.
Anyway, I will take a look at all your work.
Regards,
Alex
> .
>
Dr Heinz M. Kabutz
like this for many years. Just never got the push to actually do it.
I've filled in all the inner annotations for our patterns, next we need
to do some unit tests for these patterns. This will hopefully show up
some weaknesses in our approach.
So far our unit tests have been a bit weak in my opinion. Any
suggestions on how we could improve them? Perhaps we will need to write
a tool that can extract the patterns from a set of classes and then
verify against that?
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
Dr Heinz M. Kabutz
our jpatterns.org website every 10 minutes. This means we should only
check in code that works :-)
We will improve this once we figure out how to integrate with something
like codehaus.
Downloads: http://www.jpatterns.org/?page_id=29
Javadocs: http://www.jpatterns.org/?page_id=27
Regards
Heinz
--
Dr Heinz M. Kabutz (PhD CompSci)
Author of "The Java(tm) Specialists' Newsletter"
Sun Java Champion
http://www.javaspecialists.eu
Michael Hunger
The question is, what do we want to show with the Tests? What examples do you use in the course for the patterns.
Perhaps we should take a sample application, refactor it to use patterns and annotate them.
Just had another idea (actually two).
I read somewhere that Kent and Erich tried to put as many patterns as possible into Junit (at least version 3.x).
So perhaps we should just take the JUnit source code and annotate it with our annotations, use a sourcecode-publishing tool to put it on the web.
Another example are the Game of Life from the book "Holub on Patterns" where he really crammed all known patterns in the poor game of life.
(He's got another example in the book that is an in memory database, which is actually quite nice).
So perhaps we can ask Kent (I can do this) or Allan Holub to use their code for the application of the annotations.
Michael
Dr Heinz M. Kabutz
I will use add some of the examples from my course into the tests also.
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
Michael Hunger
you could change the cron job, that it only updates the file if maven ends with an exit code of 0.
As I added the maven bundle plugin, we also have the bundle-jar that contains, source, javadoc and class jar.
Michael
Michael Hunger
Michael
>>>>> .
>>>>> 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
>>>>> .
>>>>>
>>>>>
>>>>>
>>> --
>>> 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
Dr Heinz M. Kabutz
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
Alex Gout
Yes, thats why I wondered what I should put in the Singleton tests.
Every test I see now, does not actually test the usefuless of the
annotation. I think the real added value and indeed weaknesses of this
approach will show when they come to life when you can get information
concerning the used patterns compile- or runtime. Maybe even tools
like findbugs would be able to detect weaknesses in a pattern approach
used.
But I agree the first step is applying the annotations on real-life
code and see where the gaps start to show.
-- Alex
> .
>
Dr Heinz M. Kabutz
1.
jonnybbb says:
August 10, 2010 at 9:18 pm (Edit)
I really like the inner annotations approach, although it might have one downside: The user does not have code completion hints to find out that a @PatternParticipants should be used in conjunction with the concrete pattern.
I already started using it for the exercises! Great.
Reply
2.
admin says:
August 10, 2010 at 9:27 pm (Edit)
Yes, we agree. Unfortunately annotations do not have inheritance, which means we would have to include the Class[] participants() default {}; attribute in every single inner annotation. I can whack that in with vi if you feel it should be there rather. Then we could do the following:
@CompositePattern.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) {}
}
Heinz
Reply
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
Michael Hunger
I assume that most users will forget to use @PatternComment and @PatternParticipants.
As I already said, we can also create a file template in idea for creating new Patterns, then all of this comes for free.
Michael
Dr Heinz M. Kabutz
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
Dr Heinz M. Kabutz
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
Michael Hunger
A template for the inner ones is just a text expansion (called live-templatte in idea): http://screencast.com/t/ZmUwZjI4Y
Michael
Dr Heinz M. Kabutz
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
Alex Gout
Dr Heinz M. Kabutz
On 8/11/10 11:31 AM, Alex Gout wrote:
> Hi,
>
> I have a few suggestions for additions to the pattern annotations.
> Please let me know what you think:
>
> Builder: add elementtype.method CreationalDelegate
is that in the original GoF? The Construct() or BuildPart() methods?
> ChainOfResponsibility: add elementtype.type DefaultHandler
Yes, good idea.
> CommandPattern: add related pattern Singleton (as keeper of state)
first run). I'm also not quite sure how these are related. Could you
explain a bit?
> Iterator: add related Visitor pattern (as a visitor often uses
> iterator to loop through elements)
should then make the Visitor have a relative of Iterator?
> Memento: add pattern State as related pattern.
> Observer: why is observer related to itself?
and Singleton. Well spotted :-)
> Strategy: add related pattern FactoryMethod
we start doing other patterns, for example, the
Fowler.StaticFactoryMethod, then that would definitely be related to
Strategy.
This brings me onto another question for the group. How "pure" should
we keep the pattern definitions? What is our gold standard? My thought
was that we stick as closely as possible to the original. However, in
the case of the Factory Method, there are lots of different types of
factories out there (see Head First Design Patterns). Should we put
them all into the GoF Factory Method (which is where most people would
look for them) or do we add a comment to the file that explains where to
find these patterns?
Do we link from the GoF patterns to related patterns in other patterns
catalogs?
Would love to hear your opinions.
Heinz
Michael Hunger
I assume there can be lots of heated debate as everyone takes his own context and experiences into the calculation when dealing with pattern - which is a good thing!
I would also link to other patterns from other catalogues.
Perhaps we should also introduce the patternLanguage attribute at the DesignPatterns annotation then we could relate the patterns to the pattern language they belong to.
There is a comprehensive list of patterns in POSA4 and a great discussion about the philosophy of patterns in POSA5 (the latter is a very recommended read).
Cheers Michael
Perhaps we should also put a list of pattern related books on jpatterns.org (w/ amazon links and affiliate-id)?
e.g. GoF, HF DP, POSA1..5, Refactoring to patterns, William Wakes Pattern Handbook,
there was a recently released hatching patterns book from Vlissides (it think), Fowlers PoAA
and certainly others (these were just those that I thought of now).
Dr Heinz M. Kabutz
Perhaps we should also put a list of pattern related books on jpatterns.org (w/ amazon links and affiliate-id)?
e.g. GoF, HF DP, POSA1..5, Refactoring to patterns, William Wakes Pattern Handbook, there was a recently released hatching patterns book from Vlissides (it think), Fowlers PoAA
and certainly others (these were just those that I thought of now).
Michael Hunger
Michael
Alex Gout
Thanks for your comments. I used the book "Applied JAVA
Patterns" (Stelting & Maassen). It is somewhat more towards actual
implementations than the GoF book, hence I think the differences with
GoF. Im ok if we stick to GoF as a reference, but at least lets's make
that explicit for now.
About my comments:
Builderpattern: in AJP, they describe the Director variant, with the
Director delegating parts of the creation process to what they call
creational delegates. So, it is related to the BuildPart() method
Command: In the book, a common variant of the commandpattern in
described in an example of an undo- redo list. The command history is
a singleton. On second thought this might be too much implementation
oriented detail for a related pattern.
I agree on the Visitor - Iterator relation, as the visitor will use an
iterator to cycle the elements.
Memento: A memento is used to capture the state of an object and be
able to rewind to that state. Ofcourse, you do not need to inplement
the state pattern for this, but I felt the relation was strong enough
to mention
Strategy: AJP: "The Stragtegy method is sometimes defined as a Factory
so that the using class can use new Strategy implementations without
having to recode other parts of the application" Hence, I suggested it.
Ofcourse, if we mean to stick to GoF for now for these patterns most
of these comments are academic.
Thanks again for your comments, I hope I have explained myself ;)
I will be on holiday from sunday for 3 weeks. Be good all ;)
-- Alex
Op 13 aug 2010, om 08:12 heeft Dr Heinz M. Kabutz het volgende
geschreven:
>
> --
> 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
Michael Hunger
Am 13.08.2010 um 10:05 schrieb Alex Gout:
> Hi!
>
> Thanks for your comments. I used the book "Applied JAVA Patterns" (Stelting & Maassen). It is somewhat more towards actual implementations than the GoF book, hence I think the differences with GoF. Im ok if we stick to GoF as a reference, but at least lets's make that explicit for now.
>
> About my comments:
> Builderpattern: in AJP, they describe the Director variant, with the Director delegating parts of the creation process to what they call creational delegates. So, it is related to the BuildPart() method
This looks more like a pattern composition. The director could implement a template method for that, or use the other builders as strategies. If they builder form a consistent hierarchy it could also be a composite (depending on what to build).
But that is a good idea. We should address (I'm not sure how) the different kind of pattern aggregations:
POSA5 names:
* pattern collections
* pattern sequences
* pattern stories
* pattern languages
(I also think pattern compositions but am not sure, have to look it up).
> Command: In the book, a common variant of the commandpattern in described in an example of an undo- redo list. The command history is a singleton. On second thought this might be too much implementation oriented detail for a related pattern.
I agree with that. And singleton is not necessarily a good solutions for that. Imagine a application with several sessions and you want to have an undo list per user or session, then the
singleton would have to handle the thread-safe access of all users and separate that internally.
Rather have the undo-list as a part of the appropriate object,
> I agree on the Visitor - Iterator relation, as the visitor will use an iterator to cycle the elements.
> Memento: A memento is used to capture the state of an object and be able to rewind to that state. Ofcourse, you do not need to inplement the state pattern for this, but I felt the relation was strong enough to mention
Hmm I rather think the state encapsulated by the state pattern is the part of the objects functionality that varies with the state changes not necessarily its attributes, putting the attributes into the state as well would be possible but then it would not enable code sharing between objects. Most implementation of the state pattern I've seen deal only with behavior not internal state (pun intended)
> Strategy: AJP: "The Stragtegy method is sometimes defined as a Factory so that the using class can use new Strategy implementations without having to recode other parts of the application" Hence, I suggested it.
Could you explain that a bit more? You have to recode something in the app when adding new strategies, I don't know how factory protects you from that. The only thing I can imagine is to hide the selection logic from the client.
Alex Gout
To: jpat...@googlegroups.com
X-Mailer: Apple Mail (2.1081)
Return-Path: ag...@planet.nl
X-OriginalArrivalTime: 14 Aug 2010 08:28:34.0282 (UTC) FILETIME[AF4DACA0:01CB3B8A]
On Aug 13, 2010, at 10:22 AM, Michael Hunger wrote:
>
> Am 13.08.2010 um 10:05 schrieb Alex Gout:
>
>> Hi!
>>
>> Thanks for your comments. I used the book "Applied JAVA Patterns" (Stelting & Maassen). It is somewhat more towards actual implementations than the GoF book, hence I think the differences with GoF. Im ok if we stick to GoF as a reference, but at least lets's make that explicit for now.
>>
>> About my comments:
>> Builderpattern: in AJP, they describe the Director variant, with the Director delegating parts of the creation process to what they call creational delegates. So, it is related to the BuildPart() method
> This looks more like a pattern composition. The director could implement a template method for that, or use the other builders as strategies. If they builder form a consistent hierarchy it could also be a composite (depending on what to build).
>
> But that is a good idea. We should address (I'm not sure how) the different kind of pattern aggregations:
> POSA5 names:
> * pattern collections
> * pattern sequences
> * pattern stories
> * pattern languages
> (I also think pattern compositions but am not sure, have to look it up).
Actually, the delegates are not objects, they are methods. Thats why I suggested the elementtype.METHOD CreationalDelegate (or in GoF terms I think BuildPart, I dont have GoF handy atm).
I like the idea of addressing the aggregations.
>
>> Command: In the book, a common variant of the commandpattern in described in an example of an undo- redo list. The command history is a singleton. On second thought this might be too much implementation oriented detail for a related pattern.
> I agree with that. And singleton is not necessarily a good solutions for that. Imagine a application with several sessions and you want to have an undo list per user or session, then the
> singleton would have to handle the thread-safe access of all users and separate that internally.
> Rather have the undo-list as a part of the appropriate object,
Agree. Come to think of it.. I never saw Singleton as 'real' singleton, but more of an object that controls object creation and uniqueness in a context. The context could also be a thread or a session instead of a JVM. Regardless of how we address it in JPatterns, how do you guys look upon this?
>
>> I agree on the Visitor - Iterator relation, as the visitor will use an iterator to cycle the elements.
>> Memento: A memento is used to capture the state of an object and be able to rewind to that state. Ofcourse, you do not need to inplement the state pattern for this, but I felt the relation was strong enough to mention
>
> Hmm I rather think the state encapsulated by the state pattern is the part of the objects functionality that varies with the state changes not necessarily its attributes, putting the attributes into the state as well would be possible but then it would not enable code sharing between objects. Most implementation of the state pattern I've seen deal only with behavior not internal state (pun intended)
I don't understand this I'm sorry ;(
Can you elaborate on this?
>
>> Strategy: AJP: "The Stragtegy method is sometimes defined as a Factory so that the using class can use new Strategy implementations without having to recode other parts of the application" Hence, I suggested it.
>
> Could you explain that a bit more? You have to recode something in the app when adding new strategies, I don't know how factory protects you from that. The only thing I can imagine is to hide the selection logic from the client.
Imagine you have a family of datastructures that need to support serialization in some application. If each structure defines a strategy to do this, you could have the DataSerializer use the factorymethod on the datastructure to retrieve the appropiate strategy. When you implement a new Datastructure, you only need to associate it with the (new) strategy and the rest of the code remains untouched. That is the correlation they mean between factorymethod and strategy.