Design patterns 设计模式-建造住宅

我的计划将为我建造许多房屋。每个住宅的规格都基于一个定义的蓝图，每个住宅必须按照特定的顺序建造。我想我会有一个施工队。这个船员什么都能做

 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

 -

然后我可以给他们一堆蓝图，告诉他们开始工作

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

还是我想让我的劳动者更具体

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

然后我就可以

foreach blueprint
   #send crews to work with the blueprint

或者我可以在一个既有蓝图又有一个作为领班的建造师的项目中使用它们

class Project

   blueprint

   fn construct
      #create and deploy crews

   class FrameCrew
   class CarpetCrew

然后只需规划每个蓝图

看来我在思考这个问题的时候，最终会得到一个类似这样的程序：

  -
   - 
    -
     - 
      - 

  -
   - 
    - 
     -
      - 

 -
 -

每个内部功能都依赖于之前功能的完成情况和结果，不需要多次完成每个任务（不需要两次）。对我来说，这与过程风格似乎没有太大区别，除了我在不同的地方定义和调用函数，这似乎是额外的工作。我想我是在问，是否有一种方法可以构建一个面向对象的系统，与过程系统相比，它具有决定性的优势（组织性、易用性、灵活性等）？我对这件事感到很困惑。我以程序化的方式开始了这个项目，它很快变得非常可怕。我开始以面向对象的方式重新编写它（这可能是我的拙劣想法），但它似乎仍然是同样可怕的。如果有人能就如何以更易于管理的方式组织这些项目提供任何建议，我将不胜感激

谢谢你，

---

brandon

我认为好的OO设计是一种解决隐藏性/复杂性的方法。然而，如果一个问题是复杂的，那么你不能期望摆脱复杂性，只是更好地管理它

某些方面，例如单一责任原则，允许您分解问题。因此，通过将框架工作与地毯工作分开，您可以获得一个胜利，因为每一部分都更容易理解，但好的过程代码也可以实现这一点

面向对象的东西往往在两个方面变得更有趣。首先，有更好的结构化技术。类有自然信息隐藏，我们有私有数据和方法。因此，建造房屋意味着什么的细节隐藏在这个类中。您可以用过程语言实现这些目标，但通常需要付出很大的努力

其次，您有可能使用多态性，相同职责的不同实现。这在将来你需要弯曲东西时是值得的，例如，地毯确实是一种特殊的地板，所以你也可以引入瓷砖

OO的总体回报往往体现在未来的灵活性和可维护性上