Wednesday, May 18, 2011

PatternCraft - Builder Pattern

This PatternCraft tutorial explores the Builder Pattern in the context of building out maps in Starcraft:

6 comments:

  1. Great Tutorial!  I am always amazed at how simple most design patterns really are, and yet they add so much.  After seeing this, I really need to look into using IntelliJ

    ReplyDelete
  2. Anonymous1:25 PM

    I agree. Most books/articles/whatever make patterns sound way too complicated, but patterns are really just a couple of classes/interfaces put together in a certain way to solve a particular problem.

    It is nice developing a "Pattern Vocabulary" so you and your team can discuss potential solutions like "Adapter", "Facade", etc and have everyone be on the same page without diving into code.

    ReplyDelete
  3. miels tronic2:20 PM

    hi john,

    I don't really see the benefit of the Director. Sure you get the whole usage of the Builder into a separate class.
    However, when you added the sky, you were forced to add the sky functionality to the super class MapBuilder, due to Director taking a MapBuilder as parameter.

    I had the idea to extend Director to get "SkyDirector" who takes care of the new possibilities of a SkyMapBuilder class. But that makes no sense, as inheritance isn't the right approach here.

    The problem I try to explain is that the Director forces you to put everything into the super class, like a god object, I think.
    The classes that do not override sky do nothing, so there's no harm. But I don't like that, I mean, instead of "doing nothing" shouldn't they "not do anything"?
    (instead of executing an empty function, do not have the function)

    This is the point where I think the problem is the Director, as it want's to treat every Builder subclass in a generalized way (as it only accepts the super class (MapBuilder) as a parameter) Wouldn't it be better to place the different buildTypes into the different Builder classes?

    I'm quite new to this whole pattern stuff, not sure if I could explain this properly. thanks.

    ReplyDelete
  4. Anonymous2:31 PM

    The Builders define steps that you "can" take to create your Product. The Director defines the steps that you "do" take.

    Builders, by themselves, don't really do anything except expose what they can be used for. It's up to the Director to make it happen.

    The main thing is, if you don't think that this setup works for your current task, then don't try to force it. There are a billion different ways to solve whatever you're trying to do and this is just one of them.

    ReplyDelete
  5. Rickylala4:33 AM

    First of all I can't thank you enough for doing these examples, so much more clear than what is read in books imo, plus having starcraft as a base for everything really helps it all tie in together.
     
    I'm also a padawan in the proper programming world.  Up until now (I think at least) you have favored interface over inheritance.  If this were something more than a simple example for Director and string output would you have done something along the lines of:

    GrasslandBuilder extends MapBuilder implements IMapBuilder

    ReplyDelete
  6. Anonymous7:56 AM

    I used a class instead of an interface so that I could define default behaviors for the methods (like in init()) and so I wouldn't have to define them in the subclasses if they didn't need to change the default behavior.

    If I were to use an interface to make it a bit more flexible, I'd have MapBuilder implement IBuilder (or whatever) so that I the base types would be swappable.

    ReplyDelete