Зачем нужно наследование интерфейсов? - Философия программирования

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, AlexRK, Вы писали:

ARK>>Василий уже ответил за меня: метод Get из third-party либы должен возвращать IAnimal + IPet, а не просто IPet.

AVK>Никому он ничего не должен. Констрейнтов явных нет — значит как повезет.

Признаться, не понимаю вопроса. Метод не возвращает нужный интерфейс IAnimal — все, это ошибка. То же самое если метод не принимает нужного параметра. В чем вопрос-то?

ARK>>>>Кстати, еще момент. Мне не очень нравится ситуация, когда метод возвращает "не знамо что" — интерфейс, за которым непонятно какой класс.
AVK>>>Это называется абстракция. Предлагаешь и ее отменить?
ARK>>ИМХО, не все абстракции одинаково полезны.

AVK>Какие средства абстрагирования ты предлагаешь взамен?

Взамен абстрагирования "изнутри"? Я писал в прошлом посте, предлагается вынести знание о создаваемом классе на тот уровень, на котором оно есть.

AVK>>>Т.е. возможность создания плагинов и аналогичных механизмов хороним в зародыше?
ARK>>Нет, не хороним

AVK>Хороним, потому что они все построены на том, что есть well known абстрактный контракт, и плагины его реализуют.
AVK>Да хоть 10 раз, проблемы это не решает. Код хоста принципиально не может знать, какая реализация будет у абстрактного контракта в конкретном плагине.

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

Здравствуйте, artelk, Вы писали:

A>Здравствуйте, AlexRK, Вы писали:

ARK>>Василий уже ответил за меня: метод Get из third-party либы должен возвращать IAnimal + IPet, а не просто IPet.
A>Скорее всего на практике это будет так:
A>

A>interface IAnimal {...}
A>interface IPetOnly {...} //:)
A>alias IPet = IAnimal & IPetOnly;
A>

A>Метод вернет IPet и все довольны, кроме тех кому этот IPetOnly мозолит глаза, т.к. нигде один не используется — только в связке с IAnimal.

Ну, можно и обратную ситуацию вообразить для наследования.
IAnimal, IPet и IPetButNotAnimal.

Это если предположить, что нам одинаково часто нужны и IPet, и IPetButNotAnimal.

A>Это все равно, что IList<T> разбить на IReadOnlyList<T> и IChangeOnlyList<T>

Боюсь, не все равно. Кстати, такое разделение списка может быть полезным, на мой взгляд.

Здравствуйте, AlexRK, Вы писали:

ARK>Здравствуйте, artelk, Вы писали:

A>>Здравствуйте, AlexRK, Вы писали:

ARK>>>Василий уже ответил за меня: метод Get из third-party либы должен возвращать IAnimal + IPet, а не просто IPet.
A>>Скорее всего на практике это будет так:
A>>

A>>interface IAnimal {...}
A>>interface IPetOnly {...} //:)
A>>alias IPet = IAnimal & IPetOnly;
A>>

A>>Метод вернет IPet и все довольны, кроме тех кому этот IPetOnly мозолит глаза, т.к. нигде один не используется — только в связке с IAnimal.
Еще нужно следить, чтоб IAnimal и IPetOnly не пересекались по сигнатурам методов.

ARK>Ну, можно и обратную ситуацию вообразить для наследования.
ARK>IAnimal, IPet и IPetButNotAnimal.

Это если предположить, что нам одинаково часто нужны и IPet, и IPetButNotAnimal.
А если IPetButNotAnimal нафиг не нужен, но его все равно придется делать, т.к. язык не поддерживает наследования?

A>>Это все равно, что IList<T> разбить на IReadOnlyList<T> и IChangeOnlyList<T>

ARK>Боюсь, не все равно. Кстати, такое разделение списка может быть полезным, на мой взгляд.
Зачем тебе может понадобится IChangeOnlyList?

Здравствуйте, artelk, Вы писали:

A>Здравствуйте, AlexRK, Вы писали:

ARK>>Здравствуйте, artelk, Вы писали:

A>>>Здравствуйте, AlexRK, Вы писали:

ARK>>Ну, можно и обратную ситуацию вообразить для наследования.
ARK>>IAnimal, IPet и IPetButNotAnimal.

Это если предположить, что нам одинаково часто нужны и IPet, и IPetButNotAnimal.
A>А если IPetButNotAnimal нафиг не нужен, но его все равно придется делать, т.к. язык не поддерживает наследования?

Тут вопрос только в наименовании, так ведь? Ну да, будет кривоватый IPetOnly. Так я же и привожу обратный пример для наследования — там будет ровно та же кривизна, просто в другом случае — когда нам НУЖНЫ два интерфейса, IPet и IPetButNotAnimal.

A>>>Это все равно, что IList<T> разбить на IReadOnlyList<T> и IChangeOnlyList<T>

ARK>>Боюсь, не все равно. Кстати, такое разделение списка может быть полезным, на мой взгляд.
A>Зачем тебе может понадобится IChangeOnlyList?

Ну мало ли — кому-то может нельзя считывать содержимое, а писать можно. Например — безотносительно списка — пароли можно только записывать, а читать нельзя.

Здравствуйте, AlexRK, Вы писали:

