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

G>Но далеко не любая программа является моделью части реального мира.

При чем тут "реального"? Ключевое слово — модель. Например, можно брать математические модели.


G>Даже наоборот, программ где такой подход оправдан исчезающе мало.

Попробуй привести пример, который тут не раскатают по асфальту.


G>Отношение is-a отлично достигается без наследования реализации. Интерфейсы (выше ты привел именно наследование интерфейсов), typeclasses в хаскеле, ducktyping в динамических языках. Это все позволяет выстраивать отношения is-a.

Я бы не стал ducktyping приравнивать к is-a. Ибо сие отношение как раз служит для для типизированных языков как инструмент проверки контрактов в compile-time. Для ООП-скриптовых языков ducktyping работает на уровне отдельного метода, и лишь предоставляет способ реализации обмена сигналами для целей собственно работы ООП в этой динамике.

Насчет твоей фразы наследования интерфейсов — не уверен, что ты сам понял, что сказал. В ООП интерфейсом называют публичное АПИ классов, оно и наследуется автоматически. Если же ты про термин "Interface" из COM, особенность которого была повторена в Delphi/Java/C#, то его следует называть "абстрактным интерфейсом". Слово абстрактный — ключевое, т.е. мы заведомо опускаем подробности реализации, используя этот интерфейс исключительно как описание контракта для системы статической типизации компилятора. Заметь, с т.з. клиентов таких интерфейсов, им глубоко до фени, абстрактный он или нет, это подробности уже самого интерфейса.

Абстрактные интерфейсы предназначены для случая надобности сокрытия полного АПИ реализующих классов, ведь термин "абстракция" означает выделение сути/основы. То, что в некоторых языках абстрактные интерфейсы используются порой для побочных целей, например для порождения нескольких параллельных иерархий is-a — лишь следствие отсутствия в этих языках множественного наследования. То бишь, инструмент абстрагирования применяется даже там, где размер задачи абстрагирования не требует.

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

SV.>>Грамотная декомпозиция на значимые сущности должна быть переложена на ЯП без изменений, с сохранением всех отношений, в т.ч. наследования реализаций.

G>Выделенное необоснованно.

Оно ничему не противоречит. Даже имея описанный вариант системы, иерархия которой расписана на абстрактных интерфейсах, ничто не мешает использовать наследование реализаций для конкретных используемых типов. Вы в пылу спора всё время забываете, что вся эта абстрактность — вторична. Это лишь наше внутренее дело, как мы боремся со сложностью и какой инструмент для этого взяли. Напротив, функциональность — первична. Даже такая вещь, как агрегирование и делегирование в реализации концепции миксинов (ручной реализации чаще всего) — лишь инструмент, обыгрывающий некоторые ограничения некоторых ООП-языков/платформ.


G>Ты в принципе попал в ту же проблему, куда попадают все "философы ооп". Они поголовно считают что все достижения ООП недоступны в других парадигмах, а на деле даже наоборот.

Расшифруй, плиз, о каких достижениях речь, и куда именно попал твой оппонент? Сдается мне, тут уже наблюдается тихий спор с самим собой.

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

DG>>>>но значит у тебя модель другого мира. модель проекта, например.
G>>>
G>>>Ты всегда сводишь к абсурду. У тебя получается что объект — модель какого-то "мира".

DG>>объект — это слово(понятие) модели обычно.
G>А мы вообще-то говорим про объекты и классы в ОО-языках.

Ну так в ООП объект и представляет из себя элемент модели. Класс — это уже термин из области типов, к понятию "объект" в общем случае ортогональный.

G>Композиция.

Наследование реализации в ООП — это и есть агрегирование, что есть частный случай композиции. И множественное наследование в т.ч. Подозреваю, что ты хотел упомянуть какие-нить паттерны, типа делегирования и т.д., но это уже шелуха и подробности. Ты все-равно повторно используешь именно функциональность, только предоставляешь ее не из АПИ, а через самописные переходники, эдакое ручное описание thunk, вместо компилятора. Сия техника нужна там, где нет множественного наследования или параметр генерика не может быть базой. В других языках, имея полностью абстрактные параллельные иерархии, легко использовать "автоматическую" композицию через множественное наследование, вместо получения того же эффекта вручную.

В общем, ты опять попутал причину и следствие. Миксины не самоцель, а инструмент, пригодный для обхода ограничений языка.

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

