Re[3]: Ответ
От: vdimas Россия  
Дата: 28.01.04 10:05
Оценка:
Здравствуйте, VladD2, Вы писали:


VD>Пьеса о создании супер рэплэйсилке

[кусь]
VD>Занавес...

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

(Польза-то от коллективизации понятна... не понятно, что такое коллективизация...)

Ведь речь, в конечном итоге, должна идти о ПОЛЕЗНОСТИ этой технологии в наших современных реалиях. Т.е. берем немаленький проект с приличным числом девелоперов, убеждаем их в полезности еще одной фишки (предположим), которая дополняет наше мышление и добавляет нам счастья, не опровергая предыдущий опыт, и теперь, после того как все ответили: "ну давай!", что им дать-то?

(в той статье было перечисление разработок на тему АОП, из них ничего, относящегося к дотнет, я пока не рискну предложить для серьезной промышленной разработки, может у кого-то есть другая информация?)
Re[17]: Ответ
От: IT Россия linq2db.com
Дата: 28.01.04 15:41
Оценка: 1 (1)
Здравствуйте, Batiskaf, Вы писали:

B>Вот давай я буду этой бестолковой операционисткой а ты будешь этим пионером, или наоборот, если хочешь .Net реализация АОП тебе не нравится, да?


Да её там почти нет.

B>Ну а AspectJ нравится?


Я такого не говорил.

B>Раз уж заговорили о количестве траха, то для сравнения я возьму тот же пример из статьи, все тот же Point, Line, DisplayUpdateAspect и попытаюсь выразить это на плюсах, а потом сравним со статьей.


[nice code skipped]

Это всё извращения на тему как сэмулировать AOP любыми доступными средствами. Я в своё время, когда меня заставили вернуться опять на C с C++, писал что-то типа такого:

struct MyObject
{
    int x;
    int y;
};

void MyMethod(MyObject *this)
{
}


И даже с успехом эмулировал виртуальные функции. Но называть этот изврат ООП у меня как-то язык не поворачивался.
То же самое сейчас ты демонстрируешь на С++. То же самое с RealProxy. То же самое я делаю в RFD с абстрактными классами. Всё это показывает лишь то, что проблема назрела и существует необходимость реализации AOP нормальными языковыми средствами.

В твоём коде я вижу как минимум две проблемы.

1. У тебя всё построено на виртуальных методах, следовательно, твои аспекты применимы только к ним.
2. Пользователь может создать и использовать просто Point, а не DisplayPoint. И тогда к нему придут пионеры.
3. Комбинирование аспектов в твоём случае приводит к появлению нового аспекта, реализующего эту комбинацию. Соответственно, там где нужно будет написать 2 аспекта тебе придётся делать 3, там где 3 — 7 и т.д. Запутаться не долго. При этом поймать ошибку будет непросто.

B>Количество вариантов как ты сам понимаешь ростет, а количество телодвижений за счет повторного использования моих же "аспектов" гораздо выше. Цель применения аспектов лежит в том что бы делать менее связанный, декларативный код, в примере из статьи я этого не вижу. Вот как я могу применить aspect DisplayUpdating в другом месте для другой компоненты в AspectJ, например для 3DPoint??? Они же все hardcoded, там четко прописано к какому методу какого типа все это привязывается, кроме всего нужно уметь понять что тут относится к сетап коду этих аспектов, а что к сквозной функциональности.


Давай не будем пытаться сравнивать академические исследования с коммерческими продуктами. AspectJ — это всего лишь попытки найти правильный путь. Мне тоже не нравится то, что ты называешь hardcoded. Но и ООП не начался с C++, до этого было много других языков, на которых пытались выразить идеи ООП. То что в AspectJ используется пока только 'call' совсем не означает, что мы не можем использовать что-нибудь типа 'attribute', 'baseclass', 'interface' или их комбинации.

B>А что касательно наследования таких аспектов???


Не вижу необходимости в наследовании Аспекты должны легко комбинироваться, а не наследоваться. Поэтому, например, гораздо важнее может оказаться механизм очерёдности их применения, что-то типа приоритетности.
Если нам не помогут, то мы тоже никого не пощадим.
Re[13]: Ответ
От: IT Россия linq2db.com
Дата: 28.01.04 16:01
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Насчет валидации... Согласно собственной практике валидации можно классифицировать. Некоторые типы валидаций, напр. допустимые значения полей, заданные некоей формулой, легко записываются в виде аттрибутов полей и обрабатываются на клиенте. И нет смысла встраивать подобного рода валидацию в бизнес-сущности, т.к. валидация, не требующая наличия других каких-то других БО или даже доступа в БД легко описывается аттрибутами.


Чего там квалифицировать. Валидация должна проводиться везде и всегда. Естественно, что при этом нужно учитывать целесообразность затрат на валидацию. Например, если валидация требует обращения к БД, то делать эту её часть из UI нецелосообразно. Но это совсем не означает, что БЛ должен полагаться на то, что что-то провалидировано на UI и не проводить той же самой повторной валидации на сервере.

V>Более сложная валидация может происходить в имплементации самого БО, см. внимательней след. пункт.


Точно.

V>Возвращаясь к бизнес-сущностям, далеко не все виды валидаций да и просто каких-то осмысленных действий можно выполнить "силами" самой бизнес-сущности, в отрыве от других сущностей (которых может не быть в момент обработки в месте этой обработки — скажем на клиеннте), т.е. от них как от таковых (сущностей, "гоняемых" по значению, а не по ссылке) давно отказались.


Можно об этом поподробней, почему отказались?

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


Сдаётся мне, что ноги вашей архитектуры растут из COM. Такое ощущение, что вы сделали COM Application Model, затем нарвались на тормоза (а это действительно самый неудачный способ применения ремоутинга) и начали изобретать свои собственные велосипеды. Не проще было бы с самого начала перейти на stateless модель, либо уж если оставлять stateful, то взять более отработанные решения типа клонирования.

V>Хоть это все вероятно и выглядит мудренно, зато в итоге порождает совсем немного целевого бизнес-кода, именно фреймворк берет на себя многие тонкости по организации передачи данных м/у слоями и кешированием данных. (Да, много чего есть в .net, но вот идеологию immediate or lazzy update пришлось конопатить ручками, хотя, вроде, очевидная весчь...)


