Design Patterns: Elements of Reusable Object-Oriented Software

[syph 140]

http://www.amazon.com/gp/product/0201633612/qid=1137684931/sr=8-1/ref=pd_bbs_1/103-9181331-8743851?n=507846&s=books&v=glance I've read a few good things about this book from Amazon, but I wanted to know if any of you have read it. I'd like to have more "structure" to my game design instead of the haphazard way I do things now like "Make a class for my hero --- oops I should make a unit class and use that as a base class --- oops I need to add methods to hold their sprites --- oops now I have to make my sprite class able to send those textures --- oops ..." You get the idea - I know experience is a big part of this as well, but I think I need to supplement the dozen or so technical "this is how you code DirectX/Windows API/MFC/Forms/Game AI in C++" books with a couple "this is how you logically dissect problems into manageable and reusable blocks" books. Any recommendation on this or other books is appreciated!

[Washu 7836]

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

[ApochPiQ 23134]

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.

[coderx75 435]

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).

[coderx75 435]

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!

[syph 140]

Thanks everyone, I had my boss order the GOF book yesterday and I put the pragmatic programmer on my amazon wishlist. Just reading through the link coderx75 sent has got me thinking about the current code I'm maintaining as well as my personal game project. I have a couple of degrees in electrical engineering and transitioned into a software engineering position on a fluke (I was the least code-o-phobic of the team).

I (thankfully) heard about the GOF book via a footnote in my Borland reference manual. I get the feeling that there's a whole world of design paradigms that I'm missing out on. Are there any other books I should think about getting to help me become a "real" software engineer as opposed to a renegade EE who kind of knows C++/Python? ;)

Thanks again.

[uutee 142]

The most influential books to my SE thinking:

1) Large scale software design in C++ (John Lakos)
2) Pragmatic Programmer (Thomas&Hunt)
3) GOF

Some of the stuff relies quite heavily on previous knowledge: I assume I wouldn't have gained the maximum out of Lakos without first having Coplien&Meyers&Cargill under my belt. Pragmatic Programmer is definitely the one with the least burden of previous knowledge: the stuff is very easy to read understandable, but still very useful.

GOF is very nice in a "hey, I've been using this solution for a long time, it's cool to see other people are using it too, oh and here's a variation of it that I never thought about in my hobby projects, cooooooool! <typeptypetypeypytepe>" sort of way.

Cheers,
-- Mikko

[Kuro 284]

I Love pragmatic programmer. I still pick it up and read a page or two now and then to keep it in my mind.

[eelke_folmer 191]

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.

[DrGUI 402]

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.