Most books are about languages (and how to use them) and algorithms. This one is original because it focuses instead on higher object oriented patterns not captured directly by syntax of current languages (but can nevertheless be expressed in them). It names these patterns and describes them, giving a common vocabulary to programmers.

You might be interested in Design Patterns in Dynamic Programming by Peter Norvig.

This presentation shows how to express common Design Patterns in Common Lisp.

It classifies Design Patterns into three levels:

• Invisible: So much a part of language that you don’t notice (e.g. when class replaced all uses of struct in C++, no more “Encapsulated Class” pattern)
• Informal: Design pattern in prose; refer to by name, but must be implemented from scratch for each use
• Formal: Implement pattern itself within the language -Instantiate/call it for each use - Usually implemented with macros

And concludes:

16 of 23 patterns are either invisible or simpler, due to:

• First-class types (6): Abstract-Factory, Flyweight, Factory-Method, State, Proxy, Chain-Of-Responsibility
• First-class functions (4): Command, Strategy, Template-Method, Visitor
• Macros (2): Interpreter, Iterator
• Method Combination (2): Mediator, Observer
• Multimethods (1): Builder
• Modules (1): Facade

This matches my personal observation that after learning programming in Scheme and Common Lisp, I often find the standard object-oriented languages like C++ and Java to be clumsy and lacking abstraction features (no functions as first-class objects (no closures, no functions as return values), no access to continuations (call-with-current-continuation (call/cc)), no macros, just to name the most important ones). Patterns like "Strategy" or the common C++ "Functor" idiom simply look like an indicator of poor language design when viewed from the perspective of a language with first-class functions.

The paper continues with an interesting historical observation:

Long ago, subroutine call was just a pattern

• Involves two parts: call and definition

  load R1, x       SQRT: 
  load R0, *+2     ...
  branch SQRT      branch @R0
  

• Nowadays, made formal by the language

  sqrt(x);         function sqrt(x) ...
  

So yes, indeed, the real task is to put all these Design Pattern stories into code. If the languages we use do not support this, we should change them to do so.

Christian Lemburg
Brainbench MVP for Perl
http://www.brainbench.com

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.