构造函数的设计模式

oza*_*n k 5 java constructor design-patterns

我受到设计问题的挑战,我将在下面介绍.

假设一个类(称为A)具有带有一堆参数的构造函数.由于在每个实例化中编写所有这些参数都很累,所以我编写了另一个类,称之为StyleSheetA,它封装了所有这些参数,并且是A构造函数的唯一参数.这样,​​我可以准备一些默认值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;
    }
Run Code Online (Sandbox Code Playgroud)

感谢您的任何帮助或建议,也欢迎任何评论家.

编辑:我正在使用java开发,因此没有泛型支持.

Gor*_*vic 5

在我看来,你只是在移动从一个类A到另一个类的参数太多的问题StyleSheetA.

为了说明我的观点,请想一想这个问题:你将如何实例化StyleSheetA?无论如何,可能使用接受所有这些参数的构造函数.此设计可能给您带来的唯一好处是,如果您有一组相同的参数值,StyleSheetA这些参数值将由您将在多个实例之间重用的对象封装A.如果是这样,请记住,虽然你有不同的实例,A他们会分享相同的参数,所以这不是一个好的选择.

我可以推荐你的是尝试重构你自己的课程A.尝试将其分解为更小的类.如果是nesseccary,请尝试创建子类以避免条件分支等.

现在,我不知道你的班级是怎么A样的,但是如果你这样做,你将会有几个类,每个类都有自己的一组参数.如果任何参数是一个鉴别器(意味着它确定了类"类型"),你将能够摆脱它,只需使用子类,并依靠内置类型系统来代替它.


Ada*_*kis 3

您是否考虑过使用 IoC 容器(例如 StructureMap)来管理构造函数依赖项?这可能会让很多事情变得更容易。

  • 我同意@Adam 的观点:投反对票而不给出解释是不好的。它也无法帮助任何人理解为什么答案没有帮助。 (3认同)