Re: Концептно-ориентированное прораммирование (КОП) - Философия программирования

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

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

S>>А мне почему-то сразу вспоминаетя другая ситуация. Когда разрабатывался JBoss где-то на 2-ой или 3-ей версии, то постоянно вламывались какие-то товарици, стучали кулаком по столу и требовали предоставить подробную документацию. Мол так писать системы нельзя, нужна документация, а то пользователям трудно жить. Им вежливо (а иногда и не очень) пытались объяснить, мол, проект бесплатный.

E>Кстати, не понятно почему именно эта история вспоминается. У JBoss-а был продукт, и не было документации, которая бы упростила использование этого продукта. И, что важно, было понятно, что это за продукт, для каких целей он предназначен и какие задачи решает.

Да в том-то и дело, что продукт был относительно новый и с чем его едят было не ясно (широкой аудитории по крайней мере). Без документации по серверу приложений работать крайне трудно, поскольку всегда много "особенностей". Но дело не в этом. А в том, что всегда найдутся недовольные, которые почему-то требуют, чтобы их убедили в чем-то или предоставили что-то. И это раздражает. Если что-то не нравится, то не ешь, либо приготовь это бдюдо лучше.

E>В вашем же случае нет продукта, но есть обширное описание чего-то, что предназначено не понятно для чего и может (может ли?) быть использовано не понятно как.

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

Впрочем, это нормальная реакция форума. Народ поглазеет, посмеется, поругается и пойдет дальше. Если найдется один другой кто заинтересуется, то задачу можно считать выполненной.

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

C>Причем водиночку вполне реально сделать интересные вещи — достаточно
C>посмотреть на mxx_ru или SObjectiser у eao197.

SObjectizer -- это далеко не в одиночку. Его принципы и идеология была разработана очень, очень мощным коллективом, где я был всего лишь подмастерьем.

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

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

C>>Причем водиночку вполне реально сделать интересные вещи — достаточно
C>>посмотреть на mxx_ru или SObjectiser у eao197.

Правильно, принцип простой: если хочешь что-то сделать, то делай, а не критикуй.

E>SObjectizer -- это далеко не в одиночку. Его принципы и идеология была разработана очень, очень мощным коллективом, где я был всего лишь подмастерьем.

Смею предположить, что кто-то за это платил... Но дело не в этом. Представь, что кто-то сейчас в форуме встрянет, и начнет грузить тебя, что сделал ты все не так, делать надо было по-другому, и вообще мне не понятно, что ты там настрогал, а потом будь добр, убеди меня в своей праводе. (Проще говоря, ты козел, но можешь попытаться меня убедить, что это не так.) Я могу представить что ты ему ответишь.

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

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

WH>>Вот мне почемуто сразу ясно что открыть, а что не нужно.
S>А вот мне чем дальше, тем менее ясным становится.
Так может просто поучится проектировать?

S>Как я выше отметил, есть разные подходы к проектированию и такое разделение это всего лишь один из них (не самый лучший).
О как?! А какой по твоему лучший? Делать монолитный клубок? В лес!

S>Вот это мне нравится. Вот только как описать уровни? Какие средства для этого использовать?
А зачем их формально описывать?
Что это нам дает? Какие задачи решает?

S>В настоящее время таковых практически нет (в смысле поддержки в языках программирования).
И не надо.
S>А в КОП это одна из основных целей, поскольку слоеная организация системы это основное предположение.
Те КОП ради КОП? В лес!
S>Каждый уровень имеет свой способ представления и доступа, свои средства защиты и т.д. Т.е. это свое пространство со своими правилами игры.
Зачем?
От неправильной архитектуры это всеравно не спасет. Это к гадалке не ходи.
От неправильной архитектуры спасает только правильный архитектор. И никакой язык не поможет неправильному архитектору создать правильную архитектуру.

Прокси, а весь твой КОП это прокси в языке, нужны очень редко. И делаются в любом языке не напрягаясь. А в языках с метапрограммированием таких как nemerle делается написанием простенького макроса(не путать с макросами С/С++).

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

S>Да в том-то и дело, что продукт был относительно новый и с чем его едят было не ясно (широкой аудитории по крайней мере). Без документации по серверу приложений работать крайне трудно, поскольку всегда много "особенностей". Но дело не в этом. А в том, что всегда найдутся недовольные, которые почему-то требуют, чтобы их убедили в чем-то или предоставили что-то. И это раздражает. Если что-то не нравится, то не ешь, либо приготовь это бдюдо лучше.
При чем тут давольние или не довольные. Ты объясни зачем оно нужно?
Я понимаю зачем нужно структурное программирование, зачем нужно ООП, зачем нужно функциональное программирование, зачем нужно метапрограммирование. Я даже понимаю адептов динамически типизированных языков хотя и не согласен с их точкой зрения.
А зачем нужен твой КОП понять не могу.

S>Предлагается совершенно конкретный механизм. Описание далеко от идеала, это правда. Но ведь и предмет тоже не простой.
Все что понятно из твоего описания это то что язык поддерживает генерацию проксей.
Но зачем мне это если есть языки с метапрограммированием?
Ведь я могу написать простенькую метапрограмму которая все это сделает.
S>Я не зря привел пример АОР, поскольку там тоже на первый взгляд не ясно, для чего это все нужно.
С АОП все просто и понятно. Это всего лишь частный случай метапрограммирования. А оно появилось еще в Lisp'е если не раньше.
А зачем нужен частный случай если можно иметь общий?
S>Я абсолютно уверен, что за несколько дней в КОП точно ничего не понять.
Боюсь мне никогда не понять зачем нужен еще один частный случай метапрограммирования встроенный в язык.

