Jim Weirich is here at the Rails Edge talking about design patterns. As he and many other people have pointed out, design patterns are language specific. In sufficiently expressive languages, many design patterns become library calls or disappear entirely. For example, does Iterator deserve to be a design pattern in Java? There’s an interface for it, after all. Many design patterns have direct library representations in Ruby: Singleton, Observable, Enumerable, etc.

Quite a while back, Peter Norvig proposed some terminology to deal with the gradual disappearance of certain patterns:

1. An invisible pattern is so much part of your language that you do not perceive it as a pattern. For example, “Encapsulation” is not a pattern in Java.
2. A formal pattern has an explicit library or macro realization, e.g. Ruby’s Observable.
3. An informal pattern is not captured by the language.

Far too many pattern enthusiasts relish informal patterns, when we should be trying to convert them to formal or invisible ones.

At the Rails Edge this morning, PragDave spoke out against class variables, and in favor of class instance variables. I totally agree. Look at this code:

# why I don't like @@attributes
class Base
  @@shared = 'cattr from base'
  class << self
    attr_accessor :unshared
  end
  def self.shared
    @@shared
  end
  self.unshared = 'attr from base'
end
class Derived < Base
  @@shared = 'cattr from derived'
  self.unshared = 'attr from derived'
end
class Ouch
  class << self
    attr_accessor :unshared
  end
  def self.shared
    @@shared
  end
end
puts Base.unshared
puts Base.shared
puts Derived.unshared
puts Derived.shared
puts Ouch.unshared
puts Ouch.shared

Can you guess what this program will do? It demonstrates three of the ways that class variables cause trouble:

1. The behave differently from instance variables if they are missing.
2. They are shared across an inheritance hierarchy in a counterintuitive way.
3. They require a new syntax, when the instance variable syntax is perfect for the task.

But maybe I am wrong. Ola Bini, who says many wise things, appears to be arguing exactly the opposite. Does anybody have a use case where class variables are the best solution?

Pro Ajax and the .NET 2.0 Platform, by Daniel Woolston, attempts to tackle three goals:

1. explain the history of web development, from start to finish
2. explain JavaScript
3. examine the integration Ajax techniques with ASP.NET 2.0

Fortunately, the author is well-versed in ASP.NET development and the idioms and practices that make for well-organized code. If nothing else, the final chapters serve as a good example of what clean, modular ASP.NET can look like. But it is very much better than that. The book provides a wonderful, ground-up walk through of integrating the major Ajax frameworks for .NET into your application. Particularly, he does a great job with demonstrating the marshaling of data back and forth between the server and browser, and dealing with the architecture of your handles/URLs on the server to deal with the non-standard request patterns in Ajax apps.

Less-(or perhaps un-)fortunately, the author also suffers from a common ailment in books of this genre: provincialism. The opening chapters of the book were riddled with examples of the author’s lack of experience outside his chosen platform. I won’t be a jerk and do a point-by-point analysis of what turned me off, but instead just provide three examples.

In the first chapter, as he is describing the inception of the web, he refers to the first browser as the “Mozilla” browser from NCSA. Three times. Could be a search-and-replace problem, but that browser was called Mosaic. Secondly, he admits that he shied away from learning JavaScript for many years because he just assumed it was Java, which means that he was dissuaded from even a cursory examination of the technology by four letters in its name. And, third, in his timeline for the history of web development, the second major event is “Bill Gates and Paul Allen create BASIC for the Altair”. Which might be an important step in the history of ASP, but is hardly seminal for, say, all those people who wrote CGI apps with Perl. In fact, his history of web development only mentions one technology not produced by Microsoft: Netscape.

Now, this doesn’t mean that the book is bad. It means, though, that the chapters on actual Ajax implementations are very, very Microsoft-specific. Sure, you say, that’s fine, though. Its an ASP.NET 2.0 book, after all. True, but the lack of deep JavaScript coverage, or acknowledgment of alternate strategies, leaves a limited scope to the ideas imparted.

In all, I think the book serves one audience very well: developers who get paid to write ASP.NET code, and aren’t looking around beyond their borders. However, I’d love to see a second edition of the book branch out and at least explain the alternate strategies, like incorporating Dojo or Prototype or Rico or some other non-Microsoft framework and really tackling JavaScript as a first-class programming language in its own right.

Overall, for its major purpose, I’d give it an A-. For its two lesser purposes (history and JavaScript), I’ll give it a D. If you are starting an Ajax app in ASP.NET 2.0, it is an important book for you. If you want to place the ASP.NET 2.0 tools in context, look elsewhere.