So CodePro
http://www.instantiations.com/codepro/ws/docs/express.html
already contains a tool for emitting patterns.

But that's different from storing and emitting the patterns. At worst, I could picture attaching meta-information in a javadoc comment at the end of the file:

/**

*/

I think I would prefer something like XML, so that you can parameterize it... after all, sometimes you want "a Factory of Five Wuzzits", which means that both Five and Wuzzit need to be definable.

Alternately, I guess, you could do a CPP-style preprocessor.

WussitFactory.jpp {
FACTORY( FIVE, WUZZIT )
}

expands into the full pattern for the compiler. Is that desirable? I'm not sure.

Danyel

Yeah, my emphasis was more on pattern validation than generation. Generating general skeleton code with hooks for a pattern would be a fairly simple task -- and it's very easy to break this code once you start playing with it and implementing the hooks. Nothing prevents you from destroying the skeleton.

Instead the validation would take the pattern you want to do and look for 1) code that violates the pattern or 2) code that is missing to satisfy the pattern. The validation would be a harder to implement but it would also keep the programmer or software engineer on track with the pattern they ultimately want to produce, keeping important contracts in place for larger design considerations that depend on patterns.

That's a good point about parameterizing, though I'm not sure if it belongs in the pattern itself. Maybe it could be a constant or a passed parameter. For example you might want a thread pool of 12 threads to be initialized, which is sort of factory-like. But later on you might want to change the pool to 24 or something when your server requirements change. The pattern hasn't changed though, just the number of threads or wuzzits.

Incidently, I did have something in the javadoc involving angle brackets...

(pattern type = "factory")
... (count/ number = "five")
... (type/ class = "wuzzit")
(/pattern)

I see what you mean about validation. Perhaps a different model is to look at VEP
http://www.eclipse.org/vep/
which manages excatly what you're talking about. It knows you have a JFrame with a JComponent inside it. Of course, it knows that ... because it runs it. A VM instance runs the code and sees what comes up.

Could we go one step further, and actually extract whether it's still the real pattern or not? I'm not sure.

The other thing that comes to mind is that with JDK 1.5 and some clever reflection, it might be possible to make pattern abstract classes.

ThingFactory{X}

gives you a bare XFactory. (Those are angle brackets around the X.)

public MyXFactory extends ThingFactory {
.. public froble() {
.. }
}

gives you an XFactory that also frobles.

Isn't the VEP for GUI builders?

Something I forgot was namespaces.

For example, I could use my own org.audioman.Immutable but Sun may have their own com.sun.Immutable or another organization. Then the validator would know which thing to validate.

Most importantly if the patterns were standardized somewhere programmers/architects could trust they'd follow the same rules every time, rather than have to create custom patterns every time. Custom patterns would be relatively rare.