S>Впрочем, это нормальная реакция форума. Народ поглазеет, посмеется, поругается и пойдет дальше. Если найдется один другой кто заинтересуется, то задачу можно считать выполненной.
Ну так бы сразу и сказал что очередной свидетель Оберона...

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

S>>Да в том-то и дело, что продукт был относительно новый и с чем его едят было не ясно (широкой аудитории по крайней мере). Без документации по серверу приложений работать крайне трудно, поскольку всегда много "особенностей". Но дело не в этом. А в том, что всегда найдутся недовольные, которые почему-то требуют, чтобы их убедили в чем-то или предоставили что-то. И это раздражает. Если что-то не нравится, то не ешь, либо приготовь это бдюдо лучше.
WH>При чем тут давольние или не довольные. Ты объясни зачем оно нужно?
WH>Я понимаю зачем нужно структурное программирование, зачем нужно ООП, зачем нужно функциональное программирование, зачем нужно метапрограммирование. Я даже понимаю адептов динамически типизированных языков хотя и не согласен с их точкой зрения.
WH>А зачем нужен твой КОП понять не могу.

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

S>>Предлагается совершенно конкретный механизм. Описание далеко от идеала, это правда. Но ведь и предмет тоже не простой.
WH>Все что понятно из твоего описания это то что язык поддерживает генерацию проксей.
WH>Но зачем мне это если есть языки с метапрограммированием?
WH>Ведь я могу написать простенькую метапрограмму которая все это сделает.

Забудь про прокси. Просто всем не угодишь и каждому надо объяснять на том спец. языке, который он знает. Прокси это один из возможных способов опосредования, т.е. способ вставить посредника. В КОП главная цель состоит в описании общего и максимально универсальноо механизма доступа, т.е. надо научиться моделировать ссылки и их функции. Это позволяет отвязаться от реальности и работать в своем собственном виртуальном пространстве, где живут объекты. Теперь это не объекты в памяти или БД. Это объекты в некотором виртуальном пространстве, где у них свои обозначени, свой жизненный цикл и т.п. Но пользуемся мы ими совершенно так же как и всегда. По моему, более конкретно задачу уже не сформулировать. Если нет, то объясни что не ясно.

S>>Я не зря привел пример АОР, поскольку там тоже на первый взгляд не ясно, для чего это все нужно.
WH>С АОП все просто и понятно. Это всего лишь частный случай метапрограммирования. А оно появилось еще в Lisp'е если не раньше.
WH>А зачем нужен частный случай если можно иметь общий?

Ну ясно зачем. Поскольку в метапрограммировании есть серьезные дефекты. С помощью АОП их попытались исправить. Причем довольно успешно (отсюда популярность). Но все равно даже в АОП остались серьезные проблемы, а потому ИМХО будущего у него нет.

S>>Я абсолютно уверен, что за несколько дней в КОП точно ничего не понять.
WH>Боюсь мне никогда не понять зачем нужен еще один частный случай метапрограммирования встроенный в язык.

S>>Впрочем, это нормальная реакция форума. Народ поглазеет, посмеется, поругается и пойдет дальше. Если найдется один другой кто заинтересуется, то задачу можно считать выполненной.
WH>Ну так бы сразу и сказал что очередной свидетель Оберона...

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

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

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

WH>>>Вот мне почемуто сразу ясно что открыть, а что не нужно.
S>>А вот мне чем дальше, тем менее ясным становится.
WH>Так может просто поучится проектировать?

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

А теперь вот сомнения грызут и хочется что-то человеческое придумать.

S>>Как я выше отметил, есть разные подходы к проектированию и такое разделение это всего лишь один из них (не самый лучший).
WH>О как?! А какой по твоему лучший? Делать монолитный клубок? В лес!

Ты говоришь правильные вещи, но это детский сад (выделение интерфейсов и т.п.), т.е. хорошо для преподавания. Ну а правильного подхода не сущестует. Есть просто адекватные и неадекватные, умело применяемые или неумело и т.д. Я бы например начал проектирование системы с построения жилища для объектов, системы их обслуживания и поддержания в нормальном состоянии.

S>>Вот это мне нравится. Вот только как описать уровни? Какие средства для этого использовать?
WH>А зачем их формально описывать?
WH>Что это нам дает? Какие задачи решает?

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

S>>В настоящее время таковых практически нет (в смысле поддержки в языках программирования).
WH>И не надо.

Кому как. Если получается без этого, то конечно не надо ничего искать нового. У меня например не получается, а потому я построил для себя новую теорию.

S>>А в КОП это одна из основных целей, поскольку слоеная организация системы это основное предположение.
WH>Те КОП ради КОП? В лес!
S>>Каждый уровень имеет свой способ представления и доступа, свои средства защиты и т.д. Т.е. это свое пространство со своими правилами игры.
WH>Зачем?
WH>От неправильной архитектуры это всеравно не спасет. Это к гадалке не ходи.
WH>От неправильной архитектуры спасает только правильный архитектор. И никакой язык не поможет неправильному архитектору создать правильную архитектуру.

Ну это ясно, никто не спорит. КОП это инструмент, который позволяет автоматизировать определенные задачи и все. А неправильно его использовать никто не запретит. Можно также и без него все правильно сделать. Так, чтобы программировать в стиле ООП совершенно не нужен ОО язык.

WH>Прокси, а весь твой КОП это прокси в языке, нужны очень редко. И делаются в любом языке не напрягаясь. А в языках с метапрограммированием таких как nemerle делается написанием простенького макроса(не путать с макросами С/С++).

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

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

S>Он позволяет описывать опосредованные представление и доступ к объектам. Проще говоря, мы можем моделировать ссылки и их функции. Это нужно для описания внутренней системы координат и внутренней структуры программы. Чего здесь может быть не ясного.
Не ясно зачем это нужно.
Что это дает?

