Перегруженные методы в интерфейсе - PullRequest
Новая
       29

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

17 голосов
/ 26 января 2011

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

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

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

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

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

Ответы [ 3 ]

8 голосов
/ 26 января 2011

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

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

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

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

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

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

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

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

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

0 голосов
/ 26 января 2011

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

...