设计模式 - 建设住宅

我的计划将为我建造许多住宅。每个住宅的规格都基于一个明确的蓝图，每个住宅必须按特定的顺序建造。我想我会有一名施工人员。该船员所能做的一切，设计模式 - 建设住宅

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

然后只是项目的每个蓝图。

看来，我在想这个问题的方法，我会在最后一个程序是这样的：

每个内部函数之前，依靠功能的完成和结果后，而不是真的需要多次完成每项任务（不需要两次在家构建）。对我来说，除了我在不同地方定义和调用函数这一事实之外，这看起来与程序风格没有多大区别，这看起来像是额外的工作。我想我是问有没有办法建立一个面向对象的系统，在程序系统上提供决定性的优势（组织，易用性，灵活性等）？对于这件事，我感到非常困惑。我以程序的方式开始了这个程序，并且很快变得非常可怕。我开始重新修改它（可能是我可怜的）面向对象时尚的概念，而且它似乎仍然是一种可怕的东西。如果任何人都可以就如何以更易于管理的方式组织这些项目提供任何建议，我会非常感激。

感谢好心，布兰登

来源

2010-11-07 Orbit

我看到良好的面向对象设计让周围丑/复杂结构的一种方式。但是，如果问题很复杂，那么你不能期望摆脱复杂性，只是更好地管理它。

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

面向对象的东西往往会以两种方式变得更有趣。首先有更好的结构化技术。类有自然信息隐藏，我们有私人数据和方法。因此，构建房屋的细节隐藏在该类别内部。你可以用程序语言来完成这些事情，但通常很费力。

其次你有使用多态性的可能性，相同责任的不同实现。未来当您需要弯曲东西时，这会带来回报，例如Carpeting真的是地板的特别之王，所以您也可以介绍Tiling。

在未来的灵活性和可维护性中可以看到OO的整体收益。

来源

2010-11-07 18:13:56 djna

设计模式 - 建设住宅

回答

相关问题