It’s certainly worthwhile for every programmer to read Design Patterns at least once, if only to learn the shared vocabulary of common patterns.
No matter what you think of design patterns, you have to read the book at least one time. I remember a talk with a fellow programmer, explaining a part of his design: “so you this object inheriting from that one, and implementing that one interface, and blabla blabla object object blabla more objects etc…”. After a couple of minutes, I said “so basically, you have a composite”. “Yes”. As a design gets bigger and bigger, it’s important to have a bigger vocabulary than just class this, object this.
But there are problems with patterns as Jeff continues:
If you find yourself frequently writing a bunch of boilerplate design pattern code to deal with a “recurring design problem”, that’s not good engineering– it’s a sign that your language is fundamentally broken.
In his presentation “Design Patterns” Aren’t, Mark Dominus says the “Design Patterns” solution is to turn the programmer into a fancy macro processor.
Don’t Repeat Yourself. If the same pattern happens again and again, maybe you should find a way to automate it? A good language can help here. I hear a lot more about patterns in the java world than in the ruby world. Why? You have no choice but to code the pattern and it’s boilerplate every time in java. In ruby, you do it one time with a bit of metaprogramming. The ruby standard library provides a library for the singleton. “Include singleton” in your class and you’re done. Other design patterns are there to cover a flaw in the language. For example, you don’t need visitors if you use lisp because of multiple dispatch.
How can you distribute responsibility for design through all levels of a large hierarchy, while still maintaining consistency and harmony of overall design? This is the architectural design problem Alexander is trying to solve, but it’s also a fundamental problem of computer systems development.
I will have to read the Alexander book. That’s a much more interesting problem than something you can abstract in a good language.
Popularity: 4% [?]
I finally played a bit with the REST part of Rails. Over the weekend, I made my first RESTful web app. How did it go? I don’t know. I don’t think I’ve yet made the mental switch. There’s a few things that bug me about REST, and I’m not sure I can put it in words yet.
I think there’s “REST” and “Rails REST”. The way Rails does REST seem to be a subset of REST, or at least it puts more constraints on how you should do it.
The one thing that bothers me the most is the respond_to and how you can handle different formats. Yes it is nice to be able to reuse the same action and send back XML or CSV or a basic html representation of the information. But when it comes to the actual UI of your application, the html, the forms, the navigation, I don’t want my user to interact with the application the same way a machine would.
Maybe I should investigate a bit more the RADAR architecture as described by Dave Thomas. The idea is to have the html application be another layer on top of your resources.
Popularity: 2% [?]