методы конструктора в интерфейсах

Question

Методы конструктора в интерфейсах плохие?

Answer 1

Почему люди думают, что кто-то хочет создать интерфейс?

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

Интерфейс похож на контракт. Допустим, у меня есть интерфейс Queue, и я хочу убедиться, что разработчики создают конструктор с одним аргументом, который создает одноэлементную очередь (Новая очередь только с этим элементом). Почему это не должно быть частью контракта? По крайней мере, с интерфейсами Java, которые не могут быть указаны.

Answer 2

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

Если вам нужна какая-то инициализация, вам лучше использовать абстрактный класс.

Answer 3

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

Я бы не подумал, что странно делать что-то вроде:

interface IDBConnection
{
    function __construct( $connectionString );
    function executeNonQuery( $commandText, $paramters=null);
    function executeScalar( $commandText, $paramters=null);
    function executeSingle( $commandText, $paramters=null);
    function executeArray( $commandText, $paramters=null);
}

Это позволит вам создавать экземпляры сторонних классов для доступа к данным на основе простого отражения, а не просто как контракт на данные.

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

Я не видел, чтобы это было сделано, но я бы не подумал, что это странно или плохо.

Answer 4

Хотя интерфейсы не могут иметь конструкторов на большинстве языков, шаблон Factory предоставляет контракт на создание объектов, аналогичный интерфейсу. Посмотрите на это.

Answer 5

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

При этом, однако, я лично не верю, что конструктор объекта является частью интерфейса этого объекта, и поэтому добавление конструктора к интерфейсу будет препятствовать естественной гибкости, которую предоставляют интерфейсы.

Answer 6

Вы должны когда-нибудь создавать экземпляры неизменяемых полиморфных объектов через их конструктор, который требует параметров, и вам может понадобиться этот конструктор в интерфейсе по тем же причинам, по которым вам могут понадобиться другие открытые методы в интерфейсе, например…

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

$immutablePolymorphe = $userConfig['immutable_polymorphe_class'];
$immutablePolymorphe = new $immutablePolymorphe($state);
// Then do something with that polymorphe...

Так что, если вы не определили конструктор с его параметром в интерфейсе? Следовательно, причина, по которой я считаю, что конструктор в интерфейсе может быть таким же легитимным, как и любой другой публичный метод в интерфейсе ...