[eclipse.org-architecture-council] Eclipse Patterns

["Scharf, Michael" <Michael.Scharf@xxxxxxxxxxxxx>]

Hi,

since a few days I am thinking about patterns in the realm of
eclipse. Patterns are a great way to express design decisions
and to share experience. Eclipse is a very open and complex 
system, and it requires quite some experience to make good
use of eclipse. If I do something (new) with eclipse, I start 
looking at other projects how they solve a particular problem and 
I try to follow that scheme. But it is a very time consuming 
process to come up with the patterns by looking at others code. 
Especially it is often hard to figure out if a specific piece of 
code is "good practice" or violating some eclipse principles.


The top-ten list is a good start for a set of eclipse patterns.
In addition a catalog with a set of documented patterns:
 
http://en.wikipedia.org/wiki/Design_pattern_(computer_science)#Documenta
tion
would be very helpful. 

I am aware that eclipse patterns would be much more specific than
classical design patterns like Composite or decorator. But since there
are so many plugins and applications based on eclipse, there is enough
examples to come up with quite some eclipse specific patterns. We 
could also relate to existing patterns and adapt them into the context 
of eclipse (like write eclipse specific "Consequences").

Writing good patterns is not simple and takes time. There is this huge 
patterns community (http://hillside.net/) with the PLoP (Pattern
Languages 
of Programs) conferences. I have never been to any of them, but there 
seems to be a process with "writers workshops" to come up with good
patterns.

So, I could imagine that we could have a face to face meeting where
we do a kind of eclipse PLoP. In previous face to face meetings we had
nothing really to talk about. But an eclipse patterns workshop could
be a great way of using or shared knowledge and produce something of
value for the community. I think this would also scale, because there
is no need for long (unproductive) round table discussions with 30+
people. Instead there would be small breakout sessions focusing on
individual patterns. 

I try to avoid the term "architectural patterns" because I think there
are many areas, from project managements, release engineering, API
design,
concrete framework usage (like I can see lots of patterns around EMF and

osgi) to architecture patterns. So, we should not restrict this to 
"architectual" patterns.


Michael

-- 
Michael Scharf, Wind River
direct +49.6621.586.0139 mobile +49.173.664.2579 fax +49.6221.436.805