Перегруженные методы в интерфейсе

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

void Add(object item); 
void Add(object item, bool shouldDoSomething); 
void Add(object item, bool shouldDoSomething, IUltraObscureDeviceContext context);

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

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

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

Ответ 1

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

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

Если вы имеете дело с какими-то исключительными исключениями 80/20 nitty-gritty, где независимые по умолчанию значения по умолчанию почти не всегда достаточны, у вас есть несколько вариантов, ни один из которых не является хорошим:

С этим справляйтесь, как будто они всегда разные, объявляют их как интерфейсные методы и переопределяют их везде. Не очень СУХОЙ.
С этим справляйтесь, как будто они всегда разные, объявляют их как методы интерфейса и наследуют базовый класс, который обеспечивает реализацию по умолчанию 80%. Вид неуклюжий, и не очень хороший, если ваш единственный слот базового класса уже занят.
Создайте другой интерфейс, содержащий эти конкретные методы. Объявлять методы расширения с совпадающей подписью с исходным интерфейсом. В методах расширения as -проведите аргумент this на новый тип интерфейса, и если он совпадает, вызовите его там, иначе заполните значения по умолчанию. Очень напуганный, зависящий от динамического кастинга, который не настолько велик во внутреннем цикле, но он отделяет значения по умолчанию как от разработчика, так и от вызывающего, не жертвуя гибкостью для разработчиков, которые не могут принимать "значения по умолчанию по умолчанию".

Ответ 2

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

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

вы прокомментируете наличие разных реализаций для перегрузок....

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

Если вам нужно другое поведение, используйте полиморфизм. Это то, что там есть.

Ответ 3

IMO, если это объясняет интерфейс/контракт, не должно быть никаких проблем. Однако цель состоит в том, чтобы упростить вещи, выставляя интерфейс и скрывая детали. И thats, где необязательные параметры подходят. Практически объектно-ориентированные языки, такие как Python, даже не перегружают AFAIK