Шаблон дизайна для конструкторов - PullRequest
5 голосов
/ 10 февраля 2011

У меня возникла проблема с дизайном, которую я постараюсь описать ниже.

Предположим, что класс, называемый A, имеет конструктор с набором параметров.Поскольку писать все эти параметры в каждом конкретном случае утомительно и грязно, я написал другой класс, который называется StyleSheetA, который инкапсулирует все эти параметры и является единственным параметром для конструктора A. Таким образом, я могу подготовить некоторые значения по умолчаниюШаблоны StyleSheetA будут использоваться позже, и, если это необходимо, я могу их изменить.

И на этом этапе мне нужно расширить A. Предположим, B расширяет A. B будет иметь свою собственную таблицу стилей, а именно StyleSheetB.Я думаю, что будет уместно, что StyleSheetB расширяет StyleSheetA, поэтому с одним параметром таблицы стилей конструктор B может также создать свой суперкласс A. Но я боюсь возможности того, что у этого дизайна могут быть недостатки.Например, что если я решу добавить метод получения / установки для таблицы стилей?Есть ли новый способ справиться со всеми этими ситуациями?Я не в том направлении?Для тех, кто смущен, я прилагаю некоторый код здесь:


    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;
    }

Спасибо за любую помощь или предложения, также будет признателен любой из ваших критиков.Ява, так что нет поддержки дженериков.

Ответы [ 3 ]

5 голосов
/ 10 февраля 2011

Мне кажется, что вы переносите проблему слишком большого количества параметров из класса A в класс StyleSheetA.

Чтобы проиллюстрировать мою мысль, подумайте над вопросом: как бы вы описали StyleSheetA? Вероятно, в любом случае, используя конструктор, который принимает все эти параметры. Единственное преимущество, которое может дать этот дизайн, - это если у вас есть один и тот же набор значений параметров, инкапсулированных объектом StyleSheetA, который вы будете повторно использовать среди нескольких экземпляров A. Если это так, имейте в виду, что, хотя у вас будут разные экземпляры A, они будут иметь одни и те же параметры, поэтому это не лучший выбор.

Что я мог бы порекомендовать вам, так это попытаться провести рефакторинг самого класса A. Попробуйте разбить его на более мелкие классы. Если необходимо, попробуйте создать подклассы, чтобы избежать условных переходов и т. Д.

Теперь я не знаю, как выглядит ваш класс A, но, возможно, если вы это сделаете, у вас будет несколько классов, каждый со своим набором параметров. И если какой-либо из параметров является дискриминатором (то есть он определяет класс «тип»), вы сможете от него избавиться, просто используя подклассы и полагаясь на встроенную систему типов, чтобы сделать это вместо этого.

3 голосов
/ 10 февраля 2011

Рассматривали ли вы использование контейнера IoC, такого как StructureMap, для управления зависимостями конструктора? Это может облегчить многие вещи.

2 голосов
/ 10 февраля 2011

Замечания по проблеме метода получения и установки:

Конструктор в 'B' подразумевает, что дополнительные параметры (n101 +) необходимы для работы класса.Если бы вы просто расширяли класс полным списком параметров, у вас были бы методы получения и установки для n101 ... n200 в B и n1 ... n100 в A.Это предполагает, возможно, не иметь StylesheetB extension StylesheetA, но вместо этого иметь конструктор для класса B, равный B(StyleSheetA,StyleSheetB), таким образом, вы можете иметь установщик в классе A для его параметров, иметь его наследуемый и также помещать егоB для StylesheetB.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...