Использовать наследование интерфейса или просто реализовать все интерфейсы напрямую? - PullRequest
1 голос
/ 27 февраля 2010

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

Рассмотрим следующие три интерфейса, третий наследует два других

interface IOne {
}

interface ITwo {
}

// interface inheritance
interface IAll : IOne, ITwo {
}

Лучше ли

class C : IOne, ITwo { ... }

или

class C : IAll { ... }

Если последнее может быть полезным, то почему бы просто не создать IAll, чтобы все методы IOne и ITwo не наследовали от них? Ведь это интерфейс.

Является ли наследование интерфейса практичным, а не просто полезным?

Ответы [ 5 ]

6 голосов
/ 27 февраля 2010

Хороший способ подумать об «наследовании» интерфейса - полностью забыть, что он называется «наследованием». В конце концов, очевидно, что «базовый» интерфейс не вносит функциональность в «производный» интерфейс; все, что он вносит, это обещание, что будут определенные члены.

Отношения деривации классов обычно подразумевают отношения типа "это что-то вроде". Исключение NullReferenceException является своего рода исключением. Отношения деривации интерфейса вовсе не подразумевают этого - бессмысленно говорить, что IEnumerable<T> является своего рода IDisposable.

Скорее, наследование интерфейса означает, что "тип, который реализует IEnumerable<T>, требуется также для реализации IDisposable. То есть наследование интерфейса не означает" это своего рода это ", а скорее" каждая реализация этого требуется также реализовать это ".

Это делает его более убедительным?

2 голосов
/ 27 февраля 2010

Делай то, что семантически правильно. Не делайте что-нибудь, только чтобы сохранить набор текста в дополнительном интерфейсе.

Если 'IAll' - это понятие, которое имеет значение в вашей программе, хорошо, используйте его. Если это просто способ не набирать «IFirst, ISecond», не делайте этого.

1 голос
/ 27 февраля 2010

Могут быть методы, которым нужен аргумент IAll - поэтому, если вы соответствуете требованиям для реализации всего IAll, это удобно сделать, а не просто реализовать каждый из расширяемых интерфейсов!

Обычно, конечно, интерфейсы не пусты, поэтому есть определенные (возможно, небольшие) затраты на реализацию одного и / или другого (разные, несколько методов должны быть реализованы). Если, скажем, у IFirst есть метод foo, а у ISecond есть метод bar, то имеет смысл расширить оба в IBoth, даже если это не добавляет дальнейших необходимых методов - это позволяет методу четко выразить, что ему нужен аргумент, который имеет оба метода, foo и bar.

Если бы все интерфейсы в мире были пусты, само их использование (а тем более расширение их за счет еще более пустого интерфейса) было бы намного более сомнительно, конечно! -)

1 голос
/ 27 февраля 2010

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

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

class C : IOne, ITwo { ... }

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

0 голосов
/ 27 февраля 2010

Я бы пошел с первого подхода, мне это намного понятнее. Второй кажется искусственным, ИМО.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...