Ну понятно, без хорошего фрейсворка тут не обойтись

V>Опять же (про бизнес-сущности), оперирование бизнес-сущностями требует ОСМЫСЛЕННОСТИ кода клиента. Хех, кому это надо? На клиента просто приходят ресурсы форм и описание биндинга полей. Что делается на клиенте, так это то, что и должно там делаться: drag&drop, например, и пр. клиентские фишки. (Утрирую, бывает, очень редко, но бывает, что осмысленный код приходится накидывать и на клиенте)


А что понимается под описанием баиндинга полей?

V>Для нормальной работы всей этой кухни, разумеется, пришлось отнаследоваться от всех потенциально требуемых data-aware контролов, для работы в подобной системе, зато формы можно плодить как грибы (накидал ресурсы и ЗАБЫЛ), а разработчик серверной части (т.е. БО-части) вообще практически не задумывается от том, как и кто создает или работает с его объектами...


Вы свой баиндинг изобрели или просто что-то расширили?

V>В общем, есть что пообсуждать.


Всегда
Если нам не помогут, то мы тоже никого не пощадим.
Re[18]: Ответ
От: naje  
Дата: 28.01.04 16:26
Оценка:
Здравствуйте, IT, Вы писали:

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



IT>
IT>struct MyObject
IT>{
IT>    int x;
IT>    int y;
IT>};

IT>void MyMethod(MyObject *this)
IT>{
IT>}
IT>


Чтоб на С ООП эмулировать нужно метод назвать как-то так MyObject_MyMethod(MyObject *this) .
А вобще в С++ техника определения методов класса не членами класса, дает очень много замечательных эффектов, оставаясь ООП при этом.
Re[18]: Ответ
От: Batiskaf Израиль http://www.mult.ru/
Дата: 28.01.04 16:48
Оценка:
Здравствуйте, IT, Вы писали:

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


B>>Вот давай я буду этой бестолковой операционисткой а ты будешь этим пионером, или наоборот, если хочешь .Net реализация АОП тебе не нравится, да?


IT>Да её там почти нет.

Хоть это и имеет отношение другому спору, но Мика таки своего добился

B>>Раз уж заговорили о количестве траха, то для сравнения я возьму тот же пример из статьи, все тот же Point, Line, DisplayUpdateAspect и попытаюсь выразить это на плюсах, а потом сравним со статьей.



IT>Это всё извращения на тему как сэмулировать AOP любыми доступными средствами. Я в своё время, когда меня заставили вернуться опять на C с C++, писал что-то типа такого:


IT>
IT>struct MyObject
IT>{
IT>    int x;
IT>    int y;
IT>};

IT>void MyMethod(MyObject *this)
IT>{
IT>}
IT>


IT>И даже с успехом эмулировал виртуальные функции. Но называть этот изврат ООП у меня как-то язык не поворачивался.

IT>То же самое сейчас ты демонстрируешь на С++. То же самое с RealProxy. То же самое я делаю в RFD с абстрактными классами. Всё это показывает лишь то, что проблема назрела и существует необходимость реализации AOP нормальными языковыми средствами.
Ты забыл отвести 4 байта под виртуальную таблицу Помнится в самом начале существования форума .Net на РСДН я показывал одному джависту что полиморфизм существовал задолго до появления объектно ориентированных языков, что кстати очередной раз подтверждает мысль о том, что при достаточной развитости существующих языков можно безболезненно эмулировать современные парадигмы

IT>В твоём коде я вижу как минимум две проблемы.


IT>1. У тебя всё построено на виртуальных методах, следовательно, твои аспекты применимы только к ним.

Для начала методы в AspectJ так же как бы виртуальные, если только это не final. АОП в .Net ты сам только что зачеркнул. Что же касается С++, то я с легкостью могу применять этот способ и для не виртуальных методов и работать с обьектами по значению, что очень гладко сойдется с парадигмой статического дженерик полиморфизма, но это уже другая история.

IT>2. Пользователь может создать и использовать просто Point, а не DisplayPoint. И тогда к нему придут пионеры.

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

IT>3. Комбинирование аспектов в твоём случае приводит к появлению нового аспекта, реализующего эту комбинацию. Соответственно, там где нужно будет написать 2 аспекта тебе придётся делать 3, там где 3 — 7 и т.д. Запутаться не долго. При этом поймать ошибку будет непросто.

Мне кажется я достаточно ясно показал применимость аспекта для Point в рамках 3DPoint, отличный пример повторного использования, не очень понял на что ты намекаешь... Учитывая декларативные особенности языка, этот аспект ты можешь натянуть на другой тип, у которого совпадают имена и прототипы инспектируемых функций (методы setX\setY могут быть не только у точек, ведь правда), это тоже приятная особенность.

B>>Количество вариантов как ты сам понимаешь ростет, а количество телодвижений за счет повторного использования моих же "аспектов" гораздо меньше. Цель применения аспектов лежит в том что бы делать менее связанный, декларативный код, в примере из статьи я этого не вижу. Вот как я могу применить aspect DisplayUpdating в другом месте для другой компоненты в AspectJ, например для 3DPoint??? Они же все hardcoded, там четко прописано к какому методу какого типа все это привязывается, кроме всего нужно уметь понять что тут относится к сетап коду этих аспектов, а что к сквозной функциональности.


IT>Давай не будем пытаться сравнивать академические исследования с коммерческими продуктами. AspectJ — это всего лишь попытки найти правильный путь. Мне тоже не нравится то, что ты называешь hardcoded. Но и ООП не начался с C++, до этого было много других языков, на которых пытались выразить идеи ООП. То что в AspectJ используется пока только 'call' совсем не означает, что мы не можем использовать что-нибудь типа 'attribute', 'baseclass', 'interface' или их комбинации.

Сравнивать я не собирался, ты же сам начал говорить о количестве трахов... Я пытаюсь применить существующие средства, работать нужно сейчас, и выбор делать так же сейчас. И когда еще эти саны с микрософтами снизойдут до наших нужд и решатся привести это в надлежащий вид, сколько споров было про необходимость дженериков в яве к примеру, по началу категорическти не желали этого делать, ведь помнишь же, сколько говорильни было о вреде дженериков и множественного наследования. Наигрались в System.out.println, пошли задачи круче.

