Ответ на »сообщение 3540« (Axcel)
___________________________

... Есть противоречие между наследованием реализации в ООП и необходимостью отчуждения программного продукта с последующим его развитием. И это объективное противоречие. А модульность как раз и позволяет свести к минимому возможные потери и ограничения.

Вот ради таких наблюдений и читаю форум...

Дорогой Axcel, "пешите ишшо" 8))

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

В третьих, может есть альтернативное решение? Может в Оберон-системах, это решается по-другому?
А что уже есть какое то отдельное Оберон-программирование, которое в принципе отличается от ООП ?

Не секрет, что и промышленность и академия в большинстве случаях довольно далеки и от идей ФЯ и от Оберон-технологий.

Не знаю как насчет оберонов, но ФП всегда было сильно именно в академической среде. Все таки самая близкая к математике.

Ответ на »сообщение 3541« (Jack Of Shadows)

Во первых, это проблема, раз уж о ней так "пекутся" и даже в Академии.
Во вторых, законный вопрос, почему это проблема в ООП, но не в ФЯ ?
В третьих, может есть альтернативное решение? Может в Оберон-системах, это решается по-другому?

Не секрет, что и промышленность и академия в большинстве случаях довольно далеки и от идей ФЯ и от Оберон-технологий.

Ответ на »сообщение 3538« (slava)
___________________________
Аспекты это еще один функциональный механизм, который теперь болтами прикручивается к ООП.
Причина заключается в том, что за годы работы с ООП, выяснилось что довольно большой класс типичных задач очень плохо реализуется в ООП. Эти задачи называются cross-cutting concerns.
То есть задачи, которые проходят красной нитью через всю иерархию классов, не давая возможности как то выделить их и решить отдельно.
Из таковых например
- проверка доступа к информации
- ведение аудита
- транзакционность.

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

Отсюда и попытка решения этих задач за пределами ООП, то есть аспектами.

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

Они у нас находятся в непрерывном state of denial :))

ответ на »сообщение 3539« (Сергей Перовский)

Гораздо важнее противоречие концепций модульного и объектного программирования в части наследования реализации. 

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

Ответ на »сообщение 3537« (Jack Of Shadows)
___________________________

Ответ на »сообщение 3534« (Сергей Перовский)
___________________________
"Если OOP, значит должен быть class и object, иначе это не OOP!"
Господа, а вы терминологию не путаете ?
Насколько я знаю - класс это тип, а обьект это экземпляр (instance) этого типа.
Так что в ООП действительно есть и классы (типы) и обьекты (переменные типа)

Хотя скажем в prototype based languages есть только обьекты.

Господа в курсе :)
Это просто старый спор о том, нужно ли отделять синтаксически записи от объектов.
Вирт считает, что не нужно.
В ТП и первых дельфях использовалось ключевое слово object, которое означало только возможность наличия методов и от record практически не отличалось.
В более поздних версиях использовалось ключевое слово class и подразумевалось наличие общего для всех объектов прототипа Tobject.
В Обероне, в принципе, можно написать нечто вроде TClass=Record(Tobject) и перестать спорить: класс определен, но является обычным типом, а не ключевым словом.
То, что методы описываются не внутри описания класса, а отдельно, для меня неудобство, но в общем мелкое - дело привычки.
Вообще, синтаксические споры, дело неблагодарное.
Что удобнее {} или begin end можно обсасывать годами без всякого толка.
Гораздо важнее противоречие концепций модульного и объектного программирования в части наследования реализации. Тут вопрос не в терминологии и внешнем виде программы.

Хотелось бы узнать мнение по поводу Aspect.
Появились всякие надстройки на языками: AspectJ, AspectC++.
Ваше мнение?

А то в универе даже курсы такие есть, кто-то даже наукой занимается в этой области, но что-то это странно выглядит, ИМХО.

Спасибо.

Ответ на »сообщение 3534« (Сергей Перовский)
___________________________
"Если OOP, значит должен быть class и object, иначе это не OOP!"
Господа, а вы терминологию не путаете ?
Насколько я знаю - класс это тип, а обьект это экземпляр (instance) этого типа.
Так что в ООП действительно есть и классы (типы) и обьекты (переменные типа)

Хотя скажем в prototype based languages есть только обьекты.