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
[email protected]
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
_______________________________________________
patterns-discussion mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/patterns-discussion