S>Забудь про прокси. Просто всем не угодишь и каждому надо объяснять на том спец. языке, который он знает.
Я знаю много языков. В данном форуме наверное вобще нет людей которые знают только один язык.
Так что можешь объяснять на любом. В том числе на псевдокоде.
Покажи как все плохо при использованиее традиционных средств и как все хорошо при использовании твоего КОП. Ведь если ты понимаешь какие плюсы дает КОП то и пример тебе не составит труда привести.
А если КОП ничего не дает то на кой черт он нужен? Зачем мне не нужные абстракции?
S>Прокси это один из возможных способов опосредования, т.е. способ вставить посредника. В КОП главная цель состоит в описании общего и максимально универсальноо механизма доступа, т.е. надо научиться моделировать ссылки и их функции. Это позволяет отвязаться от реальности и работать в своем собственном виртуальном пространстве, где живут объекты. Теперь это не объекты в памяти или БД. Это объекты в некотором виртуальном пространстве, где у них свои обозначени, свой жизненный цикл и т.п. Но пользуемся мы ими совершенно так же как и всегда. По моему, более конкретно задачу уже не сформулировать. Если нет, то объясни что не ясно.
Ну и чем это отличается от проксей реализующих некоторый интерфейс?
Метапрограммированием можно легко устранить всю ручную работу.
Болие того практика показывает что работать прозрачно с объектами лежащими черт знает где вобще получается очень плохо. И никакие КОП тут не помогут.
Вобще единственный способ построить надежную распределенную или даже просто многопоточную систему это асинхронная посылка сообщений.
Любые другие методы создают массу проблем (хотя иногда они работают) и синтаксическим сахаром их не решить.

S>Ну ясно зачем. Поскольку в метапрограммировании есть серьезные дефекты. С помощью АОП их попытались исправить. Причем довольно успешно (отсюда популярность). Но все равно даже в АОП остались серьезные проблемы, а потому ИМХО будущего у него нет.
А вот с этого места по подробней пожалуйста.
Мне очень интересно знать какие фатальные недостатки есть у метапрограммирования и как их решает АОП.
Ну и о недостатках АОП тоже хочется услышать.
У меня есть свое мнение на этот счет вот только что-то мне подсказывает что оно не совпадает с твоим.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

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

S>Ты говоришь правильные вещи, но это детский сад (выделение интерфейсов и т.п.), т.е. хорошо для преподавания. Ну а правильного подхода не сущестует. Есть просто адекватные и неадекватные, умело применяемые или неумело и т.д. Я бы например начал проектирование системы с построения жилища для объектов, системы их обслуживания и поддержания в нормальном состоянии.
Те с "правильного" подхода которого не существует.

S>Описание уровня это сама первая и главная задача в проектировании. Здесь происходит разделение функций, ответственности, правил безопасности, формат обозначения объектов (ссылок), формат представления объектов и многое другое. В сложной системе основные функции сосредоточены на границах, а не в объектах (не в бизнес-логике). Немного преувеличивая большая система это и есть структура уровней — все остальное это уже мелочи.
Те система ради системы? Мне кажется что тебе деньги не за это платят.
Деньги платят за решение задач, а не за устраивание супер сложных границ системы.

S>Кому как. Если получается без этого, то конечно не надо ничего искать нового. У меня например не получается, а потому я построил для себя новую теорию.
А может нужно было просто научится использовать существующие инструменты?
Они прекрасно работаю. А куда можно засунуть твой КОП вобще не понятно.

S>Ну это ясно, никто не спорит. КОП это инструмент, который позволяет автоматизировать определенные задачи и все. А неправильно его использовать никто не запретит. Можно также и без него все правильно сделать. Так, чтобы программировать в стиле ООП совершенно не нужен ОО язык.
Так ты мне объясни какие преймущества дает КОП.
С ООП все понятно. С функциональным программированием тоже. А вот чето дает КОП не понятно.

S>Нет, в КОП нет прокси. Я просто сделал сравнение для тех, кто больше ничего не знает. КОП позволяет моделировать ссылки и их функции.
Зачем? Приведи пример.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

S>>Он позволяет описывать опосредованные представление и доступ к объектам. Проще говоря, мы можем моделировать ссылки и их функции. Это нужно для описания внутренней системы координат и внутренней структуры программы. Чего здесь может быть не ясного.
WH>Не ясно зачем это нужно.
WH>Что это дает?

Это я уже не в состоянии формально объяснить. Это все равно что пытаться объяснить зачем нужно ООП тому, кто всегда применял процедурное программирование. Т.е. что такое ООП он с трудом, но сможет понять, но зачем это нужно — никогда. Для этого нужно только время и большое число примеров. КОП в только в начале пути и этого нет. Поэтому пока я расчитывают только на тех, кто уже интуитивно чувствует, что это дает. Мой личный опыть показывает, что в больших глобальных системах (не только программных) проблемы возникают на стыках пространств (слоев, контейнеров), поэтому этим и надо заниматься. Что такое вообще объект? Этого никто никогда не знает, поскольку объект это ссылка. Есть ссылка — есть объект. Нет ссылки — нет объекта (даже если он есть). Поэтому надо сфокусироваться на ссылках, а не объектах. Это и есть главное смещение в приоритетах. Но я уже сказал, что это вопрос во многом религиозных и многие просто это не воспримут. Тут я помочь не смогу (и никто другой тоже).

