设计模式——建造房屋

Question

我的计划将为我建造许多房屋。每个家庭的规格都基于一个定义的蓝图，每个家庭都必须按照特定的顺序建造。我想我会有一个施工人员。这个船员无所不能，

 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

然后只是投影每个蓝图。

看来，按照我的想法，我最终会得到一个看起来像这样的程序：

  -
   - 
    -
     - 
      - 

  -
   - 
    - 
     -
      - 

 -
 -

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

谢谢， 布兰登

Answer 1

我认为优秀的 OO 设计是围绕丑陋/复杂性构建结构的一种方式。但是，如果问题很复杂，那么您不能期望摆脱复杂性，只需更好地管理它即可。

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

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

其次，您可以使用多态性，即相同职责的不同实现。当您需要弯曲某些东西时，这会在未来得到回报，例如地毯确实是地板的特殊之王，因此您也可以引入瓷砖。

OO 的总体收益往往体现在未来的灵活性和可维护性上。