构造器的设计模式

我一直在设计问题上受到挑战，我将在下面进行介绍。构造器的设计模式

假设一个类，称为A，有一个带有一堆参数的构造函数。由于在每个实例化中写入所有这些参数都很累人，所以我编写了另一个类，将其称为StyleSheetA，它封装了所有这些参数，并且是构造函数的唯一参数。这样，我可以准备一些默认值StyleSheetA模板稍后会用到，如果需要的话，我可以修改它们。

在这一点上，我需要扩展A.假设B扩展A. B将有它自己的样式表，即StyleSheetB。我认为StyleSheetB扩展StyleSheetA是合适的，所以对于一个样式表参数，B的构造函数也可以构造它的超类A.但是我担心这种设计可能存在缺陷。例如，如果我决定为样式表添加一个getter/setter？有没有一种新颖的方式来处理所有这些情况？我错了吗？对于那些谁是困惑，我在这里附上一些代码：


    class A 
    { 
     StyleSheetA ss; 

     A(StyleSheetA ss) 
     { 
      this.ss = ss; 
      // Do some stuff with ingredients of styleSheet 
     } 
    } 
    class StyleSheetA 
    { 
     int n1; 
     int n2; 
     // : 
     // : 
     int n100; 
    } 

    class B extends A 
    { 
     B(StyleSheetB ss) 
     { 
      super(ss); 
      // Do some stuff with ingredients of styleSheet 
     } 
    } 
    class StyleSheetB extends StyleSheetA 
    { 
     int n101; 
     int n102; 
     // : 
     // : 
     int n200; 
    }

谢谢你的任何帮助或建议，也可以是任何的批评可以理解的。

编辑：我在java中开发，所以没有泛型支持。

来源

2011-02-09 ozan k

对于我正在开发的语言来说，这并不明显（但对我而言），但通常泛型/模板可以帮助解决此问题。通过将A类变为A ，您可以在从中派生类型时指定组合的类型（例如StyleSheetB）：B类延伸A 。如果你没有这样的功能，试试C＃;） – 2011-02-09 21:38:46

是的，你的解决方案将是一个很好的方法，但不幸的是我用java开发，并且没有通用的支持。谢谢。 – 2011-02-09 21:41:42

你应该添加一个java-me标签。 ;） – weltraumpirat 2011-02-09 21:48:34

您是否考虑过使用IoC容器（如StructureMap）来管理构造函数的依赖关系？这可能会使这件事情变得更容易。

来源

2011-02-09 21:28:41

在我看来，你只是将参数从A级过多到StyleSheetA级的问题。

为了说明我的观点，请考虑以下问题：如何实例化StyleSheetA？无论如何，可能使用一个接受所有这些参数的构造函数。此设计可能给您带来的唯一好处是，如果您有一组由StyleSheetA对象封装的相同参数值集合，您可以在多个A实例中重复使用该对象。如果是这样，请记住，虽然你有不同的A实例，但它们会共享相同的参数，所以它不是一个好的选择。

我可以推荐你的是尝试重构你的班级A本身。尝试将其分解成更小的类。如果需要，尝试创建子类以避免条件分支等。

现在，我不知道您的课程A的外观如何，但是如果您这样做，您将拥有几个类，每个类都有自己的设置的参数。如果任何参数是一个鉴别器（意味着它决定了“类型”类），那么只需使用子类，并依靠内置类型系统来完成它，就可以摆脱它。

来源

2011-02-09 21:32:05

在吸气和setter问题甲想法：

在“B”的构造意味着附加参数（N101 +）所必需的类的操作。如果你只是用一个完整的参数列表来扩展这个类，那么你可以在B和A的n1 ... n100中获得n101 ... n200的获得者和设置者。这表明也许没有StylesheetB扩展StylesheetA，而是让类B的构造函数为B(StyleSheetA,StyleSheetB)，这样你可以在类A中为它的参数设置一个setter，让它继承并且在B中为StylesheetB放置一个。

来源

2011-02-09 21:44:45 dfb

构造器的设计模式

回答

相关问题