B>>А что касательно наследования таких аспектов???


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


Тогда может стоит уже прямо сейчас позаботиться о создании аспектов для аспектов... К примеру супер аспекты, которые будут перемешивать все аспекты в кучу, и выделять из них сквозную функциональность, но для этого нужно будет сначала наваять километры аспектных имплементаций в коде, что бы понять что разница между аспектом и классом неожиданно исчезла, ну а потом ждать очередного языкового решения для всех наших бед
Вобщем пора прекращать споры, надоело все это
Will I live tomorrow? Well I just can't say
But I know for sure — I don't live today.
Jimi Hendrix.
Re[19]: Ответ
От: IT Россия linq2db.com
Дата: 28.01.04 17:21
Оценка:
Здравствуйте, Batiskaf, Вы писали:

B>Ты забыл отвести 4 байта под виртуальную таблицу


Не забыл. В этом "классе" нет виртуальных методов, поэтому ему виртуальная таблица не нужна

IT>>1. У тебя всё построено на виртуальных методах, следовательно, твои аспекты применимы только к ним.

B>Для начала методы в AspectJ так же как бы виртуальные, если только это не final.

Здесь ключевое слово 'если'.

B>АОП в .Net ты сам только что зачеркнул.


Ты имеешь ввиду чистый AOP или попытки его эмуляции? Чистого AOP нет ни C++, ни в .NET. Я бы даже сказал, что он пока вообще ещё не сформировался и находится в стадии исследований. То что мы о нём тут рассуждаем, говорит лишь о том, что из чисто академических исследований AOP переходит в стадию исследований технического применения. Вот и всё.

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


И потеряешь полиморфность объекта. Кстати, ещё одна проблема:

4. Фактически, ты пораждаешь два класса, когда в AOP можно вполне обойтись одним.

IT>>2. Пользователь может создать и использовать просто Point, а не DisplayPoint. И тогда к нему придут пионеры.

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

Point p = new Point();


Вот чего стоит вся твоя фабрика. Была фабрика и нет фабрики.

IT>>3. Комбинирование аспектов в твоём случае приводит к появлению нового аспекта, реализующего эту комбинацию. Соответственно, там где нужно будет написать 2 аспекта тебе придётся делать 3, там где 3 — 7 и т.д. Запутаться не долго. При этом поймать ошибку будет непросто.

B>Мне кажется я достаточно ясно показал применимость аспекта для Point в рамках 3DPoint, отличный пример повторного использования, не очень понял на что ты намекаешь... Учитывая декларативные особенности языка, этот аспект ты можешь натянуть на другой тип, у которого совпадают имена и прототипы инспектируемых функций (методы setX\setY могут быть не только у точек, ведь правда), это тоже приятная особенность.

Я намекаю на то, что если у тебя есть аспект A и аспект B, то для того чтобы их оба применить к объекту, тебе придётся написать аспект C, который будет являтся комбинацией первых двух. Короче, к одному типу объекта ты можешь применить только один аспект.

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


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

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


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


Зачем что-то перемешивать? Один аспект накладывается на целевой объект за другим, какие проблемы. Они вообще ничего друг о друге знать не должны.
Если нам не помогут, то мы тоже никого не пощадим.
Re[14]: Ответ
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 29.01.04 03:13
Оценка: 14 (1)
Здравствуйте, Merle, Вы писали:

M>И не совсем ясно с чем спорил ГВ, в своем изначальном постинге. Я так и не понял, он против АОП "в принцие" или нет?

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

А с IT сцепились (да и не сцепились-то, а просто беседуем) из-за конкретного примера, а не АОП вообще.

M>Впрочем один я кажется помню, неконтролируемое вмешательство в логику поведения объекта извне, я прав?

Да, ты совершенно прав. А чтобы вспомнить все — перечитай исходный пост.

Ещё мне кажется не слишком хорошей идея построения обобщений на основе имён методов, да и вообще — использование только методов как некоторых "осей", на которые нанизываются аспекты. Впрочем, это ко всему АОП не относится, это уже реализации конкретных инструментов.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[20]: Ответ
От: Batiskaf Израиль http://www.mult.ru/
Дата: 29.01.04 11:11
Оценка:
Здравствуйте, IT, Вы писали:

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


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

IT>>>1. У тебя всё построено на виртуальных методах, следовательно, твои аспекты применимы только к ним.

B>>Для начала методы в AspectJ так же как бы виртуальные, если только это не final.

IT>Здесь ключевое слово 'если'.


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

B>>АОП в .Net ты сам только что зачеркнул.


IT>Ты имеешь ввиду чистый AOP или попытки его эмуляции? Чистого AOP нет ни C++, ни в .NET. Я бы даже сказал, что он пока вообще ещё не сформировался и находится в стадии исследований. То что мы о нём тут рассуждаем, говорит лишь о том, что из чисто академических исследований AOP переходит в стадию исследований технического применения. Вот и всё.


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


IT>И потеряешь полиморфность объекта. Кстати, ещё одна проблема:

Ты же только что упрекал меня в том, что мои аспекты насаживаются только на вируальные методы? Если я не ошибаюсь, в До диез других средств для реализации полиморфизма пока что не существует... Просто в плюсах есть еще одна форма полиморфизма, не менее мощная, тот же vector<T> это еще какой полиморфизм, особенно когда ты меняешь один typedef и весь твой алгоритм приобретает другую предметную область.

IT>4. Фактически, ты пораждаешь два класса, когда в AOP можно вполне обойтись одним.

Ок, сначала ты все таки прийдешь к пониманию того, что аспект это то же класс, ну а потом станет понятно что у аспектов, которые насаживаются на разные классы может быть общая функциональность,инициализация к примеру, как в моем примере у аспектов 3DPointLockAspec и PointLockAspect есть общая функциональность LockAspectBase<Base>. Так что все дороги ведут к наследованию аспектов, иначе будет дублирование кода. И чем в таком случае аспект отличается от класса???

IT>>>2. Пользователь может создать и использовать просто Point, а не DisplayPoint. И тогда к нему придут пионеры.

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

IT>
IT>Point p = new Point();
IT>


