Возможно.
Но тогда, имхо, неизбежно нужно признать, что если Comparer/Comparable и Opener/Openable ничем не отличаются, то какой-нибудь IObject тоже вполне имеет право на жизнь, c каким-нибудь методом Object::DoSomething(Subject).
Т.е. я думаю, что абстракция должна всё же иметь некие рамки, и мне очень интересно понять для себя, исходя из какого принципе эти рамки ставить.
Как вариант: Comparer/Comparable даёт хоть какое-то представление, чего можно ожидать в результате, а вот Opener/Openable - уже не даёт. имхо.
Т.е. понятие интерфейса как "контракта взаимодействия" должно всё же нести за собой некую семантику этого взаимодействия.
Только вот почему-то IComparer/IComparable у меня не вызывает неприятия, а вот Opener/Openable - вызывает. Сижу вот и думаю, почему.
Интересно, это только у меня так?
Для пущей ясности, озвучу свою позицию в терминах интерфейсов:
В моём понимании, ключ от амбара (квартиры, сейфа в банке) имплементирует IPermission, а гаечный ключ - какой-нибудь ITool, или IHelper. И поэтому по сути своей, они совершенно разные, хоть и называются одинаково, и крутиться могут :)
Может быть, так будет яснее, что я имею в виду.
А если мы их все пытаемся втиснуть в рамки одной иерархии - разумеется, будут проблемы. Это я и пытался сказать с самого начала, что автор в примере смешивает действие ключа как механического tool-а (вставить, провернуть и т.д.) и как средства получения доступа к чему-то.
Теперь менее сумбурно? :)
Да, пожалуй, что сумбурно. Органичусь и я постулатами, ибо мы кажется спорим вообще о разных вещах :)
1. Совершенно согласен: строить архитектуру на базе интерфейсов - можно, нужно и вообще это единственный правильный путь, который завещал Великий Ленин. Алюминь!
2. Совершенно неуместно доказывать плюсы интерфейсов, используя в качестве аргумента кривую архитектуру, особенно утверждая, что всякое наследование реализации - это зло.
3. Принцип Интерфейс < - имплементация < - расширенная имплементация - это есть не только приемлемо, но часто даже гуд.
4. Принцип Интерфейс < - имплементация < - замещённая имплементация - это в большинстве случаев есть бэд, а часто и вообще неприемлемо.
ЗЫ: Будучи увлечён в круговорот своих сумбурных мыслей, я Вас спутал с автором топика. Искренне прошу пардона.
Угу, есть у меня один знакомый, который как-то в одной ситуации предлагал сделать один из параметров интерфейса строковым, под предлогом, что в строку всё что угодно сериализовать. Тоже о высоких материях рассуждал, об абстракции.... Дескать, смотрите как у нас всё абстрактно будет - мы же всё, что угодно, в строку запихать можем!
А в Вашим примере - ключ не должен ничего открывать, он должен доказать, что его обладатель имеет право на окрытие чего-либо. Каким образом это передаётся (структурой зубчиков, данными из встроенного чипа или штрих-кодом - дело реализации).
Это и есть главное, что их объединяет - то что все ключи (будь они комнатные, амбарные или магнитные) являются пропуском.
А если этого не понимать - разумеется буду проблемы при наследовании реализаций. Вы выстроили архитектуру, которая требует замещения наследуемой реализации, вместо её расширения, и говорите "посмотрите, какая гадость это ваше наследование реализации"!
Разумеется, когда мы полностью замещаем унаследованную реализацию - это плохой признак. Который говорит, что c архитектурой что-то не то, что у нас в одной куче несовместимые вещи.
Вы бы ещё гаечные ключи туда добавили...
ЗЫ: Интерфейсы - замечательная штука, и ни одна мало-мальски серьёзная система без них нормально построена быть не может, но наличие интерфейсов само по себе не избавляет от продумывания архитектуры ;)
Всё равно не согласен. И имхо, не должно быть в интерфейсе ключа метода Open :)
Потому что главное в ключе не то, что он может всовываться и поворачиваться, а структура зубчиков ;)
А то, что старые модели ключей для передачи структуры зыбчиков надо всовывать и поворачивать - это всего лишь недостатки реализации ;)
Просто у меня тут крамольная мысль возникла, что Ключ вообще не должен ни чего открывать ;)
В Вашем примере, он на самом деле пассивен, по сути своей, и используется лишь как вспомогательное средство для открывания двери.
На мой взгляд, именно игнорирование этого и было первопричиной трудностей, а вовсе не наследование реализации.
Разумеется, очень имхостое имхо.
Хорошая статья, с точки зрения "пропаганды" интерфейсов.
Но пример, имхо, уж сильно неудачный. Должен ли Ключ уметь открывать пиво? Банку с консервами? Выдвижной ящик в столе? ;)
Но тогда, имхо, неизбежно нужно признать, что если Comparer/Comparable и Opener/Openable ничем не отличаются, то какой-нибудь IObject тоже вполне имеет право на жизнь, c каким-нибудь методом Object::DoSomething(Subject).
Т.е. я думаю, что абстракция должна всё же иметь некие рамки, и мне очень интересно понять для себя, исходя из какого принципе эти рамки ставить.
Как вариант: Comparer/Comparable даёт хоть какое-то представление, чего можно ожидать в результате, а вот Opener/Openable - уже не даёт. имхо.
Т.е. понятие интерфейса как "контракта взаимодействия" должно всё же нести за собой некую семантику этого взаимодействия.
Интересно, это только у меня так?
В моём понимании, ключ от амбара (квартиры, сейфа в банке) имплементирует IPermission, а гаечный ключ - какой-нибудь ITool, или IHelper. И поэтому по сути своей, они совершенно разные, хоть и называются одинаково, и крутиться могут :)
Может быть, так будет яснее, что я имею в виду.
А если мы их все пытаемся втиснуть в рамки одной иерархии - разумеется, будут проблемы. Это я и пытался сказать с самого начала, что автор в примере смешивает действие ключа как механического tool-а (вставить, провернуть и т.д.) и как средства получения доступа к чему-то.
Теперь менее сумбурно? :)
1. Совершенно согласен: строить архитектуру на базе интерфейсов - можно, нужно и вообще это единственный правильный путь, который завещал Великий Ленин. Алюминь!
2. Совершенно неуместно доказывать плюсы интерфейсов, используя в качестве аргумента кривую архитектуру, особенно утверждая, что всякое наследование реализации - это зло.
3. Принцип Интерфейс < - имплементация < - расширенная имплементация - это есть не только приемлемо, но часто даже гуд.
4. Принцип Интерфейс < - имплементация < - замещённая имплементация - это в большинстве случаев есть бэд, а часто и вообще неприемлемо.
ЗЫ: Будучи увлечён в круговорот своих сумбурных мыслей, я Вас спутал с автором топика. Искренне прошу пардона.
А в Вашим примере - ключ не должен ничего открывать, он должен доказать, что его обладатель имеет право на окрытие чего-либо. Каким образом это передаётся (структурой зубчиков, данными из встроенного чипа или штрих-кодом - дело реализации).
Это и есть главное, что их объединяет - то что все ключи (будь они комнатные, амбарные или магнитные) являются пропуском.
А если этого не понимать - разумеется буду проблемы при наследовании реализаций. Вы выстроили архитектуру, которая требует замещения наследуемой реализации, вместо её расширения, и говорите "посмотрите, какая гадость это ваше наследование реализации"!
Разумеется, когда мы полностью замещаем унаследованную реализацию - это плохой признак. Который говорит, что c архитектурой что-то не то, что у нас в одной куче несовместимые вещи.
Вы бы ещё гаечные ключи туда добавили...
ЗЫ: Интерфейсы - замечательная штука, и ни одна мало-мальски серьёзная система без них нормально построена быть не может, но наличие интерфейсов само по себе не избавляет от продумывания архитектуры ;)
Потому что главное в ключе не то, что он может всовываться и поворачиваться, а структура зубчиков ;)
А то, что старые модели ключей для передачи структуры зыбчиков надо всовывать и поворачивать - это всего лишь недостатки реализации ;)
В Вашем примере, он на самом деле пассивен, по сути своей, и используется лишь как вспомогательное средство для открывания двери.
На мой взгляд, именно игнорирование этого и было первопричиной трудностей, а вовсе не наследование реализации.
Разумеется, очень имхостое имхо.
Но пример, имхо, уж сильно неудачный. Должен ли Ключ уметь открывать пиво? Банку с консервами? Выдвижной ящик в столе? ;)