• Advertisement
Sign in to follow this  

Design Patterns: Elements of Reusable Object-Oriented Software

This topic is 4463 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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!

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
I Love pragmatic programmer. I still pick it up and read a page or two now and then to keep it in my mind.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement