Почему конструкторы злые?

Question

Я вспоминаю, что читал статью о строителях, которые являются злыми (но не могут это определить).Автор отметил, что конструкторы являются частным случаем методов;но имеют ограничения (например, они не могут иметь возвращаемого значения).

Являются ли конструкторы злыми?Лучше не иметь конструкторов и вместо этого полагаться на метод, такой как Initialize, наряду со значениями по умолчанию для переменных-членов?

(Ваш ответ может быть специфичным для C # или Java, если вы должны определить язык.)

Answer 1

Звучит как Аллен Голуб. Можно утверждать, что конструкторы злые исключительно для привлечения веб-трафика :) Они не более злые, чем любая другая языковая конструкция. У них есть хорошие и плохие последствия. Конечно, вы не можете их устранить - нет способа построить объекты без них!

Что вы можете сделать, однако, и это тот случай, который делал Аллен, так это то, что вы можете ограничить свой фактический вызов их и вместо этого отдавать предпочтение, когда это разумно, заводским методам, таким как Initialize. Причина этого проста: она уменьшает связь между классами и упрощает замену одного класса другим во время тестирования или при развитии приложения.

Представьте, что ваше приложение выполняет что-то вроде

DatabaseConnection dc = new OracleDatabaseConnection(connectionString);
dc.query("...");

и представьте, что это происходит в сотне мест в вашем приложении. Теперь, как вы тестируете модулем любой класс, который делает это? А что происходит, когда вы переходите на Mysql, чтобы сэкономить деньги?

Но если вы сделали это:

DatabaseConnection dc = DatabaseConnectionFactory.get(connectionString);
dc.query("...");

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

Редактировать: я не могу найти статью "конструкторы", но вот его extends - это зло one, а вот его добытчики и сеттеры - злые one.

Answer 2

Это не так.На самом деле, существует особый шаблон, известный как Inversion of Control, который позволяет изобретательно использовать конструкторы для удобного разделения кода и упрощения обслуживания.Кроме того, некоторые проблемы могут быть решены только с помощью конструкторов не по умолчанию.

Answer 3

Конструкторы не являются злом, но (по крайней мере, в Java) часто лучше вместо этого использовать статические фабричные методы (которые, конечно, используют конструкторы внутри).

Вот несколько цитат из Effective Java , Item 1: Рассмотрим статические фабричные методы вместо конструкторов :

Одно преимущество статической фабрики методы в том, что, в отличие от конструкторов, у них есть имена. Если параметры для конструктор не, в и из сами опишите объект вернулся, статическая фабрика с удачно выбранное имя проще в использовании и полученный код клиента легче читать.

...

Второе преимущество статической фабрики методы в том, что, в отличие от конструкторов, они не обязаны создавать новый объект каждый раз, когда они вызваны. это позволяет неизменным классам (пункт 15) использовать предварительно построенные экземпляры или кешировать экземпляры как они есть построено, и распределить их многократно, чтобы избежать создания ненужные дубликаты объектов.

...

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

...

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

Map<String, List<String>> m =
new HashMap<String, List<String>>();

...

Основной недостаток предоставления только статические фабричные методы классы без публичного или защищенного конструкторы не могут быть разделены на подклассы.

...

Второй недостаток статического фабричные методы в том, что они не легко отличимы от других статические методы.

Answer 4

Evil?Нет.

Для вызова конструктора необходимо вызвать "new", что связывает вас с конкретной реализацией.Фабрики и внедрение зависимостей позволяют вам быть более динамичными в отношении типов времени выполнения, но они требуют программирования для интерфейсов.

Я думаю, что последние более гибкие, но конструкторы злые?Это заходит слишком далеко, точно так же, как наличие внешнего интерфейса для всего заходит слишком далеко.

Answer 5

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

http://en.wikipedia.org/wiki/Constructor_(object-oriented_programming)

Answer 6

Конструкторы позволяют инициализировать списки и другие полезные вещи. Невозможно динамически инициализировать объект в массиве (в котором не используются указатели на объекты) без конструктора копирования.

Нет, они не злые.

Это особые случаи.

Answer 7

Вот одна статья, которая рассматривает, являются ли конструкторы вредными , а не "злыми".Это в основном в контексте JavaScript / Es6, но аргументы могут иметь место для любого языка, в котором есть конструкторы.

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

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

Это делает вашу программу проще и, следовательно, менее подверженной ошибкам.Обратите внимание, что у Smalltalk никогда не было «конструкторов».

https://medium.com/@panuviljamaa/constructors-considered-harmful-c3af0d72c2b1

Answer 8

Я в некоторой степени поднял этот вид вибрации из * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 1004Часть изложенного им обсуждения я трактую как критику «толстых конструкторов», если не конструкторов вообще.

Смысл этого аргумента, по крайней мере, как я понял, заключался в том, что конструкторы, которые принимаютвсе, что хочет объект, побуждает вас применять корректность с помощью конструктора, а не применять корректность с помощью тестов.Конструкторы, как правило, раздуваются, чтобы делать именно это, поэтому, если это вас беспокоит, вы можете считать это злой чертой в концепции конструктора.В своем выступлении он говорит, что предпочитает требовать от объекта «иметь» другой объект только тогда, когда это необходимо для чего-то, вместо того, чтобы требовать его при строительстве.

Answer 9

Вопрос может быть не о конструкторах в Java или C #, а о конструкторах в javascript.В Javascript конструкторы могут быть источником тонких ошибок.Многие книги Javascript рекомендуют начинающим держаться подальше от конструкторов.

Для более подробного обсуждения зла конструкторов и нового ключевого слова в виде javascript: Считается ли вредоносным "новое" ключевое слово JavaScript?

Answer 10

Конструкторы хороши при соблюдении нормальных парадигм программирования ОО. Существуют ситуации, когда вам может потребоваться наложить дополнительные ограничения на то, как создаются объекты, поэтому в некоторых случаях лучше подойдет шаблон Factory с частными ctors. Существует также философия / лучшая практика, которая гласит, что создание объектов должно быть таким же, как инициализация, и в этом случае конструкторы являются единственным реальным вариантом вне имеющихся у вас фабрик.

(фабрики все еще используют конструкторы, конечно же)