IT>Вот чего стоит вся твоя фабрика. Была фабрика и нет фабрики.


IT>>>3. Комбинирование аспектов в твоём случае приводит к появлению нового аспекта, реализующего эту комбинацию. Соответственно, там где нужно будет написать 2 аспекта тебе придётся делать 3, там где 3 — 7 и т.д. Запутаться не долго. При этом поймать ошибку будет непросто.

B>>Мне кажется я достаточно ясно показал применимость аспекта для Point в рамках 3DPoint, отличный пример повторного использования, не очень понял на что ты намекаешь... Учитывая декларативные особенности языка, этот аспект ты можешь натянуть на другой тип, у которого совпадают имена и прототипы инспектируемых функций (методы setX\setY могут быть не только у точек, ведь правда), это тоже приятная особенность.

IT>Я намекаю на то, что если у тебя есть аспект A и аспект B, то для того чтобы их оба применить к объекту, тебе придётся написать аспект C, который будет являтся комбинацией первых двух. Короче, к одному типу объекта ты можешь применить только один аспект.


Ок, подитожим 2 и 3 пункты... Давай подсчитаем количество твоих телодвижений на С диез:

Сначала у тебя есть Point:


class PointBase
{
    //base functional
    virtualvoid setX(...);
    ...
    ...
};


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

теперь выводим точку с аспектом:


class UIPoint : public PointBase
{
virtual    void setX(...)
{
    base.setX(...);
}
...
...
};

aspect UIPointDisplayAspect
{
    call UIPoint.setX || bla bla
};


захотелось иметь точки с дисплей аспектом и мютексами одновременно — благо наследуя от UIPoint ты наследуешь и его аспект, но наследоваться тебе нужно по любому, потому что тебе же нужно поставить фильтр на конкретные вызова конкретного типа ( call ConcreteType.concreteMethodName ), та же ситуация с идеей аттрибутов, тебе же нужно его вешать на конкретный метод, значит обьявить тебе его в наследнике прийдется, и имплементация его будет конечно же base.methodName.


class UIPointWithLock : public UIPoint
{
virtual    void setX(...)
{
    base.setX(...);
}
...
...
};

aspect UIPointLockAspect
{
    call UIPointWithLock.setX || bla bla
}


Либо нужно выдумывать динамический байнд атрибутов( аспектов ) на твои типы, типа сказать что с классом Point примени сейчас аспект номер один а теперь аспект номер 2 + номер 5. Но в таком случае создание инстанса класса уже не будет выглядеть так празднично как ты показывал:

вместо

Point p = new Point();


должна быть какая то конструкция что бы указать комбинацию аспектов, применительно к базовому классу, в лучшем случае как то так:

uses UIPointLockAspect
{
    Point p = new Point();
}

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

Что касается комбинирования "аспектов" в моем случае, то хотелось бы устранить недопонимание, для того что бы создать UIPointWithLock я должен определить класс PointBase, и два аспекта, которые надеваются один на другой совершенно без ограничений, по принципу:


struct  Type
{
    virtual void F1()
    {    }
};

template<typename Base>
struct Aspect1 : public Base
{
    virtual void F1()
    {
        //aspect operations
        Base::F1();
    }    
};

template<typename Base>
struct Aspect2 : public Base
{
    virtual void F1()
    {
        //aspect operations
        Base::F1();
    }    
};

typedef    Aspect1<Type>    Type1;
typedef    Aspect2<Type>    Type2;
typedef    Aspect1<Type2>    Type3;
typedef    Aspect3<Type3>    Type4;
....

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

Мне кажется самое время подвести черту под этим спором, АОП пока что ценна исключительно идеологически, применять это можно и нужно существующими средствами, думаю что после прочтения этой скандальной темы у многих изменятся требования к этим средствам.
Will I live tomorrow? Well I just can't say
But I know for sure — I don't live today.
Jimi Hendrix.
Re[3]: Статья про АОП
От: mSerg Украина  
Дата: 29.01.04 14:58
Оценка:
Здравствуйте, Miem, Вы писали:

[Skipped]

http://msdn.microsoft.com/msdnmag/issues/02/03/aop/
WBR, Serg Matskov
Re[21]: Ответ
От: IT Россия linq2db.com
Дата: 30.01.04 03:37
Оценка:
Здравствуйте, Batiskaf, Вы писали:

B>Не желаю я продолжать это ненужный спор...




IT>>>>1. У тебя всё построено на виртуальных методах, следовательно, твои аспекты применимы только к ним.

B>>>Для начала методы в AspectJ так же как бы виртуальные, если только это не final.

IT>>Здесь ключевое слово 'если'.


B>Интересно, а не виртуальными ли станут методы этого же Point, если ты решишь завести несколько имплементаций, например точку с обновлением экрана и точку как логическую координату...


Давай выйдем из рамок твоего примера и посмотрим ширше. Так ли уж редки не виртуальные методы? В БЛ они сплошь и рядом.

IT>>И потеряешь полиморфность объекта. Кстати, ещё одна проблема:

B>Ты же только что упрекал меня в том, что мои аспекты насаживаются только на вируальные методы?

Я тебя упрекал за негибкость дизайна, а не за виртуальные методы.

IT>>4. Фактически, ты пораждаешь два класса, когда в AOP можно вполне обойтись одним.

B>Ок, сначала ты все таки прийдешь к пониманию того, что аспект это то же класс, ну а потом станет понятно что у аспектов, которые насаживаются на разные классы может быть общая функциональность,инициализация к примеру, как в моем примере у аспектов 3DPointLockAspec и PointLockAspect есть общая функциональность LockAspectBase<Base>. Так что все дороги ведут к наследованию аспектов, иначе будет дублирование кода. И чем в таком случае аспект отличается от класса???

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

IT>>Я намекаю на то, что если у тебя есть аспект A и аспект B, то для того чтобы их оба применить к объекту, тебе придётся написать аспект C, который будет являтся комбинацией первых двух. Короче, к одному типу объекта ты можешь применить только один аспект.


B>Ок, подитожим 2 и 3 пункты... Давай подсчитаем количество твоих телодвижений на С диез:


[skip]

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