ARK>Тут вопрос только в наименовании, так ведь? Ну да, будет кривоватый IPetOnly. Так я же и привожу обратный пример для наследования — там будет ровно та же кривизна, просто в другом случае — когда нам НУЖНЫ два интерфейса, IPet и IPetButNotAnimal.
Так я не против алиасов — очень полезно было бы иметь возможность хранить объекты в посях с типом вида IA&IB. Я против замены ими механизма наследования интерфейсов.
Впринципе, если наследование сделать сахаром к генерации соответствующего интерфейса и алиаса, то было бы хорошо.
Т.е. дано:

interface IB : IA
{
  //новые методы
}

Компилятор генерит:

[Invisible]
interface IB_without_IA
{
  //новые методы
}

alias IB = IA & IB_without_IA;

Только нужно еще решить вопрос переопределения методов (то, что делается сейчас через new).

Здравствуйте, AndrewVK, Вы писали:

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

Предполагает. Ибо расчитывать каждый раз на рефакторинг *интерфейсов* — это уж больно смелое допущение.

AVK>И вопросы, вобщем то, совершенно параллельны конкретно наследованию, и больше относятся к статической типизации в целом.

Эти вопросы не относятся к статической типизации в целом. Они относятся конкретно к наследованию и к тем зависимостям, которые оно вводит.

Здравствуйте, AndrewVK, Вы писали:

ВВ>>Вопрос в общем-то остается прежним — зачем *заставлять* так делать? В реальности, это единственный вопрос, на который и нужно ответить в рамках этой темы.
AVK>Затем же, зачем заставлять в статически типизированных языках контролировать соответствие типов. Наследование интерфейсов — неотъемлемая часть контракта. Если я хочу, чтобы любая реализация IPet реализовывала IAnimal (по семантике, проект у меня такой), то я хочу чтобы компилятор это жестко контролировал.

Связать IPet и IAnimal можно и другими способами, кроме наследования. Ты ведь не просто какие-то интерфейсы выставляешь, но и, скажем, проектируешь некое API, которое с ними работает. Ну и в сигнатурах функций указываешь (IPet IAnimal), вместо последнего.

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

ВВ>>К тому же все эти примеры с GetPet/GetItems немного странные. Либо это вообще неполиморфные функции, и тогда они должны возвращать конкретный класс
AVK>Абстракции, видишь ли, бывают многоуровневыми. И GetPet таки полиморфен (реализаций IPet может быть много), просто IAnimal это абстракция уровнем выше.

Значит, он должен возвращать не IAnimal, а что-то другое. Например:

interface IPetProvider<T> where T : IPet
{
  T GetPet();
}

IPetProvider<FishPet>....

Что, кстати, вполне логично, т.к. поставщик рыбок может и не продавать птичек.

AVK>Странно другое — что вы почему то уверены, что достаточно ровно два уровня абстракции на все случаи жизни — одноуровневые интерфейсы и один уровень реализации.

Во-первых, чтобы понять, зачем что-либо нужно, самый простой способ — убрать это, и посмотреть, что получается. Таким образом, например, появилась комбинаторика.
Во-вторых, здесь не два уровня абстракции, а бесконечное множество:

FishPet = IPet IFish IAnimal

ВВ>>, а не интерфейс, либо они являются членами, скажем, генерик-класса, и тогда они тем более не будут возвращать интерфейс, а скорее некое T, на которое будут навешаны констрейнты.

AVK>Да дались вам эти дженерики. Они ничего принципиально не меняют. Дженерики это статический полиморфизм (детали его реализации в дотнете несущественны), а наследование — динамический. Они в общем случае не взаимозаменяемы. И именно из-за попытки заменить одно другим появляются идеи вроде:

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

AVK>

AVK>Мне не очень нравится ситуация, когда метод возвращает "не знамо что" — интерфейс, за которым непонятно какой класс. ИМХО, код верхнего уровня всегда должен знать конкретные типы ...

AVK>Вы уж либо крестик снимите, либо трусы оденьте. Либо отказ от динамического полиморфизма полностью, либо он таки есть, неважно как реализован, наследованием/реализацией интерфейсов, или исчислением каких нибудь кортежей типов интерфейсов.

Речь не идет об отказе от динамического полиморфизма. Интерфейсы рассматриваются прежде всего в ООП ключе. А следовательно, там так или иначе рантайм-диспатч, независимо от наличия или отсутствия наследования.

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

Здравствуйте, AlexRK, Вы писали:

AVK>>Никому он ничего не должен. Констрейнтов явных нет — значит как повезет.

ARK>Признаться, не понимаю вопроса. Метод не возвращает нужный интерфейс IAnimal — все, это ошибка.

И? Понимаешь, если я при проектировании сразу заложил наследование IPet от IAnimal, такую ошибку в принципе нельзя сделать, компилятор не даст. Это точно такой же контроль, как и проверка соответсвия сигнатуры реализуемого метода, к примеру. Еще один уровень контроля.

AVK>>Какие средства абстрагирования ты предлагаешь взамен?

ARK>Взамен абстрагирования "изнутри"? Я писал в прошлом посте, предлагается вынести знание о создаваемом классе на тот уровень, на котором оно есть.

Ничего не понял.

AVK>>Да хоть 10 раз, проблемы это не решает. Код хоста принципиально не может знать, какая реализация будет у абстрактного контракта в конкретном плагине.

ARK>Код, использующий плагины, на определенном уровне все равно где-то обязательно знает конкретные типы.

Конечно же нет.

ARK> Такая точка должна быть. Читает из файла конфигурации названия классов, метаданные или еще что-то в этом роде.

И? Как это знание в рантайме поможет компилятору?