S>>Забудь про прокси. Просто всем не угодишь и каждому надо объяснять на том спец. языке, который он знает.
WH>Я знаю много языков. В данном форуме наверное вобще нет людей которые знают только один язык.
WH>Так что можешь объяснять на любом. В том числе на псевдокоде.
WH>Покажи как все плохо при использованиее традиционных средств и как все хорошо при использовании твоего КОП. Ведь если ты понимаешь какие плюсы дает КОП то и пример тебе не составит труда привести.
WH>А если КОП ничего не дает то на кой черт он нужен? Зачем мне не нужные абстракции?

Так я привел примеры и показал недостатки прокси. Кроме того, я уже упомянул, что КОП это средство проксирования. Это средство виртуализации и отвязки от реальности. Это средство построения здания в котором живут объекты.

S>>Прокси это один из возможных способов опосредования, т.е. способ вставить посредника. В КОП главная цель состоит в описании общего и максимально универсальноо механизма доступа, т.е. надо научиться моделировать ссылки и их функции. Это позволяет отвязаться от реальности и работать в своем собственном виртуальном пространстве, где живут объекты. Теперь это не объекты в памяти или БД. Это объекты в некотором виртуальном пространстве, где у них свои обозначени, свой жизненный цикл и т.п. Но пользуемся мы ими совершенно так же как и всегда. По моему, более конкретно задачу уже не сформулировать. Если нет, то объясни что не ясно.
WH>Ну и чем это отличается от проксей реализующих некоторый интерфейс?

Прокси — это объект, а в КОП мы моделируем ссылки, которые объектами не являются. Таким образом, главная проблема (похоже, я начинаю понимать в чем трудность) в понимании отличия между ссылками и объектами. Ссылки это не менее важные сущности чем объекты, а потому заслуживают таких же средств поддержки. Еще раз:

Есть ссылки и есть объекты.
Объекты не есть ссылки, а ссылки не есть объекты.
Для описания объектов — ООП, для описания ссылок (вместе с объектами) — КОП.

В программе информацию передаются только с помощью ссылок и никак иначе — объекты находятся где-то неизвестно где и никто не знает что это такое.

WH>Метапрограммированием можно легко устранить всю ручную работу.
WH>Болие того практика показывает что работать прозрачно с объектами лежащими черт знает где вобще получается очень плохо. И никакие КОП тут не помогут.

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

WH>Вобще единственный способ построить надежную распределенную или даже просто многопоточную систему это асинхронная посылка сообщений.

Это уже другая тема. Можно синхронно, можно асинхронно.

WH>Любые другие методы создают массу проблем (хотя иногда они работают) и синтаксическим сахаром их не решить.

Нет тут никако сахара. Все в чистом виде без примесей как в аптеке. Сахар потом появится, когда модификации начнутся.

S>>Ну ясно зачем. Поскольку в метапрограммировании есть серьезные дефекты. С помощью АОП их попытались исправить. Причем довольно успешно (отсюда популярность). Но все равно даже в АОП остались серьезные проблемы, а потому ИМХО будущего у него нет.
WH>А вот с этого места по подробней пожалуйста.

Сожалению, но я не эксперт, и знакомился поверхностно. Просто у меня создалось такое впечатление. Возможо, неверное.

WH>Мне очень интересно знать какие фатальные недостатки есть у метапрограммирования и как их решает АОП.
WH>Ну и о недостатках АОП тоже хочется услышать.
WH>У меня есть свое мнение на этот счет вот только что-то мне подсказывает что оно не совпадает с твоим.

Описывать целевые точки (join points) внутри аспкта это принципиально неправильно (неествественно).

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

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

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

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

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

А теперь вот сомнения грызут и хочется что-то человеческое придумать.
WH>А меня уже давно ничего не грызет ибо я всех волков сам давно загрыз... Я просто пишу код и все. Есть сильно распиареное экстримальное программирование так вот я роботаю в сверх экстримальном режиме. Я просто пишу и постоянно рефокторю код. После чего пишу даже не тесты, а фиксаторы поведения системы для того чтобы можно было легко засечь изменение поведения.
WH>После чего перехожу к другой части системы.

И это называется правильный подход к программированию? А потом мучаться угрызениями совести за бесцельно написанные строки?

S>>Ты говоришь правильные вещи, но это детский сад (выделение интерфейсов и т.п.), т.е. хорошо для преподавания. Ну а правильного подхода не сущестует. Есть просто адекватные и неадекватные, умело применяемые или неумело и т.д. Я бы например начал проектирование системы с построения жилища для объектов, системы их обслуживания и поддержания в нормальном состоянии.
WH>Те с "правильного" подхода которого не существует.

Люблю диалектику, однако

А правильный подход у каждого свой.

S>>Описание уровня это сама первая и главная задача в проектировании. Здесь происходит разделение функций, ответственности, правил безопасности, формат обозначения объектов (ссылок), формат представления объектов и многое другое. В сложной системе основные функции сосредоточены на границах, а не в объектах (не в бизнес-логике). Немного преувеличивая большая система это и есть структура уровней — все остальное это уже мелочи.
WH>Те система ради системы? Мне кажется что тебе деньги не за это платят.
WH>Деньги платят за решение задач, а не за устраивание супер сложных границ системы.

Суперсложные границы существуют в предметной области, а нам надо просто это представить в виде программы. А для этого нужны адекватные средства.

S>>Кому как. Если получается без этого, то конечно не надо ничего искать нового. У меня например не получается, а потому я построил для себя новую теорию.
WH>А может нужно было просто научится использовать существующие инструменты?
WH>Они прекрасно работаю. А куда можно засунуть твой КОП вобще не понятно.

Куда можно засунуть это как раз понятно

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