О! Вот ты уже и думаешь в правильном направлении, нужен развитый механизм применения аспектов и всё. После этого все твои дальнейшие рассуждения становяться излишними

B>Либо нужно выдумывать динамический байнд атрибутов( аспектов ) на твои типы, типа сказать что с классом Point примени сейчас аспект номер один а теперь аспект номер 2 + номер 5. Но в таком случае создание инстанса класса уже не будет выглядеть так празднично как ты показывал:


При чём тут создание инстанса? Ты опять сам ответил на свой вопрос — шарповские атрибуты почти идеальный способ указания к чему применять, а к чему не применять атрибуты.

B>Что касается комбинирования "аспектов" в моем случае, то хотелось бы устранить недопонимание, для того что бы создать UIPointWithLock я должен определить класс PointBase, и два аспекта, которые надеваются один на другой совершенно без ограничений, по принципу:


B>
B>typedef    Aspect1<Type>    Type1;
B>typedef    Aspect2<Type>    Type2;
B>typedef    Aspect1<Type2>    Type3;
B>typedef    Aspect3<Type3>    Type4;
B>....
B>


Ну сколько можно повторять У этого решения есть один серьёзный недостаток. Мне никто не мешает использовать Type напрямую. Если для тебя это не проблема, то для меня проблема и довольно большая. Я сегодня потратил пол часа на то, чтобы выяснить, что один тупой китаец использовал вот такой вот Type вместо TypeProxy. А стоять постоянно рядом с линейкой и... "объяснять ему каждый раз где и в чём он не прав" у меня нет никакого желания. Мне проще было бы сделать так, что бы он просто физически не мог ошибиться.

B>Теперь понятно что ограничений нет ни каких, а так же прекрасно видно кто больше должен ваять классов и аспектов, вся фишка в том, что слово typedef умеет порождать тип из предложенных шаблонов, в AspectJ таких конструкций к сожалению пока что нет...


Ну, во-первых, typedef никаких новых типов не порождает, элиас он и в африке элиас. А, во-вторых, мы не обсуждаем зедсь конкретную реализацию AOP, каковой является AspectJ.

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


Я уже говорил, что выражение AOP существующим средствами — это всё равно что эмулировать OOP на голом C. Это делать можно и даже нужно, даже Страуструп начинал с препроцессора, который назывался C with classes, но настоящим ООП языком C от этого так и не стал.

Если же говорить о тех академических языках, которые сейчас реализуют AOP, то в них невооружённым взглядом видно как минимум две больших проблемы:

1. Слабые средства для описания применения атрибута к конкретному классу/методу.
2. Полное отсутствие средств работы с метадатой компилируемого кода.

Если найти красивые решения для этих проблем, то реализация того же C# with aspects представляется не такой уж неосуществимой задачей
Если нам не помогут, то мы тоже никого не пощадим.
Re[22]: Ответ
От: Sinclair Россия https://github.com/evilguest/
Дата: 30.01.04 13:32
Оценка:
Здравствуйте, IT, Вы писали:

IT>Если найти красивые решения для этих проблем, то реализация того же C# with aspects представляется не такой уж неосуществимой задачей

Ну так велком ту здесь!
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[23]: Ответ
От: IT Россия linq2db.com
Дата: 30.01.04 14:31
Оценка:
Здравствуйте, Sinclair, Вы писали:

IT>>Если найти красивые решения для этих проблем, то реализация того же C# with aspects представляется не такой уж неосуществимой задачей

S>Ну так велком ту здесь!

Всё под контролем. Пусть там сначала мужики бурьян порубят, площадку спланируют, котлован выроют и фундамент зальют
Если нам не помогут, то мы тоже никого не пощадим.
Re[24]: Ответ
От: VladD2 Российская Империя www.nemerle.org
Дата: 30.01.04 16:19
Оценка:
Здравствуйте, IT, Вы писали:

IT>Всё под контролем. Пусть там сначала мужики бурьян порубят, площадку спланируют, котлован выроют и фундамент зальют


Так эта... ужо. Порубили, спланировали... даже альфа парсера пашет.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[25]: Ответ
От: Sinclair Россия https://github.com/evilguest/
Дата: 30.01.04 17:32
Оценка: :)
Здравствуйте, VladD2, Вы писали:
VD>Так эта... ужо. Порубили, спланировали... даже альфа парсера пашет.
Это вы пока котлован роете. А вот как начнете обсуждение, в какую сторону расширять и углублять C# — вот тут-то и пойдет заливка фундамента. Кровью и слюнями .
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[26]: Ответ
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 30.01.04 21:34
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Это вы пока котлован роете. А вот как начнете обсуждение, в какую сторону расширять и углублять C# — вот тут-то и пойдет заливка фундамента. Кровью и слюнями .


Видишь ли какое дело — улучшение шарпа дело десятое. Пока задача номер один — создание "синтаксического препроцессора". А уж на основе него будут реализовываться и расширения шарпа и АОП и много чего еще.
... << RSDN@Home 1.1.3 beta 1 (Win32NT 5.1.2600.0) >>
AVK Blog
Бардак ещё не аргумент
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 31.01.04 23:54
Оценка: 4 (1)
Здравствуйте, IT, Вы писали:

Вобщем, IT, мой пост поделен на две части: комментарии к твоему письму и некоторые выводы.

Сначала: комментарии.



IT>>>Небольшие изменения тут, небольшие там и вот перед нами каша из логики и вспомогательного кода.
ГВ>>Ну, Игорь, это уже отдаёт пионерством: "эта дорога неверна, мы срочно побежим другой". А чтобы не было каши надо чаще думать, чем работать. Помогает, проверено.

IT>Думать и работать — это аргументы в пользу бедных, будешь эту лапшу своему начальству вешать. Расскажешь ему, что вот там на RSDN есть такой дурачёк IT, нифига в этой жизни не понимает, а вот я, Геннадий Васильев, фишку очень даже секу

Что-то я не понял выделенной фразы. Причём тут бедность или богатство? А... кажется дошло. Это только бедные думают и работают... Хм. А богатые что делают?

IT>В техническом же форуме всё это называется одним ёмким словом — демагогия.

Ну в данный момент мы с тобой в форуме "Философия программирования", а философы — они народ сложный, так что уж — извини.

