设计模式 - 建房

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的东西往往会以两种方式变得更有趣。首先，有更好的结构化技术。类有隐藏的自然信息，我们有私有数据和方法。因此，构建房屋的含义细节隐藏在该类中。你可以用程序语言来实现这些方面的事情，但通常需要很多努力。

其次，你有可能使用多态，同一责任的不同实现。当你需要弯曲东西时，这会得到回报，例如Carpeting真的是一个特殊的地板之王，所以你也可以介绍Tiling。

OO的整体收益往往会出现在未来的灵活性和可维护性中。