S>>Ну это ясно, никто не спорит. КОП это инструмент, который позволяет автоматизировать определенные задачи и все. А неправильно его использовать никто не запретит. Можно также и без него все правильно сделать. Так, чтобы программировать в стиле ООП совершенно не нужен ОО язык.
WH>Так ты мне объясни какие преймущества дает КОП.
WH>С ООП все понятно. С функциональным программированием тоже. А вот чето дает КОП не понятно.

Он позволяет моделировать ссылки и виртуализировать представление объектов. Виртуализация позволяет отделить бизнес-логику (в объектах) от промежуточной и вспомогательной бодяги. В ООП это все будет перемешано.

S>>Нет, в КОП нет прокси. Я просто сделал сравнение для тех, кто больше ничего не знает. КОП позволяет моделировать ссылки и их функции.
WH>Зачем? Приведи пример.

См. выше.

Другие примеры:
Диагности при доступе к объектам из одного места (логи).
Транзакции (открыть при доступе, закрыть при выходе).
Персистенс (загрузить при доступе, сбросить обратно при выходе).
Удаленность (переслать запрос на др. комп и вернуть результат).
Собственный контейнер для объектов с нужными функциями поддержки жизни.
... (список бесконечен)

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

Ну как, впечатляет?

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

S>Другие примеры:
S>Диагности при доступе к объектам из одного места (логи).
S>Транзакции (открыть при доступе, закрыть при выходе).
S>Персистенс (загрузить при доступе, сбросить обратно при выходе).
S>Удаленность (переслать запрос на др. комп и вернуть результат).
S>Собственный контейнер для объектов с нужными функциями поддержки жизни.
S>... (список бесконечен)

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

S>Ну как, впечатляет?

Если знаком с метапрограммированием (и тем более с его помощью уже реализовывал подобные вещи) то не впечатляет.

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

INDIRECT OBJECT REPRESENTATION AND ACCESS BY MEANS OF CONCEPTS
http://conceptoriented.com/tmp/icsoft06-cop-draft.pdf

QUERY BY CONSTRAINT PROPAGATION IN THE CONCEPT-ORIENTED DATA MODEL
http://conceptoriented.com/tmp/icsoft06-com-draft.pdf

Последняя статья на любителя, это про концептно-ориентированную модель данных. КОП и КОМ развиваются параллельно, так что может быть интересно (на сайте есть более понятное введение).

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

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

B>>Ну сделай

 RGBProxy = lambda *args, **kw: Proxy (RGB(*args, **kw))

B>>Или даже
B>>

 
B>>class Proxy:
B>>    def __init__( self, subject ):
B>>        self.__subject = subject
B>>    def __getattr__( self, name ):
B>>        print "proxying ;)"
B>>        return getattr( self.__subject, name )  

B>>RGBWithoutProxy = RGB
B>>RGB = lambda *args, **kw: Proxy (RGBWithoutProxy(*args, **kw))

B>>rgb = RGB( 100, 192, 240 )
B>>print rgb.Red()
B>>

B>>Тогда потом можно спокойно использовать

B>>rgb = RGB( 100, 192, 240 )
B>>а будет подставляться прокси.

S>Верю. Но сколько для этого надо было написать кода! Отсюда ясно, что язык не предназначен для таких задач (хотя и может описать какие-то механизмы более или менее удобно). Это хороший пример реализации какого-то паттерна или приема без прямой языковой поддержки. Так можно было то же самое написать на ассемблере или Си, но это бы заняло еще больше строй кода.
1) С каких это пор 10 строк кода это много?
2) А нужна ли языковая поддержка для этого приема, или ему место в библиотеке?

Ну а теперь перетащи это дело в библиотеку, обзови это какой-нибудь функцией. Тогда это будет выглядеть, например, так:

class AbstractConcept:
    def __init__(self, propagate=True):
        self.propagate=propagate
    def accept(self, object): #which objects should be wrapped
        return type(object) is DOMNode
    def adapt(self, object):
        #навешивает адаптер
        return adapted_object
    def __methodhook__(self, object, method, *args, **kw):
        if self.propagate: 
            adapt_args = map(self.adapt, args)
            adapt_kw = adaptDict(self.adapt, kw)
            return getattr(object, method).__call__(adapt_args, adapt_kw)
        else:
            
            
class MethodHookConcept(AbstractConcept):
    def __init__(self, hooker):
        AbstractConcept.__init__(self, True)
        self.hooker = hooker
    def adapt(self, object):
        AbstractConcept.adapt(self)
    def __methodhook__(self, object, method, *args, **kw):
        AbstractConcept.
        hooker.pre(object, method, *args, **kw)  #пре-хук на вызов метода
        result = AbstractConcept.__methodhook(self, object, method, *args, **kw)
        hooker.post(object, method, result) #пост-хук на вызов метода
        return result

теперь после следующего:

concept = AOPConcept(hooker)
rgb = concept.adapt(htmlDocument)

начнет работать система по обеспечению перехвата вызова всех методов для узлов DOM какой-нибудь разбираемой HTML. Остальные HTML останутся не связанными.

Кстати, я тут сообразил, как в Java решаются твои задачи — разнообразные механизмы Adapter'ов и INodeAdapter в частности. Поэтому такой пример. Кто понял, о чем я, покивайте

Но честно говоря, все мои попытки написать фреймворки для различных моих программ на питоне заканчивались ничем — стандартные методы проще в использовании, чем мои фреймворки. Язык такой

S>>>Следующая, более важная причина. В КОП во время выполнения поддерживается иерархия объектов, а потому т.н. прокси может иметь несколько внутренних объектов (в его области), для которых он выдал ссылки. В этом смысле этот промежуточный объект это граница пространства через которую проходят запросы и где выполняются промежуточные действия (типа паспортного контроля на границе). Отсутствие иерархии это в КОП частный случай, когда ссылки не используются и мы приходим к ООП.

