Reading "Design Principles and Design Patterns"

[zby]

Design Patterns are an intriguing idea - there are some attempts to port it to Perl, but I would not call them too successfull in spreading it. Design Principles and Design Patterns by Robert C. Martin tries a higher level view on the design patterns by defining some general rules about dependencies and abstraction and then showing how the patterns follow from them. This perhaps should be easier to translate into dynamic languages.

I think the real takeaway is "Stable packages should be abstract packages" - where stable for the author means 'many other packages depend on that one'. The problem with translating that to dynamic languages is that the most abstract (in the OO sense) packages, the pure interfaces don't need to be written down in code at all. Duck typing gives us a great flexibility - but it also means that there is no requirement to write down the abstract interfaces - and if there is no additional pressure then they will not be defined by the programmers.

Another problem with translating the ideas into dynamic languages is the meaning of the word 'depend'. With static typing it can be clearly defined by the need to recompile the package if there is some change in the package it depends on. For dynamic typing this needs to be defined in some more subtle ways - basing it on the type of the coupling between the packages.

[sundialsvc4]

To my way of thinking, the are three essential characteristics of “a rugged, stable package”:

1. It is thoroughly documented, and thoroughly tested against that documentation. Documentation is a form of “contract” too – a social contract between two developers ... who will never meet, although one has now chosen to utterly rely upon the work of the other. To put the whole thing another way, the package is designed, built, and deployed as a true, industrial-strength product, that has been “purchased” even if no money has changed hands.
2. The package presents opaque objects that do not obligate you to be concerned about how they work. (Just as you do not have to be concerned if they work.) There is, in other words, “an implied warranty of merchantability and fitness to a particular purpose,” in a social sense even if not (expressly not... usually...) in a legal sense.
3. The package nevertheless provides thoughtfully-considered opportunities for subclassing and augmenting its existing functionality. In other words, the designer anticipated places where his or her predecessors might reasonably need to extend, augment, or even replace some well-definable characteristic of what “this otherwise-opaque thing” is doing... or of how it is doing it.
“Being nice to the next guy” is definitely a learned habit. When you design something that is good-enough for what you are doing now, and you deploy that to CPAN, then, “well, thank you!” But, if you design something that is really well-documented, has well-placed “user exits” where the function of the component can easily be enhanced or tweaked, and that is still well-tested in spite of that ... I guess you become a legend when you do that.

[zby]

Thanks for the interesting comments. Just one clarification - 'stable' in the nomenclature used in the article does not mean that something is so good that it does not need to be changed it only means that something cannot be easily changed (because so many things rely on it).