Конкретные классы и интерфейсы: когда использовать?

Question

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

a) Люди, начинающиеся с ALWAYS, определяющие интерфейс, а затем реализующие его в классе, даже если этот интерфейс слишком специфичен для реализации любым другим классом. - Я единственный, кто думает, что это нецелесообразно?

b) Принуждение всех «связанных» интерфейсов для получения общего (бесполезного) интерфейса, поскольку оно теперь «расширяемое» - что?

c) Что вы делаете в сценариях, где связаны два или более объекта, но очень сложно определить общие методы интерфейса из-за его основных различий?

Допустим, например, интерфейс с именем IConnection с методом Connect(). (так как большинство примеров тривиализуют интерфейсы). Проблема в том, что для разных типов классов, реализующих интерфейс IConnection, могут потребоваться разные данные для установления соединения, для некоторых может потребоваться имя пользователя и пароль, для некоторых может потребоваться какой-то специальный ключ подключения, некоторые могут вообще ничего не требовать. Метод Connect в качестве контракта является абсолютно корректным, поскольку каждому классу потребуется какой-то способ установления соединения, но требуемые данные разные.

В этом случае требуется интерфейс? Если это так, как вы определяете метод Connect? Если нет, как вы докажете, что ваши конкретные классы все еще «расширяемы»?

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

Answer 1

В вашем примере IConnection вы в основном описываете абстрактный метод Connect(), поскольку каждому классу придется реализовать свою собственную версию. Обычно (всегда?) Абстрактные методы могут быть определены только с теми же параметрами, поэтому Connect (имя пользователя, пароль) и Connect (ключ) не могут быть реализациями одного и того же метода Connect() из интерфейса.

Теперь вы можете определить его как IConnection :: Connect (SomeConnectionData) и получить UsernamePasswordConnectionData и KeyConnectionData и т. Д. И т. Д. Из этого класса SomeConnectionData, но все это было бы настолько сложно объяснить и реализовать, что его довольно хорошая подсказка, что интерфейсы и наследование не помогают ситуации.

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