B>>Че, на те объекты тоже нужны прокси? Или автоматический проксификатор? Ну сделай, правда это чуточку посложнее будет.
B>>http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/496741

S>Немного сложнее это мягко сказано. Но идея в том, что проксификация часто имеет вложенный характер. S>Это уже вряд ли можно назвать прокси в чистом виде, но я и не применял этот термин, а говорил об опосредовании. Здесь ближе паттерн chain of responsibility
Конечно вложенный! Это очень просто реализуется. Просто я не вижу смысла писать больше программный код. Ты, по видимому, сам придумать такой не в состоянии. А зря, получилась бы отличная библиотечка.

S>... Обычный же подход говорит, что надо создать сперва объекты, а потом создавать для них посредников в виде прокси (хотя бы потому, что прокси без целевых объектов просто не могут быть созданы). Это принципиальное отличие, понимание которого необходимо (что первично, а что вторично).
Это еще что за бред? Ты кроме С++ на чем-нибудь программировал? Какие-нибудь большие системы писал?
То, что проксики ты никогда не писал, я уже понял.

S>>>Ну и я уже устал повторять, что с помощью прокси нельзя моделировать сами ссылки, т.е. их структуру и функции, что составляет как минимум половину всей программы.
B>>Да можно. Переименуй мой класс Proxy в класс Concept, добавь ему необходимые тебе методы, и будет тебе счастье!

S>Есть ли в Питоне передача объектов по значению?
S>Если как и в Яве нет, тогда и говорить не о чем, поскольку ссылка всегда передается только по значению.
S>Ссылка не имеет своей собственно ссылки и это ее отличие от объекта. Но даже если есть передача объектов по значению, как в С++, то сделать из таких объектов ссылки весьма сложно. Нужно очень сильно постараться, чтобы прилепить такого горбатого к стенке. Например, в С++ можно использовать шаблоны и smart pointers.
Ссылка на питоновский объект и есть твоя ссылка — передается по значению. А объекты передаются по ссылкам.

B>>Например, даже если мы напишем
S>>>

>>>>>> proxy = Proxy( rgb )
>>>>>> proxy.Green()
S>>>

S>>>то все равно наша ссылка это обычная системная ссылка.
B>>Ну да, потому что процессор это обычный системный процессор. Значит системная ссылка обязательно где-то будет! Ну и по логике вещей она будет указывать на этот прокси, который будет проверять границы так, как тебе нужно. Все это можно реализовать в любом языке с интроспекцией, даже в Java и C#. Просто на питоне эти действия будут более простыми, поскольку он ближе к чистому ООП. SmallTalk еще ближе, там это делается еще проще.

S>Ссылка может иметь любой формат и не должна быть объектом. Если ссылка является объектом, то это уже симулирование ссылки, что можно с большим или меньшим успехом сделать с помощью прокси. А я хочу иметь нормальные ссылки в моем собственном формате, а не объект, который ведет себя как ссылка. Объект это объект, а ссылка это ссылка. Это двойственные понятия и их функции в системе ортогональны (взаимно пересекаются). Например, я хочу определить свои толстые ссылки (но не прокси), чтобы далее их использовать как самые обычные системные ссылки. Зачем? Ну затем же, для чего Ява использует свой формат ссылок, а не адреса в памяти. Затем же, для чего ты используешь имена компов, а не их IP-адрес, затем же для чего ты используешь имя файла, а не его номер блока на диске. Я бы сказал, что все программирование сводится просто к разработке такой системы опосредвоаня. Это нужно, что отвязаться от реальности и добиться виртуальности. Виртуализация это другой популярный термин. Мы хотим работать в виртуальной системе координат, а быть привязаны к физической реальности. Например, зачем в процессорах ввели виртуальную адресацию? Ведь это только замедляет доступ, поскольку каждый раз процессор (менеджер памяти) должен пересчитывать где в физической памяти находится элемент. Правильно, для того, чтобы отвязаться от физической памяти, поскольку это придает гибкость. То же самое в программировании. КОП предназначено для разработки своей виртуальной системы обозначений к объектам и прозрачного доступа к ним. В отличие от других языков, где некоторые вещи также можно реализовать, это является первичной и главной целью этого подхода. Убедил?

B>>Подумай о том, что этот объект может быть не в системной куче, а где-нибудь в трудно доступном месте, куда даже лучшая зубная щетка не достает.
B>>Ну да, прокси должен доставать объект откуда надо. Например, между машинами, как в CORBA и DCOM.
B>>Для питона есть, например, такое: http://pyro.sourceforge.net/ (это аналог Java RMI)
B>>Но есть еще и такое: http://pybuild.sourceforge.net/pyinvoke.html
B>>В итоге ты абсолютно прозрачно работаешь с объектами, а они на самом деле могут быть на другой машине.

S>Совершенно верно, но все-таки это как раз то, что мы хотим избежать! Это ведь не поддержка на уровне языка, а просто библиотека или какой-то специальный механизм, заточенный под определенный вид задача (в данном случае под удаленные объекты). Такая поддержка существует уже десятки лет в самых разных формах: на уровне ОС, middleware, библиотек и др. штуковин.

