GOF (your link above), Refactoring, Refactoring to Patterns are some good choices.

The Gang of Four design patterns book is excellent. I own a copy, and it's easily one of my most-used references (as far as dead-tree stuff goes).

Another great one for learning design/structure is The Pragmatic Programmer. If you buy and read any programming books in the next year, make it that one.

I bought that book nearly a year ago and it's helped me out a lot. DEFINITELY worth the money!

I'd say this book is middle-of-the-road. It's not quite a beginner's book but it's not exactly a reference for experts either. It explains some frequently used patterns but isn't an exhaustive reference. However, for the sake of simply learning to write better object-oriented code, it hits the nail on the head. I'd suggest you read up a bit on applying design patterns first though. Here's a good article on the subject (new window).

Quote:Original post by ApochPiQ
Another great one for learning design/structure is The Pragmatic Programmer. If you buy and read any programming books in the next year, make it that one.

Excellent suggestion!

Its a great book, I say one of the greatest because the greatest software engineering book for me is still "the mythical man month" classic by FP Brooks. Use the book as a reference guide if you encounter a problem in object oriented design, for most bachelor and master software engineering students its pretty basic knowledge. I wouldn't really memorize the book just pick up a few tricks in OO design. Although most patterns present obvious solutions to OO problems in practice you often need to solve multiple problems which may require multiple patterns. I'm not saying using patterns is bad but a more simpler, elegant software design which every one can understand is better then a very complex one that no one can figure out.

Talking about architectures; another similar book that discusses software patterns is Buschmans Pattern-Oriented Software Architecture that discusses patterns on a higher level e.g. the software architecture level.

In my opinion the pattern movement is fading out a bit. Patterns are building blocks of design and as software engineering practice matures and more and more reusable components (OO frameworks) become available (the building blocks just get bigger) which inhibit these patterns. See for example java struts framework which instantiates model view controller etc. To understand these frameworks or to select particular frameworks to design your software, knowledge about patterns is required.

Design Patterns Explained is a phenomenal book, have a look at its table of contents.
I found it really enlightening and it gave me a new perspective on design.

In agreement with what people have said here, the author does stress that design patterns are just commons solutions to problems, but you can always go back to basics using the principles. Indeed, I could find quite a lot of patterns that I had reinvented in my projects.

I highly recommend that book!


edit: in your hero exam, you would use commonality and variability analysis as described in the book, putting the commonalities in a class such as your UnitBase and encapsulating the variabilities. I think inheritance would be justified in your example, but remember that aggregation (object holding a reference or pointer to another object) should be preferred; the author takes you through the patterns with case studies, so you can see the combinatorial explosion of derived classes etc.