Неиспользуемые параметры интерфейса

Question

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

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

Когда сегодня утром я решил добавить новый метод в интерфейс, я понял, что соединение с базой данных потребуется только для одного из конкретных разработчиков, но остальным это не понадобится. Итак, это заставляет меня задуматься, я должен передать это в качестве параметра? Это необходимо для «выполнения работы», но только для одного из конкретных классов, и этот класс уже имеет соединение с базой данных. Если я передал соединение с базой данных в качестве параметра интерфейса, то остальные 29 классов не будут его использовать.

Какую линию можно нарисовать для приемлемого параметра интерфейса? К счастью, любое чтение / содержание по этой теме я тоже буду поглощать.

Answer 1

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

Это звучит для меняочень похоже на то, как интерфейс медленно превращается в нечто вроде "бога интерфейса" .Проверьте, так ли это, задав себе пару вопросов:

• Представляет ли интерфейс единую концепцию поведения в вашей модели, или он стал чем-то вроде удобной площадки для сброса сигнатур методов изнесколько понятий?Может ли это называться что-то вроде, например, Serializable, или это будет точнее называться SerializableAndSomethingElse.
• Не могли бы вы разделить интерфейс на несколько более взаимосвязанных интерфейсов, и чтобы 30 различных объектов реализовали именно те, которые им нужны?

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

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

Answer 2

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

http://theamiableapi.com/2011/08/29/considering-the-perspective-of-the-caller/

Приветствия,

Ferenc

Answer 3

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

Я быстро выполнил поиск в Google по запросу «api design», и первое попадание было:

слайды презентации Джошуа Блоха .

Его пункты, имеющие отношение к вашему вопросу:

• "Если сомневаетесь, оставьте этоout "
• 'Не позволяйте деталям реализации" просачиваться "в API"
• "Разработка API сложна", но также, "Разработка API - благородное и полезное ремесло"
• «Ожидайте ошибок»

Похоже, вам предстоит решить сложную проблему - но удачи!

Answer 4

Аргументами конструктора для ваших различных классов должны быть соавторы (или значения конфигурации), используемые при обработке.Это как .Они могут варьироваться для 30 различных реализаций.Если для некоторых требуется соединение с базой данных, а не для других, то укажите его в качестве аргумента конструктора для одного.

Интерфейс, формирующий основу для обработки, должен быть выполнен.Это Что .

Вы должны стремиться к интерфейсу, где имя API, аргументы и методы находятся на том же концептуальном уровне.Аргументы конструктора, вероятно, будут на более низком концептуальном уровне.