S>Наша цель состоит в том, чтобы предоставить универсальные средства на уровне языка программирования. Например, что мне делать, если меня не устраивает Pyro, RMI или CORBA? Ведь это универсальные средства, которые м.б. либо слишком сложными либо слишком простыми, либо слишком небезопасными либо вообще делать не то что нужно. Пусть я хочу, чтобы в удаленное ссылке было еще одно поле с какой-то инфой. В этом смысле КОП как раз и дает языковые средства для описания произвольной системы обозначений обозначений объектов в программе.
Ну что, библиотеки для разных языков писать будем? Книжки выпускать, статьи для ламеров?
В АОП поступили именно так и теперь про них многие знают. Хотя АОП ровно настолько же парадигма, насколько и КОП — узкоприменимая и редко нужная вещь.
Да, и еще по поводу АОП, я никогда не использовал и не собираюсь использовать AspectJ, но тем не менее, всегда замечаю использование паттерна АОП — перехвата метода. Только он нужен. А синтаксический сахар АОП мне до лампочки.
А чтобы написать эту штуку, нужно сделать две вещи:
— рассказать, как было плохо без нее
— рассказать, как станет хорошо с ней.
Только тогда народ уверует. Проверено.
А позиция "а я вот тут просто подумал и изобрел красивую концепцию" — очень плохая. Нельзя так.

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

WH>>Не ясно зачем это нужно.
WH>>Что это дает?

S>Это я уже не в состоянии формально объяснить. Это все равно что пытаться объяснить зачем нужно ООП тому, кто всегда применял процедурное программирование. Т.е. что такое ООП он с трудом, но сможет понять, но зачем это нужно — никогда.
Не правда! К тому времени, когда я взялся за изучение ООП, я уже вполне неплохо владел процедурным программированием. И когда я увидел примерчик с полиморфным методом draw(), я сказал: "ОК. Во всём этом определённо есть смысл". То есть я увидел, что те задачи, с которыми в не-ООП приходилось мучиться, в ООП решаются легко и элегантно.

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

S>
S>Есть ссылки и есть объекты.
S>Объекты не есть ссылки, а ссылки не есть объекты.
S>Для описания объектов — ООП, для описания ссылок (вместе с объектами) — КОП.
S>
S>В программе информацию передаются только с помощью ссылок и никак иначе — объекты находятся где-то неизвестно где и никто не знает что это такое.
Есть объекты, есть ссылки, есть ссылки на ссылки, есть объекты, являющиеся коллекциями ссылок, есть ссылки на коллекции ссылок, ... и т.д.

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

Вопрос: а как же исключить возможнось появления таких копий? Самый простой и надёжный способ, который сразу же приходит в голову хоть ОО-, хоть процедурно-ориентированному программисту — это пропустить загрузку объектов через некий единый диспетчер, который уже знает, что загружено, а что — нет. Задача диспетчера — используя "родной" OID, загрузить объект (если он ещё не загружен) в ОП и вернуть "честную" ссылку. Но это такой заштатный наворотец, что он не достоин стать предметом статьи даже для ПТУшной многотиражки.

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

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

WH>>>Не ясно зачем это нужно.
WH>>>Что это дает?

S>>Это я уже не в состоянии формально объяснить. Это все равно что пытаться объяснить зачем нужно ООП тому, кто всегда применял процедурное программирование. Т.е. что такое ООП он с трудом, но сможет понять, но зачем это нужно — никогда.
V>Не правда! К тому времени, когда я взялся за изучение ООП, я уже вполне неплохо владел процедурным программированием. И когда я увидел примерчик с полиморфным методом draw(), я сказал: "ОК. Во всём этом определённо есть смысл". То есть я увидел, что те задачи, с которыми в не-ООП приходилось мучиться, в ООП решаются легко и элегантно.

Да, но к тому времени ООП уже развивался лет этак 10 или больше! Т.е. была уже сформирована база вот таких примеров и написаны книжки. (Я вовсе кстати не снимаю с себя ответственности, т.е. это не оправдание для меня, а просто я хочу чтобы Вы сделали скидку на самый начальный этап.)

V>Применительно же к КОП ни я, ни прочая уважаемая публика не могут понять, от какого же геморроя избавляет предложенная и так смачно названная, не побоюсь этого слова, парадигма.

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

S>>
S>>Есть ссылки и есть объекты.
S>>Объекты не есть ссылки, а ссылки не есть объекты.
S>>Для описания объектов — ООП, для описания ссылок (вместе с объектами) — КОП.
S>>
S>>В программе информацию передаются только с помощью ссылок и никак иначе — объекты находятся где-то неизвестно где и никто не знает что это такое.
V>Есть объекты, есть ссылки, есть ссылки на ссылки, есть объекты, являющиеся коллекциями ссылок, есть ссылки на коллекции ссылок, ... и т.д.

Нет. Сссылок на ссылки нет, есть только ссылки на объекты.

V>Объекты вообще передаются только с помощью OID.

Нет не правда. Нет такого слова OID. Объекты передаются с помощью ссылок, а что за ними стоит неизвестно (при использовании объектов). В этом суть ООП. Раньше (до ООП) мы тоже могли передавать информацию о расположении объектов, например, с помощью адреса в памяти. Но важная заслуга ООП состоит в том, что этот уровень был полностью закрыт и создана иллюзия прямого доступа по ссылке. А что внутри ссылки это уже не забота программиста.

V>В качестве OID в ран-тайме традиционно используется адрес в оперативной памяти.

Что такое рантайм? Что такое оперативная память? Нет таких слов. В ООП есть только ссылки и объекты. Может и пмяти нет, а может и рантайма нет. Это Вы сами придумали.

V>Это не только автоматически обеспечивает уникальность OID, но и позволяет организовать самый быстрый, какой только может быть, "доступ к телу" объекта.

Не согласен. За OID стоит очень сложный и крайне медленный механизм. Так они выдаются ОС, что занимает кучу времени. Выделенными объектами надо управлять и следить за распределением памяти. Процессору надо постоянно следить за безопасностью, чтобы кто-то не сунулся в чужой блок памяти. Менеджеру памяти надо при каждом доступе преобразоввывать его в физический адрес. И т.д. и т.п. Это все замедляет доступ, но преимущества окупаются. Идея КОП в том, что каждый может в своей программе построит такой же механизм.

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

