General talk about software patterns

[Holger Mügge <muegge AT iai.uni-bonn.de>]

Hi Jesús,

thanks for your statement. I have the impression that your opinion is 
rather optimistic ;-)

I often made the experience that when you're going to extend a complex 
software which incorporates many patterns (e.g. writing plug-ins for 
eclipse), patterns might be recognized but not as lucent as one might 
wish. Orientation and finding the best (and intended) ways to make use 
of the pattern applications or extend them is not that easy.

Sure, if the programmer knows the pattern (or the specific variant used) 
well, the situation is good. But if not, it is not always easy for him 
to figure out how the pattern works. I often saw code that ignored a 
well programmed pattern already providing most of the needed 
functionality, and using an unnecessary circumvention instead. This 
holds in particular for not so well known patterns, which are legion. 
And beside "real patterns" there are other unnamed structures that 
programmers have intentionally woven into the code, but that are not 
easy to understand by others.

Do you know of *empirical studies* about the usability of patterns (for 
readers and writers). I guess that naming plays an important role for 
recognizability. But that is not enough when it comes to overlapping 
pattern applications, i.e. that one code fragment plays multiple roles 
in different patterns.

Best regards,

Holger


Jesús Alonso wrote:
> Hello Holger,
>
> In my opinion, it simply depends on how familiar you are with the 
> pattern you are to recognise. Patterns like Façade, Observer, or 
> Singleton are quite easy to find, and some patterns are more a 
> philosophy than a generic structure, like the Façade or the Template 
> Method, what makes them easy to find in code. Of course, if you have 
> the design diagrams and not just the source code, they are much easier 
> to spot.
>
> Also, a few days ago Jens Dietrich sent a mail to one of these lists 
> to announce their research project regarding automated pattern 
> recognition in source code. The link is: http://www-ist.massey.ac.nz/wop/
>
> About editting code, design patterns usually give the most appropiate 
> solution for a problem. This solution stablishes a good design 
> philosophy everyone should follow as much as possible. So the 
> programmer just should have to follow that same OOP philosophy when 
> editting that code. Based on a well defined structure and following 
> correct OOP usually leads to the correct solution, even if he doesn't 
> recognise the pattern or even doesn't know anything about it. From my 
> personal experience, extending existing patterns-dense code was easy 
> and found myself implementing the Observer pattern before I ever heard 
> of it. Just as an example, anyone who has programmed a GUI in Java has 
> found himself applying the Observer pattern everytime they create a 
> new Listener (Observer participant) and attach them to a graphical 
> component (attach method in Subject participant). As you can see, a 
> well trained programmer will hardly destroy patterns when editting 
> patterns-dense code.
>
> Hope that helps.
>
> Best regards,
> Jesús Alonso
>
>
> > Hi Mike,
> >
> > Mike Beedle wrote:
> > > Any more “positive feedback” out there?
> >
> > YES. Thanks very much for your posting.
> >
> > I always appreciate hints towards a more general view on structures 
> > than just "technical" views from a software engineer's view (or even 
> > a Java programmer's).
> >
> > I also have a question and request:
> >
> > You say pattern usage is at least partly a cognitive process. 
> > Typically cognitive processes can be error-prone (misinterpretation 
> > of structures, obfuscation, easy and difficult to recognize 
> > structures, ...). In particular when it comes to formal stuff like a 
> > program.
> >
> > Does anybody has links or own experience about problems with software 
> > patterns on this level? E.g. how good are they recognized in code? 
> > Under what circumstances is an average programmer able to edit 
> > pattern-dense code correctly, or when does he eventually destroy 
> > patterns by chance?
> >
> > Thanks for
> >
> > --
> > Holger Muegge
> >
> > University of Bonn, Institute of Computer Science III
> > Roemerstrasse 164, D-53117 Bonn, Germany
> > Phone/Fax: +49-228-73-6528 / -4382
> >
> >
> > _______________________________________________
> > patterns-discussion mailing list
> > patterns-discussion AT cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/patterns-discussion

--
Holger Muegge

University of Bonn, Institute of Computer Science III
Roemerstrasse 164,  D-53117 Bonn, Germany
Phone/Fax:          +49-228-73-6528 / -4382