設計模式-建築房屋

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的總體收益往往體現在未來的靈活性和可維護性上。