Я правильно понимаю, что интерфейсы имеет смысл писать только для тех классов, которые:
— втунри компонента(сборки) могут быть представленые несколькими реализациями; (для удобства подмены класса)
— которые торчат из сборки; (для удобства развертывания).
Интерфейсы, на мой взгляд, похожи на промежуточный вариант между строго-типизированным программированием и
программированием с динамической типизацией. Вообще, я вижу противоречие: с одной стороны все хотят знать все о своем коде еще при компиляции, а
с другой стороны — имть возможность оперировать какими угодно объектами в каких угодно контекстах, т.е. приводить объекты к разным интерфесам в ран-тайме.
Поясните, пожалуйста.
Здравствуйте, Ocenochka, Вы писали:
O>Поясните, пожалуйста.
В первую очередь без интерфейсов не разрешить циклические зависимости. Например, класс А использует Б, Б использует А, находятся в разных сборках — не компилируется. Нужно выносить описание одного из них в интерфейс в независимую сборку, и определять оба через этот интерфейс, а не через друг друга.
Друга ищи не того, кто любезен с тобой, кто с тобой соглашается, а крепкого советника, кто полезного для тебя ищет и противится твоим необдуманным словам.
O>>Поясните, пожалуйста. ОВ>В первую очередь без интерфейсов не разрешить циклические зависимости. Например, класс А использует Б, Б использует А, находятся в разных сборках — не компилируется. Нужно выносить описание одного из них в интерфейс в независимую сборку, и определять оба через этот интерфейс, а не через друг друга.
Приведите, пожалуйста, пример из жизни — никак не могу придумать в каком контексте нужно так извращаться?
Здравствуйте, Keith, Вы писали:
K> Приведите, пожалуйста, пример из жизни
Накладная определяется через счёт (class Invoice: Bill). Сборка Invoice.dll содержит reference на Bill.dll. Понадобилось в счёте обратиться к накладной и получить, скажем, склады, чтобы вычислить время доставки и вписать в примечание (а в счёте складов нет, появляются только в накладной, приводить Invoice к Bill бесполезно). Сборку Invoice в ссылки к Bill не добавить — циклическая зависимость. Как ещё обратиться к свойствам Invoice?
Друга ищи не того, кто любезен с тобой, кто с тобой соглашается, а крепкого советника, кто полезного для тебя ищет и противится твоим необдуманным словам.
Здравствуйте, Ocenochka, Вы писали:
O> Я правильно понимаю, что интерфейсы имеет смысл писать только для тех классов, которые: O>- втунри компонента(сборки) могут быть представленые несколькими реализациями; (для удобства подмены класса) O>- которые торчат из сборки; (для удобства развертывания).
Основная решаемая проблема — замена "наследования реализации". Можешь по этим словам поискать на данном сайте. Неоднократно обсуждалось.
O> Интерфейсы, на мой взгляд, похожи на промежуточный вариант между строго-типизированным программированием и O>программированием с динамической типизацией.
Динамич. типизация и строготипизированность — перпендикулярны друг другу.
K>> Приведите, пожалуйста, пример из жизни ОВ>Накладная определяется через счёт (class Invoice: Bill). Сборка Invoice.dll содержит reference на Bill.dll. Понадобилось в счёте обратиться к накладной и получить, скажем, склады, чтобы вычислить время доставки и вписать в примечание (а в счёте складов нет, появляются только в накладной, приводить Invoice к Bill бесполезно). Сборку Invoice в ссылки к Bill не добавить — циклическая зависимость. Как ещё обратиться к свойствам Invoice?
Как необычно, объектная модель одной и той же предметной области — в разных сборках... Не думал, что такое бывает. А зачем?
O>> Я правильно понимаю, что интерфейсы имеет смысл писать только для тех классов, которые: O>>- втунри компонента(сборки) могут быть представленые несколькими реализациями; (для удобства подмены класса) O>>- которые торчат из сборки; (для удобства развертывания). GZ>Основная решаемая проблема — замена "наследования реализации". Можешь по этим словам поискать на данном сайте. Неоднократно обсуждалось.
Я думал, это механихм повторного использования когда в ситуации, когда существует зависимость типа "является"... Ладно. Понял. Вопрос спорный.
O>> Интерфейсы, на мой взгляд, похожи на промежуточный вариант между строго-типизированным программированием и O>>программированием с динамической типизацией. GZ>Динамич. типизация и строготипизированность — перпендикулярны друг другу.
Я так и написал. А так же я написал, что не понимаю, как технологии могут стремится к противоположностям.
Здравствуйте, Keith, Вы писали:
K> Как необычно, объектная модель одной и той же предметной области — в разных сборках...
Это уже как душа пожелает, где проводить границы между предметными областями и какими единицами развёртывать. Некоторые вообще 10-метровый *.exe на все пользовательские машины каждый день копируют, и ничего, довольны.
K> Не думал, что такое бывает. А зачем?
"Понимание приходит с опытом."
Друга ищи не того, кто любезен с тобой, кто с тобой соглашается, а крепкого советника, кто полезного для тебя ищет и противится твоим необдуманным словам.
Здравствуйте, Ocenochka, Вы писали:
O> Я так и написал.
Нет, ты написал не так.
O> А так же я написал, что не понимаю, как технологии могут стремится к противоположностям.
Перпендикулярно != противоположно. Динамическая типизация, не является противоположностью строгой типизации.
Это две совершенно разные характеристики, типизация может быть динамической/статической и, в то же время, слабой/строгой.
Чтоже касается первоначального вопроса, то интерфейс — это встроеный в язык способ, явно описать контракт взаимодействия между сущностями системы.
Мы уже победили, просто это еще не так заметно...