DG>>проблема начинается, когда люди начинают считать, что наследуя реализацию — они при этом автоматически получают наследование внешнего контракта, а также что получили отношение is-a.

Z>В общем да. Но вообще есть LSP который запрещает использовать наследование без отношения is-a.

Был приведен пример независимых иерархий, по каждой из которых существует свое is-a. Похожая задача была про квадрат, ромб и прямоугольник, кого от кого наследовать. Никого ни от кого. Имеем несколько паралельных иерархий, и сия ситуация решается множественным наследованием для реализации конечных типов. Ну или миксинами для C# и иже с ними.

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

G>Наследование реализации наследования интерфейсов и отношения is-a в некоторых языках есть и называется mixin. Тоже концепция, уводящая в сторону от ООП.

Глупость. Миксин — это вынужденно используемый инструмент для удобства программирования в ограниченной разновидности ООП — компонентном программировании. Где же тут "в сторону"? Это на маленьком островке внутри ООП.

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

DG>ракета наследуется от самолета, а свиньи от военных юнитов
DG>и это всех устраивает — если сделано аккуратно

Приведены баги вызванные подобным наследованием и остроумные костыли для их обхода. Какая логика привела тебя к выводу "всех устраивает, если сделано аккуратно"?

То, что софт почти с любыми архитектурными проблемами можно заставить заработать, я думаю, ни для кого из здесь присутствующих не новость, это не значит, что проблемы всех устраивают.

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

DG>>>проблема начинается, когда люди начинают считать, что наследуя реализацию — они при этом автоматически получают наследование внешнего контракта, а также что получили отношение is-a.

Z>>В общем да. Но вообще есть LSP который запрещает использовать наследование без отношения is-a.

V>Был приведен пример независимых иерархий, по каждой из которых существует свое is-a. Похожая задача была про квадрат, ромб и прямоугольник, кого от кого наследовать. Никого ни от кого. Имеем несколько паралельных иерархий, и сия ситуация решается множественным наследованием для реализации конечных типов. Ну или миксинами для C# и иже с ними.

Я не пойму, что ты хочешь сказать. Я возразил на выделенное, проблема начинается когда дизайн иерархии перестает удовлетворять LSP. Который как раз для этого случая и придуман, там прямым текстом написано: не хотите проблем — не делайте так.

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

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

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

G>>Но далеко не любая программа является моделью части реального мира.

V>При чем тут "реального"? Ключевое слово — модель. Например, можно брать математические модели.
Математическая модель — набор формул. Этот набор формул никак не связан с классами и объектами.
Связь модели с классами только в голове разработчика.


G>>Даже наоборот, программ где такой подход оправдан исчезающе мало.
V>Попробуй привести пример, который тут не раскатают по асфальту.
Пример чего?


G>>Отношение is-a отлично достигается без наследования реализации. Интерфейсы (выше ты привел именно наследование интерфейсов), typeclasses в хаскеле, ducktyping в динамических языках. Это все позволяет выстраивать отношения is-a.

V>Я бы не стал ducktyping приравнивать к is-a. Ибо сие отношение как раз служит для для типизированных языков как инструмент проверки контрактов в compile-time. Для ООП-скриптовых языков ducktyping работает на уровне отдельного метода, и лишь предоставляет способ реализации обмена сигналами для целей собственно работы ООП в этой динамике.
Какая-то слишком заумная фраза, смысл её мне остался непонятен.

V>Насчет твоей фразы наследования интерфейсов — не уверен, что ты сам понял, что сказал. В ООП интерфейсом называют публичное АПИ классов, оно и наследуется автоматически. Если же ты про термин "Interface" из COM, особенность которого была повторена в Delphi/Java/C#, то его следует называть "абстрактным интерфейсом".
Кем принято? Ссылку на первоисточник.
Тут все понимают интефейс, как явно указанный набор методов\свойств, которые реализует объект.

V>Заметь, с т.з. клиентов таких интерфейсов, им глубоко до фени, абстрактный он или нет, это подробности уже самого интерфейса.
Замечу что это неверно, особенно когда дело касается наследования.

V>Абстрактные интерфейсы предназначены для случая надобности сокрытия полного АПИ реализующих классов, ведь термин "абстракция" означает выделение сути/основы. То, что в некоторых языках абстрактные интерфейсы используются порой для побочных целей, например для порождения нескольких параллельных иерархий is-a — лишь следствие отсутствия в этих языках множественного наследования. То бишь, инструмент абстрагирования применяется даже там, где размер задачи абстрагирования не требует.
Ну это твои домыслы, которые не соответствуют практике.

