Интерфейсы — это просто классы без реализации. В Яве их вообще сделали в качестве костылика вместо множественного наследования. Ни какого другого смысла в них нет. Я не прав?
class MyInterface {
void method(arg) {
system_exit("Сперва реализуй, а потом пользуйся, балбес!")
}
}
Чем это не интерфейс?
Для нас [Thompson, Rob Pike, Robert Griesemer] это было просто исследование. Мы собрались вместе и решили, что ненавидим C++ [смех].
Здравствуйте, Sorc17, Вы писали:
S>Интерфейсы — это просто классы без реализации. В Яве их вообще сделали в качестве костылика вместо множественного наследования. Ни какого другого смысла в них нет. Я не прав?
S>
S>class MyInterface {
S> void method(arg) {
S> system_exit("Сперва реализуй, а потом пользуйся, балбес!")
S> }
S>}
S>
S>Чем это не интерфейс?
Нет, интерфейсы это *интерфейсы*, так же как классы это *классы*. Это вполне самостоятельное понятие. Определение смотрите в википедии.
Точно также в Си можно сказать что `void Foo_bar(struct Foo* self)` — это класс с одним методом, и что вообще это костыль и накакого особого смысла в этом нет.
Здравствуйте, Sorc17, Вы писали:
S>Интерфейсы — это просто классы без реализации. В Яве их вообще сделали в качестве костылика вместо множественного наследования. Ни какого другого смысла в них нет. Я не прав?
Интерфейс — это спецификация API класса. Это если философски.
А практически — сильно зависит от конкретного языка и платформы. Вот, например, если тебе нужно remote-вызов делать, в клиента надо скомпилировать интерфейс, но без реализации: реализация на сервере, а на клиенте автоматически гегерируемый по заданному интерфейсу прокси-код.
Здравствуйте, Abyx, Вы писали:
A>Нет, интерфейсы это *интерфейсы*, так же как классы это *классы*. Это вполне самостоятельное понятие. Определение смотрите в википедии.
A>Точно также в Си можно сказать что `void Foo_bar(struct Foo* self)` — это класс с одним методом, и что вообще это костыль и накакого особого смысла в этом нет.
Какой смысл вкладывают в это понятие мне понятно. Можно взять ящерицу, оторвать ей лапы и сказать, что это гусеница, но ящерицей от этого она быть не перестаёт, на мой взгляд. Если бы в Яве было разрешено множественное наследование, то можно было бы вместо интерфейса просто написать класс и каким-то другим механизмом обязать наследников перегружать все его функции, от этого вообще ничего бы не изменилось. Скажете не так?
Для нас [Thompson, Rob Pike, Robert Griesemer] это было просто исследование. Мы собрались вместе и решили, что ненавидим C++ [смех].
Здравствуйте, dimgel, Вы писали:
D>Интерфейс — это спецификация API класса. Это если философски.
Ну да, это понятно. Интерфейс как бы говорит нам, какими должны быть классы, его реализующие и ничего не говорит о том, что они должны делать, как именно себя вести. Но если мы заменим интерфейс классом и с помощью какого-то механизма языка заставим пользователя перегрузить все его методы, то какая нам разница, была у методов интерфейса какая-то, пусть даже вырожденная, реализация или её не было вовсе? Ведь мы её никогда не увидим и ничего про неё не узнаем, если только не залезем в код и не посмотрим как этот интерфейс на самом деле сделан.
Для нас [Thompson, Rob Pike, Robert Griesemer] это было просто исследование. Мы собрались вместе и решили, что ненавидим C++ [смех].
Здравствуйте, Sorc17, Вы писали:
S>Но если мы заменим интерфейс классом и с помощью какого-то механизма языка заставим пользователя перегрузить все его методы, то какая нам разница, была у методов интерфейса какая-то, пусть даже вырожденная, реализация или её не было вовсе? Ведь мы её никогда не увидим и ничего про неё не узнаем, если только не залезем в код и не посмотрим как этот интерфейс на самом деле сделан.
В приведённом мной примере с удалённмы вызовом у тебя этот фокус не пройдёт: реализация может тянуть зависимости, которые клиенту не нужны. Если у тебя, к примеру, трёхзвенка десктоп-сервер-база, то нахрена тебе на десктопе hibernate.jar какой-нибудь?
Здравствуйте, Sorc17, Вы писали:
S>Но если мы заменим интерфейс классом и с помощью какого-то механизма языка заставим пользователя перегрузить все его методы,
Здравствуйте, dimgel, Вы писали:
D>А ещё ты не сможешь перегрузить private и final.
Насчет remote вызова это не суть, конечно, потому что это детали конкретной реализации. В каком-нибудь другом языке могли бы сделать как-то по другому. А вот перегрузить private и final — это отличный аргумент, спасибо
Для нас [Thompson, Rob Pike, Robert Griesemer] это было просто исследование. Мы собрались вместе и решили, что ненавидим C++ [смех].
Здравствуйте, Sorc17, Вы писали:
S>Здравствуйте, Abyx, Вы писали:
A>>Нет, интерфейсы это *интерфейсы*, так же как классы это *классы*. Это вполне самостоятельное понятие. Определение смотрите в википедии.
A>>Точно также в Си можно сказать что `void Foo_bar(struct Foo* self)` — это класс с одним методом, и что вообще это костыль и накакого особого смысла в этом нет.
S>Какой смысл вкладывают в это понятие мне понятно. Можно взять ящерицу, оторвать ей лапы и сказать, что это гусеница, но ящерицей от этого она быть не перестаёт, на мой взгляд. Если бы в Яве было разрешено множественное наследование, то можно было бы вместо интерфейса просто написать класс и каким-то другим механизмом обязать наследников перегружать все его функции, от этого вообще ничего бы не изменилось. Скажете не так?
Здравствуйте, Sorc17, Вы писали:
S>Интерфейсы — это просто классы без реализации. В Яве их вообще сделали в качестве костылика вместо множественного наследования. Ни какого другого смысла в них нет. Я не прав?
S>
S>class MyInterface {
S> void method(arg) {
S> system_exit("Сперва реализуй, а потом пользуйся, балбес!")
S> }
S>}
S>
S>Чем это не интерфейс?
К учебникам.. И внимательно..
Здравствуйте, batu, Вы писали:
B>К учебникам.. И внимательно..
Можно взять и прочитать любую статью по запросу "interface vs abstract class", только они не объясняют сути. Там не пишут, ПОЧЕМУ нельзя что-то сделать, а пишут просто, что то или иное действие сделать нельзя. Почему нельзя наследовать приватные и финальные методы? Откуда вообще такое ограничение? Вот что надо объяснять, на мой взгляд.
Для нас [Thompson, Rob Pike, Robert Griesemer] это было просто исследование. Мы собрались вместе и решили, что ненавидим C++ [смех].
Здравствуйте, Sorc17, Вы писали:
S>Здравствуйте, batu, Вы писали:
B>>К учебникам.. И внимательно..
S>Можно взять и прочитать любую статью по запросу "interface vs abstract class", только они не объясняют сути. Там не пишут, ПОЧЕМУ нельзя что-то сделать, а пишут просто, что то или иное действие сделать нельзя. Почему нельзя наследовать приватные и финальные методы? Откуда вообще такое ограничение? Вот что надо объяснять, на мой взгляд.
Но, сначала надо прочитать что такое интерфейс.. Остальное следствие. Можно сделать по всякому, конечно..
Здравствуйте, dimgel, Вы писали:
D>Здравствуйте, Sorc17, Вы писали:
S>>Почему нельзя наследовать приватные и финальные методы?
D>По определению.
Это не объяснение Зачем-то же так сделали разработчики языков. Наверное они на какой-то науке основывали своё решение. Я вот могу придумать пример с публичным API к закрытой системе какой-нибудь. Допустим там есть какой-то класс с приватным методом списания денег со счета, если мы можем создать наследника этого класса и изменить реализацию списания денег со счета, то это атас! Кода я подобному примеру написать ниасилю сейчас. А тем более приплести в таком примере необходимость существования интерфейсов, которые бы как-то были здесь полезны. Короче говоря, хочется очевидного и понятного примера, которой бы неизбежно приводил нас к необходимости иметь "особые" классы, которые называются интерфейсами. Поспрашивал у знакомых в аське, никто ничего дельного не ответил ;(
Для нас [Thompson, Rob Pike, Robert Griesemer] это было просто исследование. Мы собрались вместе и решили, что ненавидим C++ [смех].
Здравствуйте, Sorc17, Вы писали:
S>Кода я подобному примеру написать ниасилю сейчас. А тем более приплести в таком примере необходимость существования интерфейсов, которые бы как-то были здесь полезны.
Я ж тебе дал юз-кейс. Распределёнка. Весь J2EE на этом построен. Более обще — снижение связности, на жаве благодаря интерфейсам реализуем IoC. А твоё "магическое замещение всех методов" не только неработоспособно, но и является удалением гланд через задницу автогентом.
Здравствуйте, Sorc17, Вы писали:
S>Интерфейсы — это просто классы без реализации. В Яве их вообще сделали в качестве костылика вместо множественного наследования. Ни какого другого смысла в них нет. Я не прав?
S>
S>class MyInterface {
S> void method(arg) {
S> system_exit("Сперва реализуй, а потом пользуйся, балбес!")
S> }
S>}
S>
S>Чем это не интерфейс?
Тем что есть реализация. Интерфейс в общем смысле, это нечто внешнее, видимое, метод спрятать детали повысив уровень абстрагирования.
Здравствуйте, Sorc17, Вы писали:
S>Это не объяснение Зачем-то же так сделали разработчики языков. Наверное они на какой-то науке основывали своё решение.
Ключевые слова для гугления: Information Hiding, Encapsulation.
Здравствуйте, dimgel, Вы писали:
D>Я ж тебе дал юз-кейс. Распределёнка. Весь J2EE на этом построен. Более обще — снижение связности, на жаве благодаря интерфейсам реализуем IoC. А твоё "магическое замещение всех методов" не только неработоспособно, но и является удалением гланд через задницу автогентом.
Интересненько. Правда я на практике с IoC не сталкивался. Хотя может и сталкивался, но не знал, что это так называется.
Вообще моя тема выросла из вопроса, как обосновать, что в коде нужно использовать ООП. То есть я могу написать код в процедурном стиле и в ооп стиле, язык это позволяет. Как же тогда понять, что пришло время делать классы, потому что без них дальше никак? Один человек мне сказал, что "когда появится необходимость наследования и полиморфизма". Но наследование можно сделать и с помощью модулей, как его кто-то назвал "модульное наследование". Насчет полиморфизма я спорить не стал. Другой человек сказал, что ооп нужно, "когда появляется необходимость наследования и интерфейсов". Я не понял что он имел ввиду, мы поспорили и вот я пришел выяснять, в чём же глубина идеи интерфейсов Ещё он сказал, что ооп нужно, когда "у тебя слишком много состояния накапливается, причем такого что его нужно таскать туда-сюда". Похоже они правы, но это какие-то слишком размытые критерии, сложно будет кому-то доказать, что пришло время переустановить шиндошс переписать всё на классы, потому что раньше-то писали программы на Си без всяких классов и ничего. Подобные вопросы похожи на болото, в них нет конкретики, меня это раздражает, казалось бы, в программировании сплошь и рядом точные науки, а тут такая лабуда получается.
Для нас [Thompson, Rob Pike, Robert Griesemer] это было просто исследование. Мы собрались вместе и решили, что ненавидим C++ [смех].