Интерфейсы, ООП
От: Sorc17 Россия  
Дата: 01.05.12 11:00
Оценка:
Интерфейсы — это просто классы без реализации. В Яве их вообще сделали в качестве костылика вместо множественного наследования. Ни какого другого смысла в них нет. Я не прав?

class MyInterface {
    void method(arg) {
        system_exit("Сперва реализуй, а потом пользуйся, балбес!")
    }
}

Чем это не интерфейс?
Для нас [Thompson, Rob Pike, Robert Griesemer] это было просто исследование. Мы собрались вместе и решили, что ненавидим C++ [смех].
Re: Интерфейсы, ООП
От: Abyx Россия  
Дата: 01.05.12 11:05
Оценка:
Здравствуйте, Sorc17, Вы писали:

S>Интерфейсы — это просто классы без реализации. В Яве их вообще сделали в качестве костылика вместо множественного наследования. Ни какого другого смысла в них нет. Я не прав?


S>
S>class MyInterface {
S>    void method(arg) {
S>        system_exit("Сперва реализуй, а потом пользуйся, балбес!")
S>    }
S>}
S>

S>Чем это не интерфейс?

Нет, интерфейсы это *интерфейсы*, так же как классы это *классы*. Это вполне самостоятельное понятие. Определение смотрите в википедии.

Точно также в Си можно сказать что `void Foo_bar(struct Foo* self)` — это класс с одним методом, и что вообще это костыль и накакого особого смысла в этом нет.
In Zen We Trust
Re: Интерфейсы, ООП
От: Osaka  
Дата: 01.05.12 11:06
Оценка:
S>Чем это не интерфейс?
Это интерфейсный класс.
Re: Интерфейсы, ООП
От: dimgel Россия https://github.com/dimgel
Дата: 01.05.12 11:12
Оценка:
Здравствуйте, Sorc17, Вы писали:

S>Интерфейсы — это просто классы без реализации. В Яве их вообще сделали в качестве костылика вместо множественного наследования. Ни какого другого смысла в них нет. Я не прав?


Интерфейс — это спецификация API класса. Это если философски.

А практически — сильно зависит от конкретного языка и платформы. Вот, например, если тебе нужно remote-вызов делать, в клиента надо скомпилировать интерфейс, но без реализации: реализация на сервере, а на клиенте автоматически гегерируемый по заданному интерфейсу прокси-код.
Re[2]: Интерфейсы, ООП
От: Sorc17 Россия  
Дата: 01.05.12 11:12
Оценка: -2
Здравствуйте, Abyx, Вы писали:

A>Нет, интерфейсы это *интерфейсы*, так же как классы это *классы*. Это вполне самостоятельное понятие. Определение смотрите в википедии.


A>Точно также в Си можно сказать что `void Foo_bar(struct Foo* self)` — это класс с одним методом, и что вообще это костыль и накакого особого смысла в этом нет.


Какой смысл вкладывают в это понятие мне понятно. Можно взять ящерицу, оторвать ей лапы и сказать, что это гусеница, но ящерицей от этого она быть не перестаёт, на мой взгляд. Если бы в Яве было разрешено множественное наследование, то можно было бы вместо интерфейса просто написать класс и каким-то другим механизмом обязать наследников перегружать все его функции, от этого вообще ничего бы не изменилось. Скажете не так?
Для нас [Thompson, Rob Pike, Robert Griesemer] это было просто исследование. Мы собрались вместе и решили, что ненавидим C++ [смех].
Re[2]: Интерфейсы, ООП
От: Sorc17 Россия  
Дата: 01.05.12 11:17
Оценка:
Здравствуйте, dimgel, Вы писали:

D>Интерфейс — это спецификация API класса. Это если философски.


Ну да, это понятно. Интерфейс как бы говорит нам, какими должны быть классы, его реализующие и ничего не говорит о том, что они должны делать, как именно себя вести. Но если мы заменим интерфейс классом и с помощью какого-то механизма языка заставим пользователя перегрузить все его методы, то какая нам разница, была у методов интерфейса какая-то, пусть даже вырожденная, реализация или её не было вовсе? Ведь мы её никогда не увидим и ничего про неё не узнаем, если только не залезем в код и не посмотрим как этот интерфейс на самом деле сделан.
Для нас [Thompson, Rob Pike, Robert Griesemer] это было просто исследование. Мы собрались вместе и решили, что ненавидим C++ [смех].
Re[3]: Интерфейсы, ООП
От: dimgel Россия https://github.com/dimgel
Дата: 01.05.12 11:23
Оценка:
Здравствуйте, Sorc17, Вы писали:

S>Но если мы заменим интерфейс классом и с помощью какого-то механизма языка заставим пользователя перегрузить все его методы, то какая нам разница, была у методов интерфейса какая-то, пусть даже вырожденная, реализация или её не было вовсе? Ведь мы её никогда не увидим и ничего про неё не узнаем, если только не залезем в код и не посмотрим как этот интерфейс на самом деле сделан.


В приведённом мной примере с удалённмы вызовом у тебя этот фокус не пройдёт: реализация может тянуть зависимости, которые клиенту не нужны. Если у тебя, к примеру, трёхзвенка десктоп-сервер-база, то нахрена тебе на десктопе hibernate.jar какой-нибудь?
Re[3]: Интерфейсы, ООП
От: dimgel Россия https://github.com/dimgel
Дата: 01.05.12 11:25
Оценка:
Здравствуйте, Sorc17, Вы писали:

S>Но если мы заменим интерфейс классом и с помощью какого-то механизма языка заставим пользователя перегрузить все его методы,


А ещё ты не сможешь перегрузить private и final.
Re[4]: Интерфейсы, ООП
От: Sorc17 Россия  
Дата: 01.05.12 11:30
Оценка:
Здравствуйте, dimgel, Вы писали:

D>А ещё ты не сможешь перегрузить private и final.


Насчет remote вызова это не суть, конечно, потому что это детали конкретной реализации. В каком-нибудь другом языке могли бы сделать как-то по другому. А вот перегрузить private и final — это отличный аргумент, спасибо
Для нас [Thompson, Rob Pike, Robert Griesemer] это было просто исследование. Мы собрались вместе и решили, что ненавидим C++ [смех].
Re[3]: Интерфейсы, ООП
От: Abyx Россия  
Дата: 01.05.12 11:46
Оценка:
Здравствуйте, Sorc17, Вы писали:

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


A>>Нет, интерфейсы это *интерфейсы*, так же как классы это *классы*. Это вполне самостоятельное понятие. Определение смотрите в википедии.


A>>Точно также в Си можно сказать что `void Foo_bar(struct Foo* self)` — это класс с одним методом, и что вообще это костыль и накакого особого смысла в этом нет.


S>Какой смысл вкладывают в это понятие мне понятно. Можно взять ящерицу, оторвать ей лапы и сказать, что это гусеница, но ящерицей от этого она быть не перестаёт, на мой взгляд. Если бы в Яве было разрешено множественное наследование, то можно было бы вместо интерфейса просто написать класс и каким-то другим механизмом обязать наследников перегружать все его функции, от этого вообще ничего бы не изменилось. Скажете не так?


а что вы всё про джаву? других языков чтоли нет?
In Zen We Trust
Re: Интерфейсы, ООП
От: batu Украина  
Дата: 01.05.12 11:58
Оценка: 1 (1) -1
Здравствуйте, Sorc17, Вы писали:

S>Интерфейсы — это просто классы без реализации. В Яве их вообще сделали в качестве костылика вместо множественного наследования. Ни какого другого смысла в них нет. Я не прав?


S>
S>class MyInterface {
S>    void method(arg) {
S>        system_exit("Сперва реализуй, а потом пользуйся, балбес!")
S>    }
S>}
S>

S>Чем это не интерфейс?
К учебникам.. И внимательно..
Re[2]: Интерфейсы, ООП
От: Sorc17 Россия  
Дата: 01.05.12 12:34
Оценка:
Здравствуйте, batu, Вы писали:

B>К учебникам.. И внимательно..


Можно взять и прочитать любую статью по запросу "interface vs abstract class", только они не объясняют сути. Там не пишут, ПОЧЕМУ нельзя что-то сделать, а пишут просто, что то или иное действие сделать нельзя. Почему нельзя наследовать приватные и финальные методы? Откуда вообще такое ограничение? Вот что надо объяснять, на мой взгляд.
Для нас [Thompson, Rob Pike, Robert Griesemer] это было просто исследование. Мы собрались вместе и решили, что ненавидим C++ [смех].
Re: Интерфейсы, ООП
От: 0x7be СССР  
Дата: 01.05.12 12:39
Оценка: +1
Здравствуйте, Sorc17, Вы писали:

S>
S>class MyInterface {
S>    void method(arg) {
S>        system_exit("Сперва реализуй, а потом пользуйся, балбес!")
S>    }
S>}
S>

S>Чем это не интерфейс?
Это реализация концепта "интерфейс" при помощи класса
Re[3]: Интерфейсы, ООП
От: batu Украина  
Дата: 01.05.12 12:54
Оценка:
Здравствуйте, Sorc17, Вы писали:

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


B>>К учебникам.. И внимательно..


S>Можно взять и прочитать любую статью по запросу "interface vs abstract class", только они не объясняют сути. Там не пишут, ПОЧЕМУ нельзя что-то сделать, а пишут просто, что то или иное действие сделать нельзя. Почему нельзя наследовать приватные и финальные методы? Откуда вообще такое ограничение? Вот что надо объяснять, на мой взгляд.

Но, сначала надо прочитать что такое интерфейс.. Остальное следствие. Можно сделать по всякому, конечно..
Re[3]: Интерфейсы, ООП
От: dimgel Россия https://github.com/dimgel
Дата: 01.05.12 12:57
Оценка:
Здравствуйте, Sorc17, Вы писали:

S>Почему нельзя наследовать приватные и финальные методы?


По определению.
Re[4]: Интерфейсы, ООП
От: Sorc17 Россия  
Дата: 01.05.12 13:13
Оценка:
Здравствуйте, dimgel, Вы писали:

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


S>>Почему нельзя наследовать приватные и финальные методы?


D>По определению.


Это не объяснение Зачем-то же так сделали разработчики языков. Наверное они на какой-то науке основывали своё решение. Я вот могу придумать пример с публичным API к закрытой системе какой-нибудь. Допустим там есть какой-то класс с приватным методом списания денег со счета, если мы можем создать наследника этого класса и изменить реализацию списания денег со счета, то это атас! Кода я подобному примеру написать ниасилю сейчас. А тем более приплести в таком примере необходимость существования интерфейсов, которые бы как-то были здесь полезны. Короче говоря, хочется очевидного и понятного примера, которой бы неизбежно приводил нас к необходимости иметь "особые" классы, которые называются интерфейсами. Поспрашивал у знакомых в аське, никто ничего дельного не ответил ;(
Для нас [Thompson, Rob Pike, Robert Griesemer] это было просто исследование. Мы собрались вместе и решили, что ненавидим C++ [смех].
Re[5]: Интерфейсы, ООП
От: dimgel Россия https://github.com/dimgel
Дата: 01.05.12 13:21
Оценка:
Здравствуйте, Sorc17, Вы писали:

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


Я ж тебе дал юз-кейс. Распределёнка. Весь J2EE на этом построен. Более обще — снижение связности, на жаве благодаря интерфейсам реализуем IoC. А твоё "магическое замещение всех методов" не только неработоспособно, но и является удалением гланд через задницу автогентом.
Re: Интерфейсы, ООП
От: licedey  
Дата: 01.05.12 13:26
Оценка:
Здравствуйте, Sorc17, Вы писали:

S>Интерфейсы — это просто классы без реализации. В Яве их вообще сделали в качестве костылика вместо множественного наследования. Ни какого другого смысла в них нет. Я не прав?


S>
S>class MyInterface {
S>    void method(arg) {
S>        system_exit("Сперва реализуй, а потом пользуйся, балбес!")
S>    }
S>}
S>

S>Чем это не интерфейс?

Тем что есть реализация. Интерфейс в общем смысле, это нечто внешнее, видимое, метод спрятать детали повысив уровень абстрагирования.
Re[5]: Интерфейсы, ООП
От: 0x7be СССР  
Дата: 01.05.12 13:26
Оценка:
Здравствуйте, Sorc17, Вы писали:

S>Это не объяснение Зачем-то же так сделали разработчики языков. Наверное они на какой-то науке основывали своё решение.

Ключевые слова для гугления: Information Hiding, Encapsulation.
Re[6]: Интерфейсы, ООП
От: Sorc17 Россия  
Дата: 01.05.12 13:40
Оценка:
Здравствуйте, dimgel, Вы писали:

D>Я ж тебе дал юз-кейс. Распределёнка. Весь J2EE на этом построен. Более обще — снижение связности, на жаве благодаря интерфейсам реализуем IoC. А твоё "магическое замещение всех методов" не только неработоспособно, но и является удалением гланд через задницу автогентом.


Интересненько. Правда я на практике с IoC не сталкивался. Хотя может и сталкивался, но не знал, что это так называется.

Вообще моя тема выросла из вопроса, как обосновать, что в коде нужно использовать ООП. То есть я могу написать код в процедурном стиле и в ооп стиле, язык это позволяет. Как же тогда понять, что пришло время делать классы, потому что без них дальше никак? Один человек мне сказал, что "когда появится необходимость наследования и полиморфизма". Но наследование можно сделать и с помощью модулей, как его кто-то назвал "модульное наследование". Насчет полиморфизма я спорить не стал. Другой человек сказал, что ооп нужно, "когда появляется необходимость наследования и интерфейсов". Я не понял что он имел ввиду, мы поспорили и вот я пришел выяснять, в чём же глубина идеи интерфейсов Ещё он сказал, что ооп нужно, когда "у тебя слишком много состояния накапливается, причем такого что его нужно таскать туда-сюда". Похоже они правы, но это какие-то слишком размытые критерии, сложно будет кому-то доказать, что пришло время переустановить шиндошс переписать всё на классы, потому что раньше-то писали программы на Си без всяких классов и ничего. Подобные вопросы похожи на болото, в них нет конкретики, меня это раздражает, казалось бы, в программировании сплошь и рядом точные науки, а тут такая лабуда получается.
Для нас [Thompson, Rob Pike, Robert Griesemer] это было просто исследование. Мы собрались вместе и решили, что ненавидим C++ [смех].
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.