V>Рациональное зерно в наследовании абстрактных интерфейсов для построения объектной иерархии разумеется есть. И чем больше иерархия, тем больше в этом смысла. Мы избавляем такую иерархию от подробностей реализации составляющих её элементов, т.е. банально уменьшаем информационную сложность иерархии. Причем, учитывая связи м/у объектами (например, из-за использования общих или базовых реализаций), мы можем нарваться на рост числа зависимостей, близкий к квадратичному от кол-ва элементов иерархии. И вот смотрим на современные программы, где многие десятки сущностей, если не сотни... Понятное дело, что есть здравое желания снизить сложность архитектуры системы на порядок и даже чуть больше.
Смотрю я .NET FW ине могу найти интерфейсов, более 3 уровней наследования.
Видимо создатели библиотек в 200000 классов (кажись такое число) не разделяют твоего мнения.


SV.>>>Грамотная декомпозиция на значимые сущности должна быть переложена на ЯП без изменений, с сохранением всех отношений, в т.ч. наследования реализаций.

G>>Выделенное необоснованно.

V>Оно ничему не противоречит. Даже имея описанный вариант системы, иерархия которой расписана на абстрактных интерфейсах, ничто не мешает использовать наследование реализаций для конкретных используемых типов.
Если прочитаешь внимательно, то тут многие говорят что наследование реализации без наследования интерфейсов вполне можно безопасно (то есть не не создавая проблем) использовать.
Основная проблема в том что в большинстве языков наследование реализации автоматически наследует интерфейс.

V>Вы в пылу спора всё время забываете, что вся эта абстрактность — вторична.
Абстрактность ты придумал. Я использую интерфейс для отделения вещей друг от друга.


G>>Ты в принципе попал в ту же проблему, куда попадают все "философы ооп". Они поголовно считают что все достижения ООП недоступны в других парадигмах, а на деле даже наоборот.
V>Расшифруй, плиз, о каких достижениях речь, и куда именно попал твой оппонент? Сдается мне, тут уже наблюдается тихий спор с самим собой.

Чаще всего укушенные ООП любят говорить что только ООП позволяет полиморфизм и отношение is-a.

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

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

G>>Наследование реализации наследования интерфейсов и отношения is-a в некоторых языках есть и называется mixin. Тоже концепция, уводящая в сторону от ООП.

V>Глупость. Миксин — это вынужденно используемый инструмент для удобства программирования в ограниченной разновидности ООП — компонентном программировании. Где же тут "в сторону"? Это на маленьком островке внутри ООП.

ООП: инкапсуляция, полиморфизм, наследование реализации с интерфейсом. mixin_ы в эту формулу не вписываются, они расширяют ООП.

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

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

DG>>>>>но значит у тебя модель другого мира. модель проекта, например.
G>>>>
G>>>>Ты всегда сводишь к абсурду. У тебя получается что объект — модель какого-то "мира".

DG>>>объект — это слово(понятие) модели обычно.
G>>А мы вообще-то говорим про объекты и классы в ОО-языках.

V>Ну так в ООП объект и представляет из себя элемент модели. Класс — это уже термин из области типов, к понятию "объект" в общем случае ортогональный.
Ага, только в типизированных языках каждый объект имеет некоторый класс. Так что не ортогональный.

G>>Композиция.

V>Наследование реализации в ООП — это и есть агрегирование, что есть частный случай композиции.
Это ты что-тоне то выдумал. Наследование и агрегирование — разные вещи.

V>В общем, ты опять попутал причину и следствие. Миксины не самоцель, а инструмент, пригодный для обхода ограничений языка.
Для обхода ограничений ООП. Ну об этом я и говорю.

Z>Приведены баги вызванные подобным наследованием и остроумные костыли для их обхода. Какая логика привела тебя к выводу "всех устраивает, если сделано аккуратно"?

всех устраивает, если исходить из совокупности параметров "качество/цена"

могли разработчики написать ракету с нуля, а не наследовать реализацию от самолета? могли
код был бы чище? скорее всего -да
почему не сделали? да, потому что — это выливается в большие временные затраты: необходимо заново выписывать требования, заново проектировать, заново кодировать, заново тестировать. наследование реализации позволило существенно сэкономить на всех 4-х этапах.