ГВ>>А если без ёрничанья, то перспектива получения каши если не из БЛ+вспомогатльный код, то уж внутри вспомогательного кода или внутри самой БЛ — по любому остаётся.


IT>Okey, хоть ты и не любишь песнь про большие проекты, но всё же, позволь, я тебе её спою, т.к. из всей нашей предыдущей дискуссии, я делаю вполне очевидный вывод, что ты слабо представляешь себе что это такое.

Грустная же у тебя песня получилась... И кстати, ты совершенно прав в том, что я действительно не представляю себе проекты с 50 девелоперами с зарплатой 150$/h. А вот объёмные (измеримая характеристика, ~300-500KLOC) проекты, реализуемые командой из ~15 девелоперов — очень даже представляю и под немалой частью твоих наблюдений (заметь, не выводов!) готов подписаться сам.

IT>Для начала давай разберёмся, что такое большой проект. Если ты думаешь, что это объём написанного кода, то это правда только отчасти. Это всё равно что определять сексуальную ориентацию человека по вторичным половым признакам. Так вот, размер проекта вовсе не измеряется числом строк, он измеряется числом амбиций, прямопропорционально зависящим от количества девелоперов помноженное на их амбициозность. Если учесть, что на серьёзные проекты приглашают серьёзное количество серьёзных ребят, то можешь себе представить что это такое.

Дурдом, естественно, хотя как мне кажется — ты не совсем верно здесь обобщаешь. Конкретная команда формируется конкретным PM-ом или отделом кадров... А может быть, у нас с тобой понимание термина "серьёзные ребята" сильно отличается.

IT> Например, представь что бы получилось, если бы кому-нибудь взбрело в голову поднять такой проект силами Top100 RSDN.ru

Хорошая шутка. Я даже хорошо представляю наши с тобой хм... споры в такой команде.


IT>У каждого из нас свои предпочтения, свой опыт и свои накатанные решения. Они все правильные, но разные. Сегодня может оказаться весомее мнение того, кто красноречивее, завтра того, у кого больше орденов, послезавтра окажется, что лучше было бы делать немного по-другому. А потом у PM'ов созреет новое видение функционирования продукта, маркетинг обнаружит новую нишу на рынке и тут найдётся кто-то, кто предложит ещё более подходящее в данной ситуации архитектурное решение. А проект тем временем идёт, люди пишут код, QA не сидит без дела. И тут ты в не самый подходящий момент заявляешь, что надо бы сделать небольшой рефакторинг во всех классах бизнеслогики. Всего-то делов на 3 часа и все изменения ты сделаешь сам. Правда на эти 3 часа лучше всем пойти покурить, т.к. тебе понадобится весь проект. Допустим средний рейт каждого из 50 девелоперов на этом проекте равен $150/h, то $150 * 3h * 50 = $22500. Столько стоит трёх-часовой простой на таком проекте.

Не-а, они все будут спать (буквально, ночью, как и все нормальные люди), пока я буду модифицировать проект. А наутро простой составит 4 часа одного меня, пока я буду отсыпаться, т.е., $150 * 4h = $600.

IT> Что бы этого избежать используется более мягкий переход, в коде начинают одновременно соседствовать два-три решения, появляются рудименты и атавизмы предыдущих архитектур. Код становится всё более и более запутанным. Бороться с этим бесполезно.

Да, Игорь, так обычно и происходит и ни в малейшей степени я с этим спорить не собираюсь. Бессмысленно спорить с тем, что есть. Споры обычно возникают вокруг того, что должно быть. Кстати, и наша с тобой дискуссия — о том же. Ты на самом деле предлагаешь не упорядочить бардак, а всего лишь свести его до "управляемого", т.е., не ты тянешь за собой проект, а он растаскивает тебя. Знаешь, меня здесь немного огорчает то, что при таком подходе роль архитектора должна по идее свестись к MSDN, т.е., — к справочной системе. Да и та не очень нужна.

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

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

IT> Человеческий фактор, ничего не поделаешь Рассуждать о правильном дизайне мы все мастаки, более того, каждый из нас может похвастаться удачными реализациями удачных решений в небольших проектах. Но большой проект — это часто наука психология + теория компромиссов.

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

IT> Единственный способ поднять такой проект — это не бороться со всем этим бардаком, а суметь его (бардак) организовать (не в смысле устроить, а в смысле взять под контроль).

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

IT> Это умение построить не наиболее удачный дизайн с точки зрения какой-либо привычной характеристики типа быстродействие, масштабируемость, переносимость, а сделать его индифферентным к будущим изменениям, которые неизбежно будут возникать, причём периодичеки.

Лучший дизайн = отсутствие дизайна? Э нет, Игорь, вот тут я с тобой не согласен совершенно. Если совсем чуть-чуть подумать над твоими словами, то мы получим дизайн, который своеобразной "сеткой" облегает "большие и могучие системы" типа ОС, SQL-сервера, Коммуникационной Инфраструктуры. Почему? А потому, что у тебя нету больше места для централизации прикладной семантики. Не-ту-ти. Совсем. Ты пытаешься удовлетворить пожелания всех разработчиков, а это невозможно в принципе. И что ты делаешь? Вздыхаешь, говоришь: "Ну, в конце концов, это сильные ребята" и лепишь "индиффирентную к изменениям архитектуру". В результате у тебя один модуль работает лучше, другой хуже, третий работает через раз... Классика жанра: "Что же это, вы все Левши, а блоха так и не скачет." Я разумеется, сгущаю краски, но суть в том, что при таком подходе любой проект превратится в большой. Блин... десять землекопов в одном колодце будут копать со скоростью одного, но колодец будет в 3 раза шире. Впрочем, я естественно не сомневаюсь, что у конкретного тебя все блохи подкованы и скачут.

Штука как раз в том, что хорошее проектирование (ИМХО) стремится максимально удовлетворить и требованиям масштабируемости, и требованиям переносимости, и необходимому быстродействию, и самое главное — пытается сделать это только один раз, за счёт унификаций. Да, действительно, чтобы не иметь геморроя с выделением сквозной функциональности её лучше выделять на этапе проектирования. Не отсюда ли, кстати и тезис о "специальном проектировании" для АОП?

