design pattern - building homes

My program is going to build me lots of homes. The specification for each home is based upon a defined blueprint, and each home must be constructed in a specific order. I imagine that I will have a construction crew. This crew can do everything,

 class crew

    blueprint     

    fn frame_house
        fn get_wood
          fn_drive_to_store
        fn do_framing
        get_wood
        do_framing

    fn carpet_house
        fn buy_carpet
        fn install carpet 
        buy_carpet
        do_framing

 -

and then i can give them the stack of blueprints and tell them to get to work...

each blueprint
  laborers = new crew(blueprint)
  laborers.frame_house
  laborers.carpet_house
-

Or do I want to my laborers to be more specified?

class FrameCrew inherits Crew
      fn get_wood
        fn drive_to_store
      fn do_framing
        get_wood
        do_framing
-

and then I can....

foreach blueprint
   #send crews to work with the blueprint

Or I could them in a project that has both a blueprint and a constructor acting as a foreman?

class Project

   blueprint

   fn construct
      #create and deploy crews

   class FrameCrew
   class CarpetCrew

and then just Project each blueprint.

It seems that the way I am thinking abou开发者_运维问答t this, I will end up with a program that looks like this:

  -
   - 
    -
     - 
      - 

  -
   - 
    - 
     -
      - 

 -
 -

with each inner function relying upon the completion and results of the function before it, and not really needing to complete each task more than once (don't need a home framed twice). To me, this appears really not much different that a procedural style, except for the fact that I define and call the functions in different places, which just seems like extra work. I guess I'm asking if there is a way to build an object-oriented system that offers a decisive advantage (organization, ease of use, flexibility, etc) over a procedural system? I am very confused in regards to this matter. I had started the program in a procedural fashion, and it quickly became very hideous. I started to rework it in (what is probably my poor idea of) object-oriented fashion, and it still seems to be the same sort of hideous. If anyone can offer any advice on how to organize these projects in a more manageable fashion, I would be much obliged.

thanks kindly, brandon

I see good OO design as a way of getting structure around hideousness/complexity. However if a problem is complex then you can't expect to get rid of complexity, just manage it better.

Some aspects, such as single responsibility principle, allow you to decompose the problem. So by separating frame work from carpet work you have a win in that each piece is easier to understand, but it's true that good procedural code can also achieve that.

OO stuff tends to get more interesting in two ways. First there are better structuring techniques. Classes have natural information hiding, we have private data and methods. So the details of what it means to frame a house are hidden inside that class. You can achieve things along these lines in procedural languages, but it's usually much effort.

Second you've got the possibility of using polymorphism, different implementations of the same responsibility. This pays off in the future when you need to flex things, for example Carpeting is really a special king of Flooring, so you might introduce Tiling too.

The overall payoff in OO tends to be seen in future flexibility and maintainbility.