Z>То, что софт почти с любыми архитектурными проблемами можно заставить заработать, я думаю, ни для кого из здесь присутствующих не новость, это не значит, что проблемы всех устраивают.

это ты говоришь лишь про максимизацию параметра "качество" без учета "цены".
да, если нам нужно именно сверхкачество, то приходится отказываться от наследования реализации, и если мы берем те же самолеты, то там пишется три копии ПО без всякого наследования реализации для такого чтобы избежать наведенных проблем от наследования реализации.
но если берется менее критичная область, то наследование реализации вовсю используется, т.к. позволяет сильно улучшить параметр "цена".

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

Z>>Приведены баги вызванные подобным наследованием и остроумные костыли для их обхода. Какая логика привела тебя к выводу "всех устраивает, если сделано аккуратно"?

DG>всех устраивает, если исходить из совокупности параметров "качество/цена"

DG>могли разработчики написать ракету с нуля, а не наследовать реализацию от самолета? могли
DG>код был бы чище? скорее всего -да
DG>почему не сделали? да, потому что — это выливается в большие временные затраты: необходимо заново выписывать требования, заново проектировать, заново кодировать, заново тестировать. наследование реализации позволило существенно сэкономить на всех 4-х этапах.

То есть ты хочешь сказать что ООП — хорошее средство писания говнокода?
Или просто пытаешься оправдать одну ошибку дизайна другой?

Z>>То, что софт почти с любыми архитектурными проблемами можно заставить заработать, я думаю, ни для кого из здесь присутствующих не новость, это не значит, что проблемы всех устраивают.

DG>это ты говоришь лишь про максимизацию параметра "качество" без учета "цены".
DG>да, если нам нужно именно сверхкачество, то приходится отказываться от наследования реализации, и если мы берем те же самолеты, то там пишется три копии ПО без всякого наследования реализации для такого чтобы избежать наведенных проблем от наследования реализации.
DG>но если берется менее критичная область, то наследование реализации вовсю используется, т.к. позволяет сильно улучшить параметр "цена".

Наследование почти всегда безболезненно можно заменить агрегацией + рефакторинг Extract Interface.

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


V>>Был приведен пример независимых иерархий, по каждой из которых существует свое is-a. Похожая задача была про квадрат, ромб и прямоугольник, кого от кого наследовать. Никого ни от кого. Имеем несколько паралельных иерархий, и сия ситуация решается множественным наследованием для реализации конечных типов. Ну или миксинами для C# и иже с ними.

Z>Я не пойму, что ты хочешь сказать. Я возразил на выделенное, проблема начинается когда дизайн иерархии перестает удовлетворять LSP. Который как раз для этого случая и придуман, там прямым текстом написано: не хотите проблем — не делайте так.