IT>AOP — это один из путей в светлое будущее. Прежде всего потому, что позволяет разнести, в общем-то, слабо связанные друг с другом сущности, полностью отжать бизнес логику от сквозного кода.

Согласен вобщем-то. Но есть и ещё одна заморока: этот тезис раньше выдвигался как защита ООП. Ничего нового.

IT>С одной стороны, чем короче код бизнес объектов, тем дешевле заказчику обойдётся проект. Продположим, каждый бизнес метод имеет в среднем по 10 строчек, ты сумел убрать одну, экономия 10%.

Ну вот только не грузи меня подобными "расчётами". Э... повторяя тебя же:

будешь эту лапшу своему начальству вешать

Это будет прекрасным аргументом в его глазах. Или у тебя "сильные ребята" работают преимущественно как машинистки? +/- 10% кода не решат вообще ничего.

IT>На 10 лимонах это уже 1 миллион. С другой, разрабатывать, реюзать, отлаживать, модифицировать и сопровождать такой код легче, а значит быстрее и дешевле. Где может сбойнуть следующий код:


IT>
IT>int Sum(int a, int b)
IT>{
IT>    return a + b;
IT>}
IT>


IT>Только в логике.

Разумеется, но кому он нужен в таком-то виде? Сбои проявятся при сопряжении этого кода с кодом сквозной функциональности. Хочешь, я напомню, чего не хватает в этом конкретном коде? Не хватает упоминания метода Sum в композиционном фильтре:

calls("int MyClass.Sum(int, int)") after(){ ... }


Притом упоминание должно быть именно таким. Почему? Попробую ответить.

ИМХО, самые большие неприятности будут, если написать вот так:

calls("* *.Sum(*, *)") after(){ ... }


Это сколько классов накроется аспектированием Sum? А если семантика MyClass2.Sum не соответствует MyClass.Sum и ему не требуется такого аспектирования? А сколько регрессионных тестов потребуется при модификации этого кода? А как тестировать новые классы? Учти, что вносимые АО-транслятором изменения непредсказуемы до запуска. Т.е., после создания нового класса можно ненароком сделать ему метод Sum и... А ведь именно так и будут поступать "новообращённые".

Впрочем, оставим пока новообращённых. Вот добавляем некий новый класс MyClass2 и метод MyClass2.Sum(), которому не требуется такое же аспектирование, как и MyClass.Sum(). Компилируем, запускаем, обнаруживаем белиберду. Исправляем... как? А вот так:

calls ("int *.Sum(*, *)")&&!("int MyClass2.Sum(int, int)") after(){ ... }


Т.е., здравствуй, отдельное упоминание метода MyClass2.Sum(). Потом ещё раз и ещё раз также. У нас вытягивается длинная цепочка отрицаний исходного обобщения "int *.Sum(*, *)". Притом обрати внимание, что эквивалентность имён в фильтре и в коде компилятором не верифицируется (это же просто поиск: нашли — хорошо, не нашли — фиг с ним), переваливая всё на рантайм.

Наконец, мы плюём на всё это и пишем в фильтре примерно такую конструкцию:
calls ("int MyClass.Sum(int, int)") || ("int MyClass3.Sum(int, int)") after(){ ... }


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

А вот теперь противопоставим такому подходу конструирование на шаблонах. Если мы опишем класс прикладной логики например так:


// Общий базовый класс для прикладных классов
template<template<typename G, typename A> class POLICY, typename G, typename A>
class AppBase : public POLICY<G, A> { ... };

template<typename GENERAL_POLICY >
class AppClass1 : virtual public AppBase<Policy, GENERAL_POLICY, AppClass1 >
{
  int Sum(int a, int b)
    {
      POLICY_METHOD_CALL(Sum); // Создание объекта, контролирующего вызов.
        POLICY_RESULT(a + b); // Возможный перехват возвращаемого значения.
    }
};


То мы сможем сделать "финт ушами" и описать требуемую специализацию Policy<> в отдельной группе файлов, где и упомянем о сквозной функциональности и прочих аспектах специализации. В принципе — то же самое АОП, но разница по сравнению с неявной модификацией исходников именно в "явности" специализаций шаблонов. Плюс к тому — мы можем на всех уровнях использовать композиционные возможности C++. Хошь — в аспектах, хошь в специализациях полиси, хошь — в прикладных объектах. Некоторые композиционные ошибки будут отслежены компилятором.

Однако, не буду спорить, что кавардак и с шаблонами можно огрести какой угодно и притом просто влёгкую. Моё глубокое ХО здесь таково, что почти всегда лучше апеллировать к несколько большему объёму мозговой работы и возне с обобщённым кодом, чем широкими шагами идти к возможно полной потере контроля над системой. "Почти всегда", потому что в каких-то случаях и на какое-то время АО-компилятор может действительно оказаться наилучшим выходом. Я бы предположил, что АО-компилятор разумно использовать как промежуточное решение между имеющимимся специализациями и новыми.

IT>А этот?

IT>
IT>HRESULT SomeClass::getSomeValue(LONG *retVal, LONG a, LONG b)
IT>{
IT>    COM_CALL_TRACE_TMDEF(TraceMode<Logged>, SomeClass, getSomeValue)

IT>    *retVal = a + b;

IT>    return S_OK;
IT>}
IT>


IT>Ошибка может быть в вызове макроса (кстати, почитай что о макросах думает Страуструп),...


Плевать мне, что Страуструп по этому поводу думает. Именно недостаточная унифицированность синтаксиса C++ и есть одна из тех "дырок", которую проще заткнуть макросом. Хотя... почему бы не сделать например так:

template<typename GENERAL_POLICY>
class AppClass1 : virtual public AppBase<AppPolicy, GENERAL_POLICY, AppClass1 >
{
    // AppBase::tracer_t<>; // импортируем из AppBase<>, конструктор специализируется адресом метода
    // AppBase::returner_t<>; // оттуда же, специализируется адресом метода
  int Sum(int a, int b)
    {
      tracer_t t(Sum, this); // Создание объекта, контролирующего вызов.
        return returner_t::rv(Sum, a + b); // Контрольная точка для возможного перехвата возвращаемого значения.
    }
};