Раз Вы видите эту проблему, значит Вы уже на полпути к КОП. Это действительно принципиальная проблема. Дело в том, что мы хотим манипулировать объектами в вирутальном пространстве, а не в памяти, на диске или в какой-то другой физической среде, которая дана нам свыше. КОП далет нам возможность разработать свои OID для собственных нужд. Даже, если мы не хотим их разрабатывают, КОП дает нам возможность эффективно разделить эти уровни, т.е. кто-то разработает средства представления и доступа, а другой уже логику самих объектов. Без их смешения. В КОП нет памяти и нет диска и нет удаленного компа. Там есть просто объекты, которые доступаютя по ссылками. Полная виртуализация.

V>Вопрос: а как же исключить возможнось появления таких копий? Самый простой и надёжный способ, который сразу же приходит в голову хоть ОО-, хоть процедурно-ориентированному программисту — это пропустить загрузку объектов через некий единый диспетчер, который уже знает, что загружено, а что — нет. Задача диспетчера — используя "родной" OID, загрузить объект (если он ещё не загружен) в ОП и вернуть "честную" ссылку. Но это такой заштатный наворотец, что он не достоин стать предметом статьи даже для ПТУшной многотиражки.

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

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

S>Да, но к тому времени ООП уже развивался лет этак 10 или больше! Т.е. была уже сформирована база вот таких примеров и написаны книжки. (Я вовсе кстати не снимаю с себя ответственности, т.е. это не оправдание для меня, а просто я хочу чтобы Вы сделали скидку на самый начальный этап.)

Всё зависит от того, каким образом рождается идея. Тут я вижу два возможных сценария.

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

2. Анализируем существующую теорию (технологию, парадигму и т.п.), находим в ней логическую нестыковку, и во всю глотку кричим: "Камрадос! Я знаю, от чего у вас всех геморрой и отсутствие счастья в личной жизни!". При этом есть ненулевая вероятность, что камрадосы не только не поверят, что у них геморрой именно по этой причине, но и не поверят, что эта логическая нестыковочка действительно является нестыковочкой. Что мы, по-видимому, и имеем удовольствие наблюдать в ветке "Концептно-ориентированное прораммирование (КОП)".
Именно при таком развитии событий мы и имеем проблемы с придумыванием примеров.

Желаю удачи в выдумывании убедительных иллюстративных примеров. Придумаете, заходите ещё.

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

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

S>>Да, но к тому времени ООП уже развивался лет этак 10 или больше! Т.е. была уже сформирована база вот таких примеров и написаны книжки. (Я вовсе кстати не снимаю с себя ответственности, т.е. это не оправдание для меня, а просто я хочу чтобы Вы сделали скидку на самый начальный этап.)

V>Всё зависит от того, каким образом рождается идея. Тут я вижу два возможных сценария.

Думаю, что от происхождения идеи ничего не зависит. Важна просто сама идея.

V>1. В ходе решения конкретных задач выясняется, что существующие подходы рождают только некрасивые/трудоёмкие/неэффективные решения. Например, у меня вот это родилось из размышлений о том, почему в серьёзных бизнес-системах (всякое там ERP, CRM, бухгалтерия, склад и т.д.) полноценный ОО-подход при проектировании бизнес-логики не применяется. На низком (технологическом) уровне — сплошь и рядом, со всеми наворотами из GoF, а на высоком — облом полный. Ну не проектируется иерархия классов, хоть ты лопни! И это несмотря на то, что полиморфизьм нужен как воздух т.к. без него получается грандиозный copy/paste, рыхлость и кривизна.
V>При таком сценарии не нужно даже напрягаться по части примеров, т.к. все теоретические выверты оказываются рождёнными в обдумывании примеров.
V>Вариант этого же сценария — находим пласт задач, которые вообще никто не берётся решать, и придумываем новую науку. Но это — вообще крутизна, которая случается очень редко.

V>2. Анализируем существующую теорию (технологию, парадигму и т.п.), находим в ней логическую нестыковку, и во всю глотку кричим: "Камрадос! Я знаю, от чего у вас всех геморрой и отсутствие счастья в личной жизни!". При этом есть ненулевая вероятность, что камрадосы не только не поверят, что у них геморрой именно по этой причине, но и не поверят, что эта логическая нестыковочка действительно является нестыковочкой. Что мы, по-видимому, и имеем удовольствие наблюдать в ветке "Концептно-ориентированное прораммирование (КОП)".
V>Именно при таком развитии событий мы и имеем проблемы с придумыванием примеров.

Странно, почему тогда нет примеров, если КОП возникла как раз по первому варианту развития? Неувязка, однако. Теорией программирования я никогда не занимался, а существующие направления в программировании изучал только для сравнения с альтернативными решениями.

V>Желаю удачи в выдумывании убедительных иллюстративных примеров. Придумаете, заходите ещё.

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

От:	eao197	http://eao197.blogspot.com
Дата:	01.08.06 14:34
Оценка:

	От:	Cyberax
	Дата:	01.08.06 15:00
	Оценка:	+1

От:	savinov	https://github.com/asavinov
Дата:	01.08.06 15:05
Оценка:

От:	eao197	http://eao197.blogspot.com
Дата:	01.08.06 15:09
Оценка:

От:	savinov	https://github.com/asavinov
Дата:	01.08.06 15:22
Оценка:

От:	buriy	http://www.buriy.com/
Дата:	02.08.06 06:13
Оценка:	7 (1)

От:	Voblin	http://maslyaew.narod.ru/
Дата:	02.08.06 08:03
Оценка: