Сколько конструкторов класс должен иметь?

Я обычно имею один, который может иметь некоторые параметры по умолчанию. Конструктор только сделает минимальную установку объекта, таким образом, это будет допустимо к тому времени, когда это было создано. Если мне будет нужен больше, то я создам статические методы фабрики. Отчасти как это:

class Example {
public:
  static FromName(String newname) { 
    Example* result = new Example();
    result.name_ = newname;
    return result;
  }
  static NewStarter() { return new Example(); }

private:
  Example();
}

Хорошо это не на самом деле очень хороший пример, я буду видеть, могу ли я думать о лучшем и отредактировать его в.

Мне кажется, что этот класс используется, чтобы сделать путь, путь к очень. Я думаю, что действительно необходимо осуществить рефакторинг класс и разделить его на несколько более специализированных классов. Затем можно избавиться от всех этих конструкторов и иметь инструмент для очистки, более гибкий, больше удобное в сопровождении и больше читаемого кода.

Это не было в прямом ответе на Ваш вопрос, но я действительно полагаю, что, если необходимо для класса иметь больше чем 3-4 конструкторов, это - знак, что он, вероятно, должен быть пересмотрен в несколько классов.

С уважением.

Достаточно, чтобы сделать его задачу, но помнить Единственный Принцип Ответственности, который указывает, что класс должен только нести единственную ответственность. С этим в памяти существует, вероятно, очень немного случаев, где имеет смысл иметь 9 конструкторов.

Я ограничиваю свой класс, чтобы только иметь одного настоящего конструктора. Я определяю настоящего конструктора как того, который имеет тело. У меня затем есть другие конструкторы, которые просто делегируют к реальному в зависимости от их параметров. В основном я объединяю своих конструкторов в цепочку.

При рассмотрении класса существует четыре конструктора, который имеет тело:

public MyManager(ISomeManager someManager) //this one I added
{
    this.someManager = someManager;
}

public MyManager(SomeClass someClass, DateTime someDate)
{
    if (someClass != null)
       myHelper = new MyHelper(someOtherClass, someDate, "some param");
}

public MyManager(SomeOtherClass someOtherClass, DateTime someDate)
{
    myHelper = new MyHelper(someOtherClass, someDate, "some param");
}

public MyManager(YetAnotherClass yetAnotherClass, DateTime someDate)
{
    myHelper = new MyHelper(yetAnotherClass, someDate, "some param");
}

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

Я попытался бы найти способ создать всего одного настоящего конструктора, делая или 3-го делегата конструктора в 4-м или наоборот. Я не действительно уверен, может ли первый конструктор даже вписаться, поскольку это делает что-то очень отличающееся, чем старые конструкторы.

Если Вы интересуетесь этим подходом, попытайтесь найти, что копия Рефакторинга к Шаблонам заказывает и затем переходит к странице Chain Constructors.

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

Дизайн класса должен быть то, что конструктор создает доступный объект после того, как, закончился. Если можно сделать это с 1 параметрическим усилителем или 10 параметрическими усилителями затем пусть будет так!

9 конструкторов и 6 000 строк в классе являются знаком запаха кода. Необходимо осуществить рефакторинг тот класс. Если класс имеет партию обязанностей, и затем необходимо выделить их. Если обязанности являются подобным но небольшим отклонением затем, необходимо надеяться реализовывать наследование, покупают создание интерфейсные и различные реализации.

Вашей проблемой не является число конструкторов. Наличие 9 конструкторов больше чем обычно, но я не думаю, что это обязательно неправильно. Это - конечно, не источник Вашей проблемы. Настоящая проблема состоит в том, что начальный дизайн был всеми статическими методами. Это - действительно особый случай слишком сильно связываемых классов. Теперь провальные классы связываются с идеей, что функции статичны. Нет очень, можно сделать об этом от рассматриваемого класса. Если Вы хотите сделать этот класс нестатичным, необходимо будет отменить всю эту связь, которая была записана в код других. Измените класс, чтобы быть нестатичными и затем обновить все вызывающие стороны, чтобы инстанцировать класса сначала (или добраться один от одиночного элемента). Один способ найти все вызывающие стороны состоит в том, чтобы сделать функции частными и позволять компилятору сказать Вам.

В 6 000 строк класс не очень связен. Это, вероятно, пытается сделать слишком много. В идеальном мире Вы осуществили бы рефакторинг класс (и те, которые называют его) в несколько меньших классов.

Единственный "законный" случай I видит от Вас, код - то, если половина из них использует устаревший тип, который Вы работаете для удаления из кода. Когда я работаю как это, у меня часто есть двойные группы конструкторов, где половина из них отмечена @Deprecated или @Obsolete. Но Ваш код, кажется, путь, кроме того подготавливают....

Это не просто этот класс, который необходимо взволновать по поводу рефакторинга. Это - все другие классы также. И это - вероятно, всего один поток в запутанном мотке пряжи, который является Вашей кодовой базой. У Вас есть мое сочувствие... Я нахожусь в одной лодке. Босс хочет все, что протестированная единица, не хочет переписывать код, таким образом, мы можем тест единицы. Закончите тем, что делали некоторые ужасные взломы, чтобы заставить его работать. Вы оказываетесь перед необходимостью переписывать все, что использует статический класс, чтобы больше не использовать его и вероятно раздать его намного больше..., или можно перенести его в статический прокси, это получает доступ к одиночному элементу. Тем путем Вы, по крайней мере, дразните одиночный элемент и тест тот путь.

При произвольном ограничении числа конструкторов в классе Вы могли бы закончить с конструктором, который имеет крупное количество аргументов. Я посещал бы урок с 100 конструкторами по конструктору с 100 аргументами каждый день. Когда у Вас есть много конструкторов, можно принять решение проигнорировать большинство из них, но Вы не можете проигнорировать аргументы метода.

Думайте о группе конструкторов в классе как математическая функция, отображающаяся M наборы (где каждый набор является списком аргументов единственного конструктора) к экземплярам N данного класса. Теперь скажите, класс Bar может взять a Foo в одном из его конструкторов и классе Foo берет a Baz как аргумент конструктора, поскольку мы показываем здесь:

    Foo --> Bar
    Baz --> Foo

У нас есть опция добавления другого конструктора к Панели, таким образом что:

    Foo --> Bar
    Baz --> Bar
    Baz --> Foo

Это может быть удобно для пользователей класса Панели, но так как у нас уже есть путь от Baz к Панели (через Foo), нам не нужен тот дополнительный конструктор. Следовательно, это - то, где личный выбор находится.

Но если мы внезапно добавляем новый названный класс Qux и мы находим нас нуждающимися для создания экземпляра Bar от него: мы должны добавить конструктора где-нибудь. Таким образом, это могло или быть:

    Foo --> Bar
    Baz --> Bar
    Qux --> Bar
    Baz --> Foo

ИЛИ:

    Foo --> Bar
    Baz --> Bar
    Baz --> Foo
    Qux --> Foo

Позже имел бы более ровное распределение конструкторов между классами, но является ли это лучшим решением, зависит в основном от пути, которым они собираются быть используемыми.

Как можно меньше,
Столько же по мере необходимости.

Аунсер: НЕТ

Посмотрите на Язык Дилана. У него другая система.

Создавая конструкторы, вы добавляете больше значений в свои слоты (элементы), чем на другом языке. Вы можете добавить ключевое слово init. Затем, если вы создадите экземпляр, вы можете установить слот на желаемое значение.

Конечно, вы можете установить 'required-init-keyword:', и есть другие опции, которые вы можете использовать.

Это работает, и это просто. Я не скучаю по старой системе. Написание конструкторов (и деструкторов).

(между прочим.это все еще очень быстрый язык)