И кстати, такой код "страшен" только на первый взгляд. В объёмном проекте подобные конструкции раньше или позже примелькаются и не будут вызывать проблем. Для меня лично такое "примелькивание" завершится к концу первого дня. А гибкости в такой реализации не в пример больше, чем у АО-транслятора.

IT>... в самой логике, в коде возврата.

Да, это естественное следствие простейшего сопряжения двух разных идеологий.

IT> Т.е. твой код потенциально в три раза менее надёжный.

Нет, на практике он будет ничуть не менее надёжным, чем приведённый тобой пример. А в отдельных случаях — даже более.

IT> Теперь помнож это на те амбиции, которыми определяется размер проекта и в результате ты вылетишь с него со свистом, как вылетают те многие, которые всего этого не понимают.

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

IT>Поэтому, отвечая на твой пост:

...ты излагаешь наблюдения, делая странные на мой взгляд выводы.

ГВ>>

IT>

А если без ёрничанья, то перспектива получения каши если не из БЛ+вспомогатльный код, то уж внутри вспомогательного кода или внутри самой БЛ — по любому остаётся.


IT>Дело не в наличии каши как таковой, дело в её размерах. Каша в БЛ — это каша в БЛ, каша в сквозном коде — это каша в сквозном коде. Если ты их соединяешь вместе, то ты их не складываешь, ты их помножаешь.

И с умножением здесь я тоже совершенно согласен. Только то же самое у тебя произойдёт и при работе с АОП. Разве что коэффициент умножения будет несколько меньше.

IT> Согласен, что в маленьком проекте это вполне допустимо, практически без разницы, но в большом... увы.

Да, и я совершенно согласен.

IT>Хорошая архитектура в данном смысле — это не та архитектура, которая красиво смотрится в коде, это та, которую не видно вообще.

У-у-упс! Хороша позиция для архитектора, ничего не скажешь. Что-то я не совсем понимаю: а за что же он тогда отвечает? За то, чтобы все песни всех участников создали некое подобие согласованного скрипа?

ИМХО, хорошая архитектура позволяет ответить на вопросы: "чего можно?" и "чего нельзя?", и не требует большого времени на изучение деталей. Иными словами, хорошая архитектура помогает организовать мышление участников, чтобы не было явления ужасных Лебедя, Рака и Щуки.

IT> А AOP — это как раз один из путей для нас увидеть всё это счастье ещё в этой жизни

Увидеть — и содрогнуться? Во всяком случае, я бы не стал утверждать, что архитектура, которой "не видно вообще" — это хорошо. Это скорее признак гибели архитектуры, а АОП для неё — всё равно что спасательный круг. Только вот на спасательных кругах обычно ждут спасателя, а не отправляются в круизы...



Теперь — немного выводов.

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

При всём при том я не предлагаю жёстко заставлять всех "думать правильно" и так далее. Нет, я только предлагаю структурировать направление усилий и развить коммуникации. Проекты с большим числом участников (больше двух!), кстати, нередко от того и гибнут, что коммуникации плохо работают, или потому, что разнообразие мнений превращается в Лебедя, Рака и Щуку. И никуда от этого не денешься. Всегда — сколько людей, столько мнений. Но ведь и их можно разделить на подкоманды, подгруппы и т.п. И неизбежно что-то кому-то придётся отбросить и с чем-то смириться. Если кто-то не согласен — ну что ж. Может поискать другую работу или найти своё место здесь. Второй вариант предпочтительней, первый — тоже выход. Вот здесь действительно нужны и психология, и компромиссность, и ещё много каких личностных качеств центровых игроков.

Второе. Ты здесь в соседней ветке сказал, что у нас с тобой спор "новое vs старое". Нету пока что в АОП принципиальной новизны. Где она? В том, что привязку одних объектов к другим обозвали неким именем? Угу, новизна в общепринятой терминологии — и я с этим не спорю. Появились новые инструменты? А где я говорил, что это само по себе плохо? Другое дело, что они пока идеологически кривы... ну может быть когда-нибудь спрямятся. Возможно, появится новая строчка в табели о рангах в IT-индустрии. Но вся принципиальная новизна АОП пока что разлетается в пыль, если только вместо вызова метода создавать объект MethodCall<> с соответствующими параметрами и т.п. Всё, на этом новизна АОП заканчивается. Точки привязки аспектов на данный момент выделяются крайне наивно: call/return/before/after/throw/around ну и ещё — модификации структуры классов. Я не случайно говорю "на данный момент". Может быть — придумают что-то ещё: например, эффективные способы семантического анализа программ. Или — принципиально новые способы подмешивания сквозной функциональности. Хорошо бы...

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

Вся новизна залючается только в снятии одних шор и немедленном одевании других. Коллеги, ну ёлки зелёные, лучше Лиспом займитесь.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re: Бардак ещё не аргумент
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.02.04 06:17
Оценка: :)
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Что-то я не понял выделенной фразы. Причём тут бедность или богатство? А... кажется дошло. Это только бедные думают и работают... Хм. А богатые что делают?


О!!!... У них есть одна большая задача. Они думают как не работать.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Бардак ещё не аргумент
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 03.02.04 09:26
Оценка:
Здравствуйте, VladD2, Вы писали:

ГВ>>Что-то я не понял выделенной фразы. Причём тут бедность или богатство? А... кажется дошло. Это только бедные думают и работают... Хм. А богатые что делают?


VD>О!!!... У них есть одна большая задача. Они думают как не работать.


Ну... тоже ведь думают как-никак... Что-то совсем я запутался...
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re: Оффтоп, в общем-то
От: Eugals Россия  
Дата: 05.02.04 12:37
Оценка:
Почему-то мой Janus упорно не хочет эту тему закачивать, а обсуждение получилось довольно интересное...
Пишу данное сообщение в надежде, что хоть в этом случае янус обратит сюда внимание...

Ну, а чтобы уж не совсем бесполезное сообщение было, скажу пару слов "в тему"
Вот тут многие соглашались, что "нормальной" реализации АОП сейчас фактически не существует.
Может оно и так, только хочу напомнить про язык Python — в нем возможность существования сквозной функциональности была заложена изначально. уже почти 10 лет как.
А после доработок (в работе метаклассов) сделанных в версиях 2.0-2.2 всё и вовсе стало почти идеально
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.