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

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

S>

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

S>Чем это не интерфейс?
К учебникам.. И внимательно..

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

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

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

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

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

S>

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

S>Чем это не интерфейс?
Это реализация концепта "интерфейс" при помощи класса

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

S>Ага. Я вот буквально пару минут назад у своих друзяшек в google+ спросил, а только ли для инкапсуляции придумали такие вещи как private, final, protected? Или есть ещё какие-то глубокие и не очевидные причины.
Только для инкапсуляции. Точнее, для возможности определять для одного и того же класса различные контракты по отношению к другому коду, в зависимости от того, что это за код. То есть protected позволяет классу выставлять наружу специальный контракт для наследников, не давая к нему доступа для посторонних. Набор этих "модификаторов доступа" зависит от структуры кода. В дотнете появляются сборки — и вместе с ними модификатор internal. В Delphi появляется отдельная сущность "визуальный дизайнер", и для него появляется модификатор published.

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

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

Интерфейс, в отличие от большинства языковых средств, представляет собой некое анти-средство, намеренно ограничивающее функциональность. Как private, const и т. п. Служит для избежания ошибок и побуждения программиста следовать определенному подходу.

Я бы еще, продолжая в том же духе, запретил наследоваться от классов, только от интерфейсов. interface I2 extends I1, class C implements I1, I42, и всё.

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

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

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

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

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

S>

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

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

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

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

S>Чем это не интерфейс?
Это интерфейсный класс.

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

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

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

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

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

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

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

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

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

В приведённом мной примере с удалённмы вызовом у тебя этот фокус не пройдёт: реализация может тянуть зависимости, которые клиенту не нужны. Если у тебя, к примеру, трёхзвенка десктоп-сервер-база, то нахрена тебе на десктопе hibernate.jar какой-нибудь?

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

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

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

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

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

Насчет remote вызова это не суть, конечно, потому что это детали конкретной реализации. В каком-нибудь другом языке могли бы сделать как-то по другому. А вот перегрузить private и final — это отличный аргумент, спасибо

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

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

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

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

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

а что вы всё про джаву? других языков чтоли нет?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это не объяснение Зачем-то же так сделали разработчики языков. Наверное они на какой-то науке основывали своё решение. Я вот могу придумать пример с публичным API к закрытой системе какой-нибудь. Допустим там есть какой-то класс с приватным методом списания денег со счета, если мы можем создать наследника этого класса и изменить реализацию списания денег со счета, то это атас! Кода я подобному примеру написать ниасилю сейчас. А тем более приплести в таком примере необходимость существования интерфейсов, которые бы как-то были здесь полезны. Короче говоря, хочется очевидного и понятного примера, которой бы неизбежно приводил нас к необходимости иметь "особые" классы, которые называются интерфейсами. Поспрашивал у знакомых в аське, никто ничего дельного не ответил ;(

Здравствуйте, 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 не сталкивался. Хотя может и сталкивался, но не знал, что это так называется.

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

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

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

S>>Это не объяснение Зачем-то же так сделали разработчики языков. Наверное они на какой-то науке основывали своё решение.
0>Ключевые слова для гугления: Information Hiding, Encapsulation.

Ага. Я вот буквально пару минут назад у своих друзяшек в google+ спросил, а только ли для инкапсуляции придумали такие вещи как private, final, protected? Или есть ещё какие-то глубокие и не очевидные причины.

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

S>Ага. Я вот буквально пару минут назад у своих друзяшек в google+ спросил, а только ли для инкапсуляции придумали такие вещи как private, final, protected? Или есть ещё какие-то глубокие и не очевидные причины.
А этих недостаточно?

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

S>Вообще моя тема выросла из вопроса, как обосновать, что в коде нужно использовать ООП.
Мне кажется, что вопрос неправильный. Не надо спрашивать "как обосновать необходимость использования Х?", надо спрашивать "что здесь надо использовать?"

S>...Подобные вопросы похожи на болото, в них нет конкретики, меня это раздражает, казалось бы, в программировании сплошь и рядом точные науки, а тут такая лабуда получается.
Именно так. ООП — это вообще чистое ремесленничество, у него нет строгой формальной базы или хотя бы единого определения, что есть ООП. В итоге ООП больше напоминает религию со всем сопутствующим словоблудием.

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

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

S>>Ага. Я вот буквально пару минут назад у своих друзяшек в google+ спросил, а только ли для инкапсуляции придумали такие вещи как private, final, protected? Или есть ещё какие-то глубокие и не очевидные причины.
0>А этих недостаточно?

Ну вдруг есть ещё что-то о чём я даже не подозреваю, интересно же

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

S>Ну вдруг есть ещё что-то о чём я даже не подозреваю, интересно же
Я не знаю

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

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

S>

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

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

abstract class MyInterface {
    public abstract void method(arg);
}

Вот это — "почти" интерфейс. И, скорее всего, костыль, изобретенный на пути к "настоящим" интерфейсам.

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

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

Интерфейсы это не просто классы без реализации, это именно интерфейсы. Они не имеют смысла без полиморфизма. ИМХО, одни из лучших применений интерфейсов — передача функциональности без передачи самого объекта, реализующего эту функциональность (некая ООП-замена передачи функций как аргументов в другие функции).

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

interface I_GuiCallback 
{
  void SetProgressRange(int n);
  void SetProgressPos(int i);
  void SetStatusText(string text);
}

Класс окна наследует этот интерфейс и реализует его методы, в которых осуществляется работа с конкретными прогресс барами и т.д.
А класс, который занимается обработкой, при инициализации получает этот интерфейс для того, чтобы управлять окном, ничего не зная про само окно. В случае С++ это весьма полезно, так как достигается кроссплатформенность класса обработки, и вообще появляется некая универсальность, уменьшается завязанность отдельных частей кода и т.д.

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

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

Формально прав. На практике же удобно когда есть способ описать интерфейс (в общем смысле этого слова) гарантированный не содержащий реализации. Так что в С++ я бы интерфейсы тоже ввел бы, не смотря на то, что физической необходимости в этом нет.

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

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

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

VD>Формально прав. На практике же удобно когда есть способ описать интерфейс (в общем смысле этого слова) гарантированный не содержащий реализации. Так что в С++ я бы интерфейсы тоже ввел бы, не смотря на то, что физической необходимости в этом нет.

Спасибо

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

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

S>

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

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

На тебе упрощалку:
Интерфейс это как-бы абстрактная сигнатура объекта(класса), по аналогии с сигнатурой функции.
Вот и всё. Очевидно, что абстрактный корневой класс тоже обеспечивает общую сигнатуру для всех потомков. И множественное наследование обеспечивает общую сигнатуру для объектов.

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

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

Здравствуйте, Sorc17, Вы писали:
S>Чем это не интерфейс?

Ничем. Ты розетку на стене, к которой комп подключен, видишь? Это реализация интерфейса. Знаешь нафига оно придумано? Чтобы ты засунул туда утюг? А вот фиг тебе, не угадал, для этого конкретная реализация розетки существует. Интерфейс описывают чтобы туда USB не прикрутил.