Давай-ка подробнее. Я предположил, что вместо одой ветки наследования можно использовать несколько. Противоречие принципу Лисков будет лишь тогда, когда нам, при работе с одним из корней сей иерархии (одним интерфейсом для C#), потребуется узнать наличие еще одной базы (реализации еще одного интерфейса) или даже конкретный используемый тип. Действительно, не делайте так. Если у нас есть коллекция интерфейсов, то при обходе сей коллекции обходитесь, пожалуйста, только этим статически типизированным интерфейсом. Вот и всё.

Т.е. обрати плиз внимание, что нарушение принципа имени Барбары может наблюдаться не в момент проектрования иерархии, а в момент её использования. Да, хоть мы "нутром" понимаем, что использование зависит от вида иерархии, это далеко не всегда так. Часто это может быть от неправильного использования.

Поэтому сто раз прав г-н Степанов в том, что сначала надо разрабатывать функциональность/алгоритмы, а потом под них разработать непротиворечивую систему хранения состояния (данные). В обсуждаемом случае — чтобы использование иерархии классов, в имеющихся как данность алгоритмах, не провоцировало на нарушение LSP.

Z>Я не вижу никакой необходимости множественного наследования или миксинов в данной ситуации.

Ну хорошо, пусть без миксинов, пусть каждый метод абстрактной базы будет реализован в конечном типе с 0-ля. По-сути то это ничего не меняет.

Z>И вообще не понимаю, что такое миксины для C#.

Речь идет об эмуляции миксинов вручную через ручное делегирование. Угу, для целей реализации продвигаемой новой фишки под названием "повторное использование кода через композицию". Фишка просто замечательная для .Net/Java, за неимением на этой платформе других способов композиции объектов. Осталось лишь поддержать фишку в языках, чтобы не делать механическую работу вручную.


Z>Если требуется какой-то полимофризм их следует наследовать от фигуры.

Еще раз, в конкретно рассматриваемом примере может быть несколько веток иерархии. И да, вполне может быть один корень, пусть "фигура", и список объектов из этого корня даже можно будет подать на часть алгоритмов. Но нельзя этот же интерфейс использовать для прорисовки, например, сегмента овала/круга, т.е. в тот алгоритм надо подать другой интерфейс, чтобы внутри него не было необходимости обходить LSP. (сорри, уже просто на пальцах)

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

SV.>>Коль скоро это так, вас, конечно же, не затруднит привести пример программы, которая не является моделью?
G>Вот сейчас занимаюсь веб-приложением для автоматизации проектного управления. У меня там нет ни одного объекта, который является моделью объекта реального мира.

Не совсем ясно, что ты понимаешь под объектами реального мира. "собака", "кошка" ?

А куда деть явления, отношения ? Ну, например, "проект"

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

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

SV.>>>Коль скоро это так, вас, конечно же, не затруднит привести пример программы, которая не является моделью?
G>>Вот сейчас занимаюсь веб-приложением для автоматизации проектного управления. У меня там нет ни одного объекта, который является моделью объекта реального мира.

I>Не совсем ясно, что ты понимаешь под объектами реального мира. "собака", "кошка" ?

I>А куда деть явления, отношения ? Ну, например, "проект"

Да пожалуйста. В постановке задачи у меня есть "проект" и в интерфейсе много где есть "проект", а вот класса "проект" нету.

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

V>Давай-ка подробнее. Я предположил, что вместо одой ветки наследования можно использовать несколько. Противоречие принципу Лисков будет лишь тогда, когда нам, при работе с одним из корней сей иерархии (одним интерфейсом для C#), потребуется узнать наличие еще одной базы (реализации еще одного интерфейса) или даже конкретный используемый тип. Действительно, не делайте так. Если у нас есть коллекция интерфейсов, то при обходе сей коллекции обходитесь, пожалуйста, только этим статически типизированным интерфейсом. Вот и всё.

LSP — про единичное наследование

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

V>>Глупость. Миксин — это вынужденно используемый инструмент для удобства программирования в ограниченной разновидности ООП — компонентном программировании. Где же тут "в сторону"? Это на маленьком островке внутри ООП.

G>ООП: инкапсуляция, полиморфизм, наследование реализации с интерфейсом. mixin_ы в эту формулу не вписываются, они расширяют ООП.

Смешались в кучу люди, кони.

У меня после прочтения тебя в этой ветке сложилось впечатление, что ты на всё смотришь под своеобразным углом зрения, путая причину и следствие, цель и инструмент. Давай уже начинай раскладывать по полкам.

В классике, наследование реализации — не есть непременный атрибут ООП. Наследование — это лишь один из способов повторного использования кода в статически-типизируемых ОО-языках. Миксины можно рассматривать как альтернативу того же самого. Оба этих способа повышают эффективности разработки, предоставляя инструмент полуавтоматического повторного использования кода (когда подробностями повторного использования кода при сохранении типобезопасности занимается компилятор, а не мы ручкам, например в С++ компилятор генерирует thunk/переходник для вызова базового метода в случае множественного наследования).

Т.е. эти инструменты ни расширяют, ни еще как-то модифицируют ОО-парадигму, а являются лишь удобными и признанными практиками в её рамках, поддержанными на уровне языков.

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

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

V>>Давай-ка подробнее. Я предположил, что вместо одой ветки наследования можно использовать несколько. Противоречие принципу Лисков будет лишь тогда, когда нам, при работе с одним из корней сей иерархии (одним интерфейсом для C#), потребуется узнать наличие еще одной базы (реализации еще одного интерфейса) или даже конкретный используемый тип. Действительно, не делайте так. Если у нас есть коллекция интерфейсов, то при обходе сей коллекции обходитесь, пожалуйста, только этим статически типизированным интерфейсом. Вот и всё.

A>LSP — про единичное наследование

С чего ты взял?

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


V>>Ну так в ООП объект и представляет из себя элемент модели. Класс — это уже термин из области типов, к понятию "объект" в общем случае ортогональный.
G>Ага, только в типизированных языках каждый объект имеет некоторый класс. Так что не ортогональный.

Каша.

Какая именно типизация имеется ввиду, статическая или динамическая? И при чем тут эта частность с типизацией, если полно не ОО-языков с обоими видами типизации и без типизации вообще, точно так же как полно ОО-языков опять же с обоим видами типизации и без типизации вообще. Классы могут быть поддержаны системой типов, а могут быть и нет. Класс — это "шаблон" объекта и одновременно type identity для целей типизации. Но если типизации нет, то и классы зачастую не нужны. И тогда мы наблюдаем "шаблоны" объектов в чистом виде, как в JavaScript. Фактически там нет классов, там есть "образцы" объектов.


G>Наследование и агрегирование — разные вещи.

Двойка тебе, коллега. Иди учи уроки.


V>>В общем, ты опять попутал причину и следствие. Миксины не самоцель, а инструмент, пригодный для обхода ограничений языка.
G>Для обхода ограничений ООП. Ну об этом я и говорю.

Ничего-то ты не понимаешь.

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

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

V>>>Глупость. Миксин — это вынужденно используемый инструмент для удобства программирования в ограниченной разновидности ООП — компонентном программировании. Где же тут "в сторону"? Это на маленьком островке внутри ООП.

G>>ООП: инкапсуляция, полиморфизм, наследование реализации с интерфейсом. mixin_ы в эту формулу не вписываются, они расширяют ООП.

V>Смешались в кучу люди, кони.

V>У меня после прочтения тебя в этой ветке сложилось впечатление, что ты на всё смотришь под своеобразным углом зрения, путая причину и следствие, цель и инструмент. Давай уже начинай раскладывать по полкам.

V>В классике, наследование реализации — не есть непременный атрибут ООП.

А что тогда непременный атрибут ООП?
Я пользуюсь общепринятым определением ООП: инкапсуляция, наследование реализации (повторное использование), полиморфизм. Причем каждый из этих компонент есть и в других парадигмах (и даже лучше делается).


V>Наследование — это лишь один из способов повторного использования кода в статически-типизируемых ОО-языках. Миксины можно рассматривать как альтернативу того же самого.

Ну и насколько "альтернатива наследования" относится к ООП?

V>Т.е. эти инструменты ни расширяют, ни еще как-то модифицируют ОО-парадигму, а являются лишь удобными и признанными практиками в её рамках, поддержанными на уровне языков.
Ок, ссылку на авторитетный источник приведи.
Кстати почему в mainstream языках (которые имеют бирку ООП) нету mixin-ов?
Наверное потому что это очень признанные практики в ООП.

Твои слова не соответствуют реальности в основном.

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

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


V>>>Ну так в ООП объект и представляет из себя элемент модели. Класс — это уже термин из области типов, к понятию "объект" в общем случае ортогональный.
G>>Ага, только в типизированных языках каждый объект имеет некоторый класс. Так что не ортогональный.

V>Каша.
Где именно?

V>Какая именно типизация имеется ввиду, статическая или динамическая?
Естественно статическая.

V>И при чем тут эта частность с типизацией, если полно не ОО-языков с обоими видами типизации и без типизации вообще, точно так же как полно ОО-языков опять же с обоим видами типизации и без типизации вообще. Классы могут быть поддержаны системой типов, а могут быть и нет. Класс — это "шаблон" объекта и одновременно type identity для целей типизации. Но если типизации нет, то и классы зачастую не нужны. И тогда мы наблюдаем "шаблоны" объектов в чистом виде, как в JavaScript. Фактически там нет классов, там есть "образцы" объектов.
Это кстати доказывает неортогональность "классов" (как бы они не выражались) и объектов.

Так что каша покачто у тебя.



G>>Наследование и агрегирование — разные вещи.

V>Двойка тебе, коллега. Иди учи уроки.
Датыче?
А ты как-нить можешь подтвердить свое мнение?
Даже гугл с тобой не согласен.


V>>>В общем, ты опять попутал причину и следствие. Миксины не самоцель, а инструмент, пригодный для обхода ограничений языка.
G>>Для обхода ограничений ООП. Ну об этом я и говорю.
V>Ничего-то ты не понимаешь.

Слив зощитан.