The Desktop Fishbowl
tail -f /dev/mind > blog

Monday, 29 July 2002

Five books I think you should read if you hack Java: Design Patterns, Gamma, Helm, Johnson, Vlissides. (the Gang of Four). There are four stages of pattern-awareness. Ignorance (What is a pattern?), Denial (Oh, patterns are stupid), Over-enthusiasm (Let's use Singleton here! And Visitor here!), and finally enlightenment (That looks like an Adapter... Hmm...) Reach stage four. Refactoring, Fowler Keep your code beautiful. An amazingly clear book, very easy to read, with good examples and sage advice. The Pragmatic Programmer Hunt and Thomas. An entertaining book. Where I learned about boiled frogs. Some of the advice in this book may seem obvious to you. So why aren't you doing it? Why? Sometimes it takes someone else reminding you what you've always believed to convince you that you've been right all along. Object Oriented Design Heuristics Riel. A harder read, far more dry than the last three. But it's the best advice I've read about OOAD yet. Good advice on how to compose your objects, divide responsibilities, and structure inheritance. Effective Java Joshua Bloch. The only Java-specific book on the list. If you program Java, you must read this book. Now. 7:40:29 PM

Brett Morgan asks what happened to JavaSpaces? My two cents is that Javaspaces is a really neat solution in search of a problem. It stores data, but it's not a database. It sends messages but it's not a message-queue. It's networked shared memory, but there's always some more convenient, more familiar solution. One day, I'll find a problem that JavaSpaces is more suited to than anything else, but I'm yet to find it. Oh, and on top of that, the overhead of working through Jini is decidedly non-trivial. 4:15:13 PM

Semantics, in my book, does cover abstraction. There is a trick I use while designing. If I cannot come up with a clear, simple name for a class or method, I probably have a bad design. Confusing names are a sign of a confusing design.Interesting thoughts from Bob. [Hard Werken], quoted in [rebelutionary] One very useful XP practice (and one of the more difficult) is the adoption of a system metaphor. You model the system you are building on something that is similar in function that already exists. The metaphor helps a great deal with naming things, because you can relate the thing you are building back to the metaphor. One project we worked on involved receiving data from a number of clients wrapped in some crypto (we had to write the client, too), passing the data on to a third party, and billing the sender. Early in the design stage, we caught on to the idea of having a courier service as our metaphor. Immediately, we had a naming scheme - the crypto became the envelope, the checksum was its seal, the envelope was "weighed" to determine its cost, and then passed to the dispatcher. Also, the metaphor helped a lot with scoping the project. Once you understand a project in terms of something real and simple to understand (like a courier), you could realise that some features that were on the list would never be used (because nobody would ask their courier to do that), or that some things that weren't on the list were vital. Of course, coming up with the metaphor in the first place can be really, really tough. 1:19:19 AM