Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, artelk, Вы писали:
A>>Здравствуйте, vdimas, Вы писали:
V>>>Давай-ка подробнее. Я предположил, что вместо одой ветки наследования можно использовать несколько. Противоречие принципу Лисков будет лишь тогда, когда нам, при работе с одним из корней сей иерархии (одним интерфейсом для C#), потребуется узнать наличие еще одной базы (реализации еще одного интерфейса) или даже конкретный используемый тип. Действительно, не делайте так. Если у нас есть коллекция интерфейсов, то при обходе сей коллекции обходитесь, пожалуйста, только этим статически типизированным интерфейсом. Вот и всё.
A>>LSP — про единичное наследование
G>С чего ты взял?
Принцип LSP описывает отношение между классом-наследником и одним базовым классом. Принцип сводится к тому, что класс-наследник должен не только наследовать реализацию, а также поддерживать явный и неявный интерфейс базового класса, чтобы все функции, принимающие по ссылке объекты базового класса, могли с тем же успехом принимать объекты класса-наследника.
P.S. Я не утверждаю, что принцип LSP имеет смысл только когда у класса только один базовый класс. Может выразился неудачно... При множественном наследовании нужно смотреть каждый конкретный базовый класс отдельно и выяснять удеовлетворяет ли наследование от него принципу LSP. Просто товарищ, на сколько я понял, утверждал что LSP — это про множественное наследование и про явное приведение типов от ссылки на одну базу к другой.
Re[7]: Почему объектно-ориентированное программирование пров
Здравствуйте, gandjustas, Вы писали:
V>>При чем тут "реального"? Ключевое слово — модель. Например, можно брать математические модели. G>Математическая модель — набор формул. Этот набор формул никак не связан с классами и объектами.
Ага, особенно если брать вектора/матрица и переопределять операции по ним в языке. Это уровень 0, где уже требуется создавать свои типы. А если брать системы ПИД из теории автоматического управления, то там набор формул управляет вполне ощутимо разнесенными "группами переменных", описывающих характеристики и состояния отдельных узлов ПИД.
G>Связь модели с классами только в голове разработчика.
Она там рождается, разумеется, и в плоском тексте мы лишь стараемся максимально приближенно к предметной области выразить, то, что родилось в голове. С переменным успехом, разумеется.
V>>Попробуй привести пример, который тут не раскатают по асфальту. G>Пример чего?
Пример программы — не модели.
G>>>Отношение is-a отлично достигается без наследования реализации. Интерфейсы (выше ты привел именно наследование интерфейсов), typeclasses в хаскеле, ducktyping в динамических языках. Это все позволяет выстраивать отношения is-a.
V>>Для ООП-скриптовых языков ducktyping работает на уровне отдельного метода, и лишь предоставляет способ реализации обмена сигналами для целей собственно работы ООП в этой динамике.
G>Какая-то слишком заумная фраза, смысл её мне остался непонятен.
G>Тут все понимают интефейс, как явно указанный набор методов\свойств, которые реализует объект.
Кроме тебя — никто. Да, используют просто сокращенное "интерфейс" когда идет обсуждение в рамках конкретного языка, но когда речь об ООП в целом — все прекрасно понимают о чем речь.
V>>Заметь, с т.з. клиентов таких интерфейсов, им глубоко до фени, абстрактный он или нет, это подробности уже самого интерфейса. G>Замечу что это неверно, особенно когда дело касается наследования.
Еще раз, клиентам объектов до фени. Или ты о том, что в некоторых платформах вызовы абстрактных методов и методов интерфейсов компилируются в разные инструкции? Ну дык, для того ЯВУ и нужны, чтобы мы от этих вещей абстрагировались.
V>>Абстрактные интерфейсы предназначены для случая надобности сокрытия полного АПИ реализующих классов, ведь термин "абстракция" означает выделение сути/основы. То, что в некоторых языках абстрактные интерфейсы используются порой для побочных целей, например для порождения нескольких параллельных иерархий is-a — лишь следствие отсутствия в этих языках множественного наследования. То бишь, инструмент абстрагирования применяется даже там, где размер задачи абстрагирования не требует. G>Ну это твои домыслы, которые не соответствуют практике.
К твоему сожалению не так. Это лишь узкий кругозор у кое кого, что даже нельзя посмотреть, что происходит в других языках.
V>>Рациональное зерно в наследовании абстрактных интерфейсов для построения объектной иерархии разумеется есть. И чем больше иерархия, тем больше в этом смысла. Мы избавляем такую иерархию от подробностей реализации составляющих её элементов, т.е. банально уменьшаем информационную сложность иерархии. Причем, учитывая связи м/у объектами (например, из-за использования общих или базовых реализаций), мы можем нарваться на рост числа зависимостей, близкий к квадратичному от кол-ва элементов иерархии. И вот смотрим на современные программы, где многие десятки сущностей, если не сотни... Понятное дело, что есть здравое желания снизить сложность архитектуры системы на порядок и даже чуть больше. G>Смотрю я .NET FW ине могу найти интерфейсов, более 3 уровней наследования. G>Видимо создатели библиотек в 200000 классов (кажись такое число) не разделяют твоего мнения.
Видимо, кто-то не в состоянии сообразить, что интерфейсов должно быть на порядки меньше, чем реализующих классов. Посему аппелировать к кол-ву классов как-то странно. И еще видимо, кто-то не понимает эквивалентность абстрактных классов и интерфейсов с т.з. архитектуры программы на дотнет, если не требуется множество интерфейсов в базе. Посмотри на дотнет теперь еще раз. И заодно оцени, какая доля публичных классов дотнета не идет корнем прямо или косвенно от интерфейсов или абстрактных классов. Эта доля ничтожно мала.
Ну и иерархии интерфейсов тоже есть, справедливости ради, хоть это было и необязательно для уровня библиотеки, которая должна вносить как можно меньше архитектурной сложности в конечное решение.
V>>Оно ничему не противоречит. Даже имея описанный вариант системы, иерархия которой расписана на абстрактных интерфейсах, ничто не мешает использовать наследование реализаций для конкретных используемых типов. G>Если прочитаешь внимательно, то тут многие говорят что наследование реализации без наследования интерфейсов вполне можно безопасно (то есть не не создавая проблем) использовать.
Естественно, и полно конкретных ситуаций, где это именно так.
G>Основная проблема в том что в большинстве языков наследование реализации автоматически наследует интерфейс.
Это проблема только в тех конкретных ситуациях, где это проблема. Понимаешь, вот так походя всё обобщая, ты превращаешь полезнейшие практики и наработки в средневековые предрассудки, которыми пытаешься пугать коллег.
V>>Вы в пылу спора всё время забываете, что вся эта абстрактность — вторична. G>Абстрактность ты придумал. Я использую интерфейс для отделения вещей друг от друга.
V>>Расшифруй, плиз, о каких достижениях речь, и куда именно попал твой оппонент? Сдается мне, тут уже наблюдается тихий спор с самим собой.
G>Чаще всего укушенные ООП любят говорить что только ООП позволяет полиморфизм и отношение is-a.
Таки я прав и это был неоконченный спор с самим собой. Возможно, что интересный и нам, только введи нас в курс дела.
Re[7]: Почему объектно-ориентированное программирование пров
Здравствуйте, AndrewVK, Вы писали:
SV.>>, а в бытовом смысле надо уточнять. Что будет контрактом в шарпе? AVK>Публичный интерфейс класса или интерфейс. В классе два контракта — публичный и для потомков.
Стало быть, вы имеете в виду protected-секцию класса, она же "контракт для потомков". ("Публичного контракта" может не быть, а значит, он не связан неразрывно с наследованием реализаций). Тогда я согласен с вашим утверждением, что в мейнстримовых ЯП такая связь неизбежна.
Давайте перейдем ко второму утверждению — что это проблема. Это может быть проблемой в частных случаях (каких, кстати?), но не в общем, коль скоро потомки активно заставляют предка отрабатывать контракт, а сами они запечатаны (и действие контракта прервано).
Re[15]: Почему объектно-ориентированное программирование про
V>>Какая именно типизация имеется ввиду, статическая или динамическая? G>Естественно статическая.
Неестественно, учитывая историю появления ООП.
V>>И при чем тут эта частность с типизацией, если полно не ОО-языков с обоими видами типизации и без типизации вообще, точно так же как полно ОО-языков опять же с обоим видами типизации и без типизации вообще. Классы могут быть поддержаны системой типов, а могут быть и нет. Класс — это "шаблон" объекта и одновременно type identity для целей типизации. Но если типизации нет, то и классы зачастую не нужны. И тогда мы наблюдаем "шаблоны" объектов в чистом виде, как в JavaScript. Фактически там нет классов, там есть "образцы" объектов. G>Это кстати доказывает неортогональность "классов" (как бы они не выражались) и объектов.
Ну ты так и не понял дуальность роли классов: служить прототипом и type identity. Когда "класс" нужен только как прототип, его называют шаблоном/образцом/прототипом. И реализуется это удобнее всего не в виде выделенной сущности-типа, а в виде экземпляра объекта — прототипа, создание других объектов по которому — суть клонирование прототипа. Ощути, насколько поменялась картинка, как только мы убираем типы в явном виде.
G>Так что каша покачто у тебя.
Перечитай пояснение, должно помочь.
G>А ты как-нить можешь подтвердить свое мнение? G>Даже гугл с тобой не согласен.
Гуглом тоже уметь надо пользоваться. Взгляни на работу компиляторов, что они делают, когда один тип наследует другого. И тогда станет понятно, что искать. Твое замечание в соседнем посте насчет автоматического наследования публичных интерфейсов в ООП при наследовании реализаций и отличия в этом от собственно агрегирования — верное. Но на этом и все, бо я и так сказал о "частном случае". Частность в этом моменте и заключается, что не просто агрегируется база, но автоматически ее публичный интерфейс становится и нашим публичным интерфейсом. Хотя, и это не всегда так. Например, в С++ есть protected/private наследование, что позволяет агрегировать базу, переопределять её виртуальные методы, тем не менее не наследуя её публичного интерфейса и не имея возможности извне привести ссылку на объект к его приватной базе.
V>>>>В общем, ты опять попутал причину и следствие. Миксины не самоцель, а инструмент, пригодный для обхода ограничений языка. G>>>Для обхода ограничений ООП. Ну об этом я и говорю. V>>Ничего-то ты не понимаешь. G> G>Слив зощитан.
Кем засчитан? Ограничения не в ООП как таковом, а в конкретных реализациях. И ты этого по-прежнему в упор не понимаешь.
Re[17]: Почему объектно-ориентированное программирование про
Здравствуйте, gandjustas, Вы писали:
G>>>Модель предметной области — тоже результат некоторой индивидуальной умственной деятельности и обладает теми же свойствами.
SV.>>Обладает, но в меньшей мере. G>Докажи. Вряд ли у тебя получится, потому что эта мера и зависит от конкретного человека.
Охренеть. Интересно, а какое доказательство вы вообще приняли бы?
gandjustas, доказать можно теорему, исходя из аксиом. См. тут: http://ru.wikipedia.org/wiki/%D0%94%D0%B5%D0%B4%D1%83%D0%BA%D1%82%D0%B8%D0%B2%D0%BD%D0%B0%D1%8F_%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0 Разработка софта — не дедуктивная система, и доказать нельзя ничего. Максимум, что мы ВМЕСТЕ можем сделать, это провести опрос и посмотреть, какой группе разработчиков удобнее с чьим кодом работать. Но для этого надо, чтобы для начала вы привели свой, отличный от моего, подход к проектирования API, в виде псевдокода, как у меня. Затем мы оформим голосование и получим... результаты голосования, а не доказательство. По-хорошему, следовало бы набрать две большие группы, чтобы в каждой были представлены все типы разработчиков, дать каждой достаточно сложный API и заставить писать, оценивая время и качество. Но такой эксперимент жизнь уже поставила. Сколько Windows-разработчиков пишет на голом WinAPI, а сколько — на MFC/Delphi/C++ Builder/WinForms etc. etc.?
SV.>>Знаете, как говорят — дураки спорят о крайностях, а умные — о мере? G>Знаю, но это к теме разговора не имеет отношения.
Re[19]: Почему объектно-ориентированное программирование про
A>Принцип LSP описывает отношение между классом-наследником и одним базовым классом.
Правильно, речь о гомоморфности каждой отдельно рассматриваемой иерархии. Вопрос в силе: с чего ты взял, что конечный объект должен участвовать лишь в одной иерархии?
Re[8]: Почему объектно-ориентированное программирование пров
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
V>>>При чем тут "реального"? Ключевое слово — модель. Например, можно брать математические модели. G>>Математическая модель — набор формул. Этот набор формул никак не связан с классами и объектами.
V>Ага, особенно если брать вектора/матрица и переопределять операции по ним в языке. Это уровень 0, где уже требуется создавать свои типы.
Любые свои типы это классы ООП?
Я вот знаю много разных типов: кортежи, списки, варианты, записи.
К ООП имеют весьма отдаленное отношение, которое заключается только в том что эти типы худо-бедно можно выразить через классы. Но зачастую без поддержки языка работать с ними сложно.
V>А если брать системы ПИД из теории автоматического управления, то там набор формул управляет вполне ощутимо разнесенными "группами переменных", описывающих характеристики и состояния отдельных узлов ПИД.
Даже боюсь спрашивать что есть ПИД.
G>>Связь модели с классами только в голове разработчика.
V>Она там рождается, разумеется, и в плоском тексте мы лишь стараемся максимально приближенно к предметной области выразить, то, что родилось в голове. С переменным успехом, разумеется.
В результатах только один "абстрактный интерфейс", причем по ссылке не объяснено в чем отличие абстрактного от неабстрактного.
Поэтому давай пользоваться более устоявшейся терминологией.
G>>Тут все понимают интефейс, как явно указанный набор методов\свойств, которые реализует объект.
V>Кроме тебя — никто. Да, используют просто сокращенное "интерфейс" когда идет обсуждение в рамках конкретного языка, но когда речь об ООП в целом — все прекрасно понимают о чем речь.
Угу, все понимают и никто ниче не говорит. Твое сознание тебя подводит.
V>>>Заметь, с т.з. клиентов таких интерфейсов, им глубоко до фени, абстрактный он или нет, это подробности уже самого интерфейса. G>>Замечу что это неверно, особенно когда дело касается наследования.
V>Еще раз, клиентам объектов до фени. Или ты о том, что в некоторых платформах вызовы абстрактных методов и методов интерфейсов компилируются в разные инструкции? Ну дык, для того ЯВУ и нужны, чтобы мы от этих вещей абстрагировались.
Видимо я неправильно понял чем отличаются твои абстрактные интерфейсы от неабстрактных.
Может объяснишь?
V>>>Абстрактные интерфейсы предназначены для случая надобности сокрытия полного АПИ реализующих классов, ведь термин "абстракция" означает выделение сути/основы. То, что в некоторых языках абстрактные интерфейсы используются порой для побочных целей, например для порождения нескольких параллельных иерархий is-a — лишь следствие отсутствия в этих языках множественного наследования. То бишь, инструмент абстрагирования применяется даже там, где размер задачи абстрагирования не требует. G>>Ну это твои домыслы, которые не соответствуют практике. V>К твоему сожалению не так. Это лишь узкий кругозор у кое кого, что даже нельзя посмотреть, что происходит в других языках.
Ты хоть приводи подтверждения своим высказываниям.
А то твое понимание ООП, интерфейсов, наследования и других инструментов не соотвествует практике и даже той статье в википедии, на которую ты прислал ссылку.
Хотя может ты просто настолько заумно пытаешься все объяснить.
V>>>Рациональное зерно в наследовании абстрактных интерфейсов для построения объектной иерархии разумеется есть. И чем больше иерархия, тем больше в этом смысла. Мы избавляем такую иерархию от подробностей реализации составляющих её элементов, т.е. банально уменьшаем информационную сложность иерархии. Причем, учитывая связи м/у объектами (например, из-за использования общих или базовых реализаций), мы можем нарваться на рост числа зависимостей, близкий к квадратичному от кол-ва элементов иерархии. И вот смотрим на современные программы, где многие десятки сущностей, если не сотни... Понятное дело, что есть здравое желания снизить сложность архитектуры системы на порядок и даже чуть больше. G>>Смотрю я .NET FW ине могу найти интерфейсов, более 3 уровней наследования. G>>Видимо создатели библиотек в 200000 классов (кажись такое число) не разделяют твоего мнения.
V>Видимо, кто-то не в состоянии сообразить, что интерфейсов должно быть на порядки меньше, чем реализующих классов.
Так ты говорил не про количество, а про большую иерархию" или я тебя неправильно понял.
V>Посему аппелировать к кол-ву классов как-то странно.
Просто метрика объема библиотеки.
V>И еще видимо, кто-то не понимает эквивалентность абстрактных классов и интерфейсов с т.з. архитектуры программы на дотнет, если не требуется множество интерфейсов в базе. Посмотри на дотнет теперь еще раз. И заодно оцени, какая доля публичных классов дотнета не идет корнем прямо или косвенно от интерфейсов или абстрактных классов. Эта доля ничтожно мала.
Это ты что теперь доказать пытаешься?
Не уводи в сторону разговор. Ты сказал:
V>>>Рациональное зерно в наследовании абстрактных интерфейсов для построения объектной иерархии разумеется есть. И чем больше иерархия, тем больше в этом смысла.
Я же тебе говорю что в .NET нету больших иерархий абстрактных интерфейсов.
Хотя я понял, что я не понял твоего определения абстрактного интерфейса.
V>Ну и иерархии интерфейсов тоже есть, справедливости ради, хоть это было и необязательно для уровня библиотеки, которая должна вносить как можно меньше архитектурной сложности в конечное решение.
Есть, но довольно маленькие. Это противоречит тому что выделено выше.
G>>Основная проблема в том что в большинстве языков наследование реализации автоматически наследует интерфейс.
V>Это проблема только в тех конкретных ситуациях, где это проблема. Понимаешь, вот так походя всё обобщая, ты превращаешь полезнейшие практики и наработки в средневековые предрассудки, которыми пытаешься пугать коллег.
То что сегодня не проблема завтра может стать проблемой. Наследование — очень сильная связь между классами, её тяжело разрывать.
Я это показывал на примере с наследованием устройствам.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, artelk, Вы писали:
A>>Принцип LSP описывает отношение между классом-наследником и одним базовым классом.
V>Правильно, речь о гомоморфности каждой отдельно рассматриваемой иерархии.
Ээ.. А причем тут гомоморфность?
V>Вопрос в силе: с чего ты взял, что конечный объект должен участвовать лишь в одной иерархии?
Это ко мне вопрос? Где я такое утверждал или имел ввиду?
Re[16]: Почему объектно-ориентированное программирование про
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
V>>>Какая именно типизация имеется ввиду, статическая или динамическая? G>>Естественно статическая.
V>Неестественно, учитывая историю появления ООП.
Первый ООП язык — Simula. Вполне себе статически типизированный.
Первый массовый ООП язык — С++, тоже вполне статически типизированный.
V>>>И при чем тут эта частность с типизацией, если полно не ОО-языков с обоими видами типизации и без типизации вообще, точно так же как полно ОО-языков опять же с обоим видами типизации и без типизации вообще. Классы могут быть поддержаны системой типов, а могут быть и нет. Класс — это "шаблон" объекта и одновременно type identity для целей типизации. Но если типизации нет, то и классы зачастую не нужны. И тогда мы наблюдаем "шаблоны" объектов в чистом виде, как в JavaScript. Фактически там нет классов, там есть "образцы" объектов. G>>Это кстати доказывает неортогональность "классов" (как бы они не выражались) и объектов.
V>Ну ты так и не понял дуальность роли классов: служить прототипом и type identity. Когда "класс" нужен только как прототип, его называют шаблоном/образцом/прототипом. И реализуется это удобнее всего не в виде выделенной сущности-типа, а в виде экземпляра объекта — прототипа, создание других объектов по которому — суть клонирование прототипа. Ощути, насколько поменялась картинка, как только мы убираем типы в явном виде.
Да какая разница? ты сказал об ортогональности (то есть независимости) понятий, а теперь сам приводишь аргументы что они зависимы.
G>>А ты как-нить можешь подтвердить свое мнение? G>>Даже гугл с тобой не согласен.
V>Гуглом тоже уметь надо пользоваться.
Значит не можешь.
V>Взгляни на работу компиляторов, что они делают, когда один тип наследует другого. И тогда станет понятно, что искать.
Ну и что же такого делает компилятор C# что чтобы можно было утверждать что наследование и агрегирование — одно и тоже.
V>Твое замечание в соседнем посте насчет автоматического наследования публичных интерфейсов в ООП при наследовании реализаций и отличия в этом от собственно агрегирования — верное. Но на этом и все, бо я и так сказал о "частном случае". Частность в этом моменте и заключается, что не просто агрегируется база, но автоматически ее публичный интерфейс становится и нашим публичным интерфейсом.
Ну да, мелочи, всего-то контракт наследуется.
V>Хотя, и это не всегда так. Например, в С++ есть protected/private наследование, что позволяет агрегировать базу, переопределять её виртуальные методы, тем не менее не наследуя её публичного интерфейса и не имея возможности извне привести ссылку на объект к его приватной базе.
Непубличное наследование и есть разновидность mixin.
V>>>>>В общем, ты опять попутал причину и следствие. Миксины не самоцель, а инструмент, пригодный для обхода ограничений языка. G>>>>Для обхода ограничений ООП. Ну об этом я и говорю. V>>>Ничего-то ты не понимаешь. G>> G>>Слив зощитан.
V>Кем засчитан? Ограничения не в ООП как таковом, а в конкретных реализациях. И ты этого по-прежнему в упор не понимаешь.
Тогда давай по новой: что ты считаешь ООП? Приведи точное и непротиворечивое определение.
Я как-то по наивности пользуюсь общепринятым, которое ты можешь прочитать в ссылке, которую сам приводил.
Re[19]: Почему объектно-ориентированное программирование про
Здравствуйте, gandjustas, Вы писали:
V>>В классике, наследование реализации — не есть непременный атрибут ООП.
G>А что тогда непременный атрибут ООП? G>Я пользуюсь общепринятым определением ООП: инкапсуляция, наследование реализации (повторное использование), полиморфизм.
Это не определение ООП, это "три кита", на которых стоит современный ООП. Т.е. это практики, которые используются для достижения целей ООП. А вот из википедии, что есть ООП:
По мнению Алана Кея, создателя языка Smalltalk, которого считают одним из «отцов-основателей» ООП, объектно-ориентированный подход заключается в следующем наборе основных принципов (цитируется по вышеупомянутой книге Т. Бадда).
Всё является объектом. Вычисления осуществляются путём взаимодействия (обмена данными) между объектами, при котором один объект требует, чтобы другой объект выполнил некоторое действие. Объекты взаимодействуют, посылая и получая сообщения. Сообщение — это запрос на выполнение действия, дополненный набором аргументов, которые могут понадобиться при выполнении действия. Каждый объект имеет независимую память, которая состоит из других объектов.
G>Причем каждый из этих компонент есть и в других парадигмах (и даже лучше делается).
Правильно, многие практики shared м/у парадигмами.
V>>Наследование — это лишь один из способов повторного использования кода в статически-типизируемых ОО-языках. Миксины можно рассматривать как альтернативу того же самого.
G>Ну и насколько "альтернатива наследования" относится к ООП?
Думаю, теперь и ты и сам в состоянии решить.
V>>Т.е. эти инструменты ни расширяют, ни еще как-то модифицируют ОО-парадигму, а являются лишь удобными и признанными практиками в её рамках, поддержанными на уровне языков. G>Ок, ссылку на авторитетный источник приведи. G>Кстати почему в mainstream языках (которые имеют бирку ООП) нету mixin-ов? G>Наверное потому что это очень признанные практики в ООП.
Есть, просто это не так называется. Например в С++ виртуальное наследование — это и есть наследование в стиле ООП, когда обеспечивается транзитивность до одной корневой базы в случае сложных иерархий, а обычное множественное наследование в С++ — суть миксин, ибо каждая операция наследования целиком агрегирует базу. Сколько раз от базы отнаследуешься, столько раз будет выполнено агрегирование, т.е. столько экземпляров данных базы будет располагаться в памяти объекта. "Миксин" от одной базы предоставлен и в C#, скажите и на этом спасибо. Потому как в VB и этого не было, можно было наследовать интерфейсы, но нельзя было наследовать реализацию, надо было ручками делегирование описывать. В общем, одиночное наследование с агрегированием базы избавляет от того описанного эффекта с клонами этих баз для случая множественного наследования. Эти эффекты реально не всеми разработчиками понимаются и являются источниками ошибок. Поэтому оперирование миксинами в явном виде как бы более "честное", т.к. прямо указывается на количество экземпляров и способ композиции данных/функциональности.
G>Твои слова не соответствуют реальности в основном.
Это может быть верно с т.з. твоей реальности.
Re[18]: Почему объектно-ориентированное программирование про
Здравствуйте, SV., Вы писали:
SV.>Здравствуйте, gandjustas, Вы писали:
G>>>>Модель предметной области — тоже результат некоторой индивидуальной умственной деятельности и обладает теми же свойствами.
SV.>>>Обладает, но в меньшей мере. G>>Докажи. Вряд ли у тебя получится, потому что эта мера и зависит от конкретного человека.
SV.>Охренеть. Интересно, а какое доказательство вы вообще приняли бы?
SV.>gandjustas, доказать можно теорему, исходя из аксиом. См. тут: http://ru.wikipedia.org/wiki/%D0%94%D0%B5%D0%B4%D1%83%D0%BA%D1%82%D0%B8%D0%B2%D0%BD%D0%B0%D1%8F_%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0 Разработка софта — не дедуктивная система, и доказать нельзя ничего.
То есть будем считать что степень влияния конкретного дизайнера на конкретный дизайн одинакова, независимо от подхода к дизайну.
И твой аргумент про что "модель предметной области понятнее" отбросим как неорганизованный.
SV.>Максимум, что мы ВМЕСТЕ можем сделать, это провести опрос и посмотреть, какой группе разработчиков удобнее с чьим кодом работать. Но для этого надо, чтобы для начала вы привели свой, отличный от моего, подход к проектирования API, в виде псевдокода, как у меня. Затем мы оформим голосование и получим... результаты голосования, а не доказательство. По-хорошему, следовало бы набрать две большие группы, чтобы в каждой были представлены все типы разработчиков, дать каждой достаточно сложный API и заставить писать, оценивая время и качество.
У меня нет времени таким заниматься.
SV.>Но такой эксперимент жизнь уже поставила. Сколько Windows-разработчиков пишет на голом WinAPI, а сколько — на MFC/Delphi/C++ Builder/WinForms etc. etc.?
А это тут причем? Ты же говорил о моделях, соответствующих реальному миру. Я вот постоянно использую объектные модели, но они крайне редко соответствуют каким-то моделям реального мира (если эти модели специально не выдумывать постфактум).
Re[9]: Почему объектно-ориентированное программирование пров
Здравствуйте, gandjustas, Вы писали:
I>>Не совсем ясно, что ты понимаешь под объектами реального мира. "собака", "кошка" ?
I>>А куда деть явления, отношения ? Ну, например, "проект"
G>Да пожалуйста. В постановке задачи у меня есть "проект" и в интерфейсе много где есть "проект", а вот класса "проект" нету.
И что с того ?
Вот смотри, есть китобойное судно. Сколько китятины изловит кок, гальюнщик, боцман, матрос добычи, владелец судна, владелец флотилии ?
Китятина есть, а кто ж наловил её —
Вот так и с твоим "проектом". Если класса нет, то эти ничего не означает.
Re[8]: Почему объектно-ориентированное программирование пров
Здравствуйте, SV., Вы писали:
SV.>Давайте перейдем ко второму утверждению — что это проблема. Это может быть проблемой в частных случаях (каких, кстати?), но не в общем, коль скоро потомки активно заставляют предка отрабатывать контракт, а сами они запечатаны (и действие контракта прервано).
Это не есть теоретические измышления, это сугубо практические наблюдения — в 99% случаев наследование используется криво. Т.е. механизм приносит больше вреда, чем реальной пользы.
... << RSDN@Home 1.2.0 alpha 5 rev. 1495 on Windows 7 6.1.7600.0>>
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
V>>>В классике, наследование реализации — не есть непременный атрибут ООП.
G>>А что тогда непременный атрибут ООП? G>>Я пользуюсь общепринятым определением ООП: инкапсуляция, наследование реализации (повторное использование), полиморфизм.
V>Это не определение ООП, это "три кита", на которых стоит современный ООП. Т.е. это практики, которые используются для достижения целей ООП. А вот из википедии, что есть ООП: V>
V>По мнению Алана Кея, создателя языка Smalltalk, которого считают одним из «отцов-основателей» ООП, объектно-ориентированный подход заключается в следующем наборе основных принципов (цитируется по вышеупомянутой книге Т. Бадда).
V>Всё является объектом. Вычисления осуществляются путём взаимодействия (обмена данными) между объектами, при котором один объект требует, чтобы другой объект выполнил некоторое действие. Объекты взаимодействуют, посылая и получая сообщения. Сообщение — это запрос на выполнение действия, дополненный набором аргументов, которые могут понадобиться при выполнении действия. Каждый объект имеет независимую память, которая состоит из других объектов.
Ок, как сюда относится mixin? Судя по всему вообще никак. Да и наследование тоже.
С точки зрения кея самый правильный ООП — это Эрланг. Но Кей идеалист в данном вопрос, а smalltalk очень мощный язык, гораздо мощнее, чем многие другие языки, которые носят бирку ООП.
V>>>Т.е. эти инструменты ни расширяют, ни еще как-то модифицируют ОО-парадигму, а являются лишь удобными и признанными практиками в её рамках, поддержанными на уровне языков. G>>Ок, ссылку на авторитетный источник приведи. G>>Кстати почему в mainstream языках (которые имеют бирку ООП) нету mixin-ов? G>>Наверное потому что это очень признанные практики в ООП.
V>Есть, просто это не так называется.
Ну и как оно называется? Сразу со ссылкой.
V>Например в С++ виртуальное наследование — это и есть наследование в стиле ООП, когда обеспечивается транзитивность до одной корневой базы в случае сложных иерархий, а обычное множественное наследование в С++ — суть миксин, ибо каждая операция наследования целиком агрегирует базу. Сколько раз от базы отнаследуешься, столько раз будет выполнено агрегирование, т.е. столько экземпляров данных базы будет располагаться в памяти объекта. "Миксин" от одной базы предоставлен и в C#, скажите и на этом спасибо. Потому как в VB и этого не было, можно было наследовать интерфейсы, но нельзя было наследовать реализацию, надо было ручками делегирование описывать. В общем, одиночное наследование с агрегированием базы избавляет от того описанного эффекта с клонами этих баз для случая множественного наследования. Эти эффекты реально не всеми разработчиками понимаются и являются источниками ошибок. Поэтому оперирование миксинами в явном виде как бы более "честное", т.к. прямо указывается на количество экземпляров и способ композиции данных/функциональности.
У тебя каша в терминах. Приведи в порядок их тогда продолжим.
Re[10]: Почему объектно-ориентированное программирование про
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
I>>>Не совсем ясно, что ты понимаешь под объектами реального мира. "собака", "кошка" ?
I>>>А куда деть явления, отношения ? Ну, например, "проект"
G>>Да пожалуйста. В постановке задачи у меня есть "проект" и в интерфейсе много где есть "проект", а вот класса "проект" нету.
I>И что с того ?
I>Вот смотри, есть китобойное судно. Сколько китятины изловит кок, гальюнщик, боцман, матрос добычи, владелец судна, владелец флотилии ?
I>Китятина есть, а кто ж наловил её —
I>Вот так и с твоим "проектом". Если класса нет, то эти ничего не означает.
А о чем разговор вообще?
Изначально высказывалась мысль что есть некоторые отношения между объектами реального мира и необходимо их в таком виде перенести на иерархии классов в программе. Я же сказал что такой подход к проектированию оправдан в крайне малом проценте приложений.
Меня попросили привести пример программы, в которой нету модели реального мира в виде иерархии классов.
Я привел.
Re[11]: Почему объектно-ориентированное программирование про
Здравствуйте, gandjustas, Вы писали:
G>Изначально высказывалась мысль что есть некоторые отношения между объектами реального мира и необходимо их в таком виде перенести на иерархии классов в программе. Я же сказал что такой подход к проектированию оправдан в крайне малом проценте приложений. G>Меня попросили привести пример программы, в которой нету модели реального мира в виде иерархии классов. G>Я привел.
Хорошо, давай сначала. Сколько китятины добывает кок на китобое ?
Re[21]: Почему объектно-ориентированное программирование про
Здравствуйте, gandjustas, Вы писали:
G>У тебя каша в терминах. Приведи в порядок их тогда продолжим.
Каша в терминах существует сама по себе. Одним и тем же термином в разных языках называются разные вещи. Поэтому попытайся сосредоточиться на сути происходящего, бо в терминологическом споре мы далеко не уйдем. Мы уже уперлись, лишь только задавшись вопросом, что есть ООП.
Re[17]: Почему объектно-ориентированное программирование про
G>Непубличное наследование и есть разновидность mixin.
Собсно, для демонстрации этого пример и приводил.
V>>Кем засчитан? Ограничения не в ООП как таковом, а в конкретных реализациях. И ты этого по-прежнему в упор не понимаешь. G>Тогда давай по новой: что ты считаешь ООП? Приведи точное и непротиворечивое определение. G>Я как-то по наивности пользуюсь общепринятым, которое ты можешь прочитать в ссылке, которую сам приводил.
Далее в википедии идет про классы, но мы же знаем про языки, в которых декларируется поддержка ООП, но классы не являются тем же, чем они являются в приведенных тобой симуле и С++, а являются прототипами для клонирования экземпляров. Поэтому понятие "классов" я склонен относить к подробностям системы типов конкретного языка, а не ООП как такового. Класс в мейнстриме это не только шаблон реализации типа, но и описание контракта типа. А последнее встречается даже в классах типов в Хаскель, хоть там ООП и не пахнет, т.е. из термина остается голый контракт, наподобие интерфейсов Java/.Net.
С терминологией вообще беда, если по справедливости, т.к. практически всегда требуется уточнение в рамках какого языка термин используется.
Re[17]: Почему объектно-ориентированное программирование про
Здравствуйте, gandjustas, Вы писали:
V>>Взгляни на работу компиляторов, что они делают, когда один тип наследует другого. И тогда станет понятно, что искать. G>Ну и что же такого делает компилятор C# что чтобы можно было утверждать что наследование и агрегирование — одно и тоже.
Сорри, пропустил интересный вопрос.
Для C# это делает не компилятор, а среда исполнения. Она располагает данные базового типа в памяти наследника. Для случая С++ это делает непосредственно компилятор. В случае множественного наследования компилятор располагает данные всех баз в памяти наследника в порядке, указанном при перечислении баз типа в его объявлении. При вызове методов наследника управление не передается непосредственно методам базы, оно передается через делегирующий код, в котором происходит смещение адреса this на область памяти, в которой хранятся агрегированные данные конкретной базы (и указатель на её vtable в т.ч.), и уже потом вызывается целевой код. Учитывая склонности С++ к оптимизации, зачастую этот thunk не живет в виде выделенного бинарного кода, а сразу происходит смещение адреса this на агрегированные данные базы для корректного вызова базового метода прямо в том месте, где происходит вызов. Но это лишь детали, а суть такова, что есть делегирующая функциональность, которую компилятор генерит автоматически.
