Design Patterns

Programming the object oriented (OO) way is not simply writing down algorithms that do “for" loops. The core concept to understand, for a OO programmer, is how many classes have to be implemented on the basis of the analysis of the problem under scrutiny, and to be eventually managed by a client (the “main” method in C family of languages)  to solve a task. Therefore, a series of questions arise:

• Are there strategies for producing a minimum number of classes without loosing functionalities  in the work done and promote its extensibility  ? 
• What goes into a class, and what in other OO features (like methods of a class) ? 
• How to create classes with a minimum of generality that can be reused in other problems ? 
• How to build classes that can be easily maintained, modified and evolved without disrupting other parts of codes ? 

(In practise the questions are those for which OO was born but knowing an OO language does not directly answer them, just offers an infrastructure for finding the answers).

An entire discipline, software engineering (SE), was established to find the answers, and various behaviors were codified to improve software writing practice and management (but software engineering also covers the organisation of software production, and the methods to give  clear specifications to pariah-programmers for practical coding).
The key actions implied by the answers, however, are not the ones a scientific programmer was used to face: s/he would expect to have a formalised mathematical problem and the scope of her/his work to consist in fact in finding the best (shortest, fastest, cleanest) algorithms to solve it (see the classical Knuth’s books, or the popularisation of Numerical Recipes - I hate their licensing scheme) but not to answer questions about the organisation of the code.
Maintainability and efficiency comes to a cost and OO adds a further level of complexity to the programming practice that scientists are not always ready to face: and it is quite paradoxical that these aspects of SE are not wide recognised as a fundamental task in our times when computer programs have entered in the daily practice of many scientists (see also the introduction to this paper of ours). As a matter of fact bad code practices easily develop in bad science.

Back to the general questions posed at the beginning of the post, proficient programmers observed that, certain problems were recurrents and that some solutions were better than others in term of maintainability and generality. These were called "design patterns”:

"The elements of this language are entities called patterns. Each pattern describes a problem that occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice."  (from A Pattern Language by Christopher Alexander, that is said to be inspirational for the the Gang of Four book - see below).
Other definitions of patterns can be fond in the Portland Patterns Repository and in The Hillside group on patterns,.

The patterns idea gained popularity after the book of Gamma, Helm, Johnson & Vlissides, Design Patterns, which actually presents 23 free patterns, grouped in three categories, called

• behavioural, 
• creational and 
• structural patterns. 

Beyond these initial patterns, other were identified, for instance for parallel computing (see Concurrency patterns), and  in other fields.
The patterns style and  use (and concept) are not immediate to grasp. They in fact derive from long practicing some specific software issues, and a subsequent conceptualisation and abstraction. As often happens, their abstraction makes them general but  quite difficult to be assimilated without going back to develop many examples.
A few guiding ideas are behind the selection of patterns: code should be made easy to modify without large refactoring efforts, and encapsulation of code parts maintained as much as possible. Subclassing maintained to a minimum. An explicit slogan was "program to interface and not to implementation”. Roughly speaking this means: first implement abstract classes or interfaces (in C-family of languages), the, for what is possible, delay the use of concrete classes at run time. Instead of creating subclasses, create other classes to which "delegate responsability”, in order to reduce coupling between classes. The reader is invited to browse the web to understand her/himself what it does mean, advising her/him that explanations are usually full of computer science slang (I think, actually that the language is part of the success of the book).
In any case, the right way to get used to Design Patterns, is, as I said, to use and practice them a lot by trial and error. Java aficionados can have several vulgarisations, many of them can be found on the web [Ava Java].

However, the relevant questions here, in this blog,  are:

• which of the original (as well as other) patterns are useful in scientific programming ?
• Are there any pattern that is characteristic to hydrological problems ?

Certainly there exists hydrologists that apply some patterns for the tasks the patterns were created. I do not know if experienced hydrology programmers apply  patterns to some specific of hydrology. Please let me know if you are someone of those, and I will really likely exchange ideas and a (very few) experiences.

In the general science framework, instead, I find a few more references. The first books I can reference are

• Design Patterns for e-Science, by Henry Gardner, Gabriele Manduchi, Springer, 2007 (It covers the building of a system for visualising experiments from plasma physics)
• Damian Rouson (Author), Jim Xia (Author), Xiaofeng Xu (Author), Scientific Software Design: The Object-Oriented Way, 2011 (It covers arguments more close to implementation of algorithms/ Unfortunately, despite the code in C++, it is pretty oriented to FORTRAN)

Other resources come from the paper by the Izaguirre group, and are referenced below.


Further Readings

- Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides: Design Patterns: Elements of Reusable Object-Oriented Software

- Thinking in patterns’ Notes by Bruce Eckel

- [Portland Patterns Repository] - Patterns are the recurring solutions to the problems of design. People learn patterns by seeing them and recall them when need be without a lot of effort. Patterns link together in the mind so that one pattern leads to another and another until familiar problems are solved. That is, patterns form languages, not unlike natural languages, within which the human mind can assemble correct and infinitely varied statements from a small number of elements.

- [The Hillside group on patterns] - Fundamental to any science or engineering discipline is a common vocabulary for expressing its concepts, and a language for relating them together. The goal of patterns within the software community is to create a body of literature to help software developers resolve recurring problems encountered throughout all of software development. Patterns help create a shared language for communicating insight and experience about these problems and their solutions. Formally codifying these solutions and their relationships lets us successfully capture the body of knowledge which defines our understanding of good architectures that meet the needs of their users. Forming a common pattern language for conveying the structures and mechanisms of our architectures allows us to intelligibly reason about them. The primary focus is not so much on technology as it is on creating a culture to document and support sound engineering architecture and design

- [Design Pattern for scientific software] by Dan Gezelter. He pointed to some papers on Design Pattern is scientific computing by the Izaguirre group of which I found [1] and [2]

- Design Patterns in Wikipedia