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

M>Как-то надо все-таки определиться, мы обсуждаем Аспекты "в принципе" или Аспекты в Net, а то mika все на RP с CBO съезжает.

Да не я это. ИТ сам первым упомянул эти слова. Ну я и понеслась

M>Пока преимуществ AOP в Net не много... Я, откровенно говоря, только-только в это въезжаю, и уже хочется большего, но сама идея мне нравится.

А кому она не нравится?

M>2IT Вот Игорь, воспитывал, воспитывал Мику, а сейчас тебя большие дядьки разуму научать будут...

Поправочка. Игорь воспитывал Рому. Мне же удалось-таки уйти от этой экзекуции.

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

M>Да не я это. ИТ сам первым упомянул эти слова. Ну я и понеслась
А чего нестись-то? Нефиг путать идею с реализацией..

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

B>>Еще несколько лет назад я бы кинулся в драку защищать свой любимый С++, но со временем эта категоричность проходит, думаю у тебя тоже это случится, тридцатка уже стукнула или еще нет?
M>
M>2IT Вот Игорь, воспитывал, воспитывал Мику, а сейчас тебя большие дядьки разуму научать будут...

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


B>> То есть эти средства помогают более простыми и экономичными способами имплементировать все тот же правильный дизайн, ведь выделение сквозной функциональности в одном месте это в первую очередь правильный дизайн, АОП предлагает лишь более простой метод придерживаться этого дизайна.
M>Корректно ли говорить о "более правильном" или "менее правильном" дизайне? АОП предполагает все-таки большую гибкость, я бы даже сказал более удачное соотношение "гибкость/сложность кода",

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

M> в этом смысле дизайн с AOP более правильный.
Подчеркиваю, АОП поможет имплементировать необходимый дизайн. Хотелось бы при этом избежать компромисов, но в реальной жизни так не бывает, я думаю каждый из вас испытывал ощущения, когда ты читаешь инфу о новом подходе или идеологии и тут же начинаешь взвешивать в голове сколько новых проблем это принесет, чего тебя лишают, и чем тебя наделяют взамен. Свой первый серьёзный облом с явой я прошел еще в году 97 — м, средств упрощающих правильную имплементацию там явно не хватало, не зря сейчас и в Шарпе и в Яве дженерики появились, причина все та же, добавить эти самые средства имплементации...

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

IT>>Тогда уж лучше абстрактные классы vdimas.

B>Согласен, но это уже вопрос воспитания.

Воспитание — это хорошо. Но если есть возможность ошибиться, то люди будут ошибаться и этот код будет уходить в производство. В результате всё как бы работает и даже правильно, за исключением какой-то одной служебной функции. Вот, допустим, мы подобным способом имплементируем разграничение прав. Я забыл о воспитании или, например, Intellisence, сволочь подсунул мне не тот метод. Всё работает, функциональные тесты проходят, код уходит клиенту. Далее юный хакер из соседней школы вызывает мой метод и грабит через него автоматизируемый нами банк Кого сажать? Меня, как допустившего ошибку? Или тебя, как давшего мне такую ошибку допустить? Допустим меня, но где гарантия, что это была одна единственная подобная ошибка? Ты это можешь гарантировать?

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

Как раз сейчас речь идёт вовсе не о результате. Речь о минимизации усилий при кодировании и сопровождении.

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

Нет, пока только 0x25 стукнуло

B>Вобщем какое может быть отношение неискушенных программеров к АОП идеологии? На мой взгляд тут нет места сопоставлениям, AOP vs. OOP и так далее. Это две разные парадигмы, которые друг друга дополняют, но не заменяют.

Кто бы спорил. Ты почитай с чего начался весь спор. ГВ заклеймил AOP как явление, сказал что без него до сих про жили и жить будем дальше. Пришлось вступаться.

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

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

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

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

M>> в этом смысле дизайн с AOP более правильный.
B>Подчеркиваю, АОП поможет имплементировать необходимый дизайн.
Осознал.

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

M>Так что, вердикт таков. Берем банду, учим паттерны, проектируем

Это только половина вердикта. В оставшейся части — используем AOP, если это позволяют нам доступные средства.

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

M>Игорь, в своем первом сообщении упомянул RealProxy. Так что ни о каком чистом АОП и речи не шло. Это я его продвигаю, так как на С++ проксей не сущесвует.

Теперь я понял. Все твои посылки в защиту ГВ — это как раз и есть твоё продвижение AOP. Ну оно и понятно, на С++ ведь проксей не сущесвует.

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

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

IT>>>Тогда уж лучше абстрактные классы vdimas.

B>>Согласен, но это уже вопрос воспитания.

IT>Воспитание — это хорошо. Но если есть возможность ошибиться, то люди будут ошибаться и этот код будет уходить в производство. В результате всё как бы работает и даже правильно, за исключением какой-то одной служебной функции. Вот, допустим, мы подобным способом имплементируем разграничение прав. Я забыл о воспитании или, например, Intellisence, сволочь подсунул мне не тот метод. Всё работает, функциональные тесты проходят, код уходит клиенту. Далее юный хакер из соседней школы вызывает мой метод и грабит через него автоматизируемый нами банк Кого сажать? Меня, как допустившего ошибку? Или тебя, как давшего мне такую ошибку допустить? Допустим меня, но где гарантия, что это была одна единственная подобная ошибка? Ты это можешь гарантировать?

Кажется ты что то там про демагогию говорил...

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

IT>Как раз сейчас речь идёт вовсе не о результате. Речь о минимизации усилий при кодировании и сопровождении.
Ну давай количество строк сравнивать не будем, тем более что количество это будет приблизительно одинаковым

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

IT>Нет, пока только 0x25 стукнуло

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

B>>Вобщем какое может быть отношение неискушенных программеров к АОП идеологии? На мой взгляд тут нет места сопоставлениям, AOP vs. OOP и так далее. Это две разные парадигмы, которые друг друга дополняют, но не заменяют.

IT>Кто бы спорил. Ты почитай с чего начался весь спор. ГВ заклеймил AOP как явление, сказал что без него до сих про жили и жить будем дальше. Пришлось вступаться.
Да нормальный он парень, просто объясниться внятно не получилось, либо вам не удалось его понять, одно из двух, точно говорю

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

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

M>>Да не я это. ИТ сам первым упомянул эти слова. Ну я и понеслась
M>А чего нестись-то? Нефиг путать идею с реализацией..

Вот вот. Я Игоря этим и потыкал. А до сих пор сопротивляется

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

M>>Игорь, в своем первом сообщении упомянул RealProxy. Так что ни о каком чистом АОП и речи не шло. Это я его продвигаю, так как на С++ проксей не сущесвует.

IT>Теперь я понял.

Всегда бы так

IT>Все твои посылки в защиту ГВ

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

IT>- это как раз и есть твоё продвижение AOP.

Я не продвигаю АОП. Я пытаюсь отделить понятие реализации АОП от его абстрактного представления.

IT>Ну оно и понятно, на С++ ведь проксей не сущесвует.

Вот опять. Ну причем тут прокси? Ну нет у АОП такого понятие как "прокси". Там есть такое понятие как "аспект".

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

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

Пример, который я привёл является классической задачей AOP. Решение на RP вполне нормальное, с той оговоркой, что используется ремоутинг.

Hello, "IT"
>
> M>Я защищал ту идей, в которой говорилось, что на ООП решение будет более эффективно и просто. Конечно, не все можно так красиво сделать на ООП, как это можно реализовать на АОП. Но данный пример (которые ты привел) был настолько надуманным и ужасным, что на АОП решение оказалось очень и очень плохим.
>
> Пример, который я привёл является классической задачей AOP. Решение на RP вполне нормальное, с той оговоркой, что используется ремоутинг.

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

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

>> Пример, который я привёл является классической задачей AOP. Решение на RP вполне нормальное, с той оговоркой, что используется ремоутинг.

TK>Ну, добавлять свои сервисы через CBO и говорить, что используется ремоутинг — это слишком громко. Просто, схожие технологии которые используют общую инфраструктуру.

С той оговоркой, что в решеаемой задаче используется ремоутинг. Такая формулировка устроит?

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

IT>>Воспитание — это хорошо. Но если есть возможность ошибиться, то люди будут ошибаться и этот код будет уходить в производство. В результате всё как бы работает и даже правильно, за исключением какой-то одной служебной функции. Вот, допустим, мы подобным способом имплементируем разграничение прав. Я забыл о воспитании или, например, Intellisence, сволочь подсунул мне не тот метод. Всё работает, функциональные тесты проходят, код уходит клиенту. Далее юный хакер из соседней школы вызывает мой метод и грабит через него автоматизируемый нами банк Кого сажать? Меня, как допустившего ошибку? Или тебя, как давшего мне такую ошибку допустить? Допустим меня, но где гарантия, что это была одна единственная подобная ошибка? Ты это можешь гарантировать?

B>Кажется ты что то там про демагогию говорил...

Какая демагогия? Я тебе привёл вполне реальный пример, может его чуть-чуть приукрасил. Замени пионера на бестолковую операционистку и всё будет как в жизни.

IT>>Как раз сейчас речь идёт вовсе не о результате. Речь о минимизации усилий при кодировании и сопровождении.
B>Ну давай количество строк сравнивать не будем, тем более что количество это будет приблизительно одинаковым

Я тебе не за строки говорю, а за количество траха, которое мы все имеем при смешивании бизнеслогики и сквозного кода.

IT>>Нет, пока только 0x25 стукнуло

B>То то я вижу ты круглосуточно в форуме сидишь.

Это просто у нас с тобой сутки в разное время

B>Папа, вернись в семью, тебя дети ждут!!

Мои дети уже большие, папу в Тёрнамент делают как сынка

IT>>Кто бы спорил. Ты почитай с чего начался весь спор. ГВ заклеймил AOP как явление, сказал что без него до сих про жили и жить будем дальше. Пришлось вступаться.
B>Да нормальный он парень, просто объясниться внятно не получилось, либо вам не удалось его понять, одно из двух, точно говорю

А кто говорит, что он ненормальный Это у нас с ним обычный спор на тему старое vs новое.

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

M>>>Да не я это. ИТ сам первым упомянул эти слова. Ну я и понеслась
M>>А чего нестись-то? Нефиг путать идею с реализацией..

M>Вот вот. Я Игоря этим и потыкал. А до сих пор сопротивляется

Просто ты как всегда перепутал тёплое с мягким

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

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

M>>>>Да не я это. ИТ сам первым упомянул эти слова. Ну я и понеслась
M>>>А чего нестись-то? Нефиг путать идею с реализацией..

M>>Вот вот. Я Игоря этим и потыкал. А до сих пор сопротивляется

IT>Просто ты как всегда перепутал тёплое с мягким

Понятно. Начинаем уже стрелки друг на друга переводить

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

TK>>Ну, добавлять свои сервисы через CBO и говорить, что используется ремоутинг — это слишком громко. Просто, схожие технологии которые используют общую инфраструктуру.

IT>С той оговоркой, что в решеаемой задаче используется ремоутинг. Такая формулировка устроит?

А если ремоутинг не используется? т.е. реально считается, что System.EnterpriseServices.ServicedComponent это просто "неживое" решение (особенно библиотечные COM+ компоненты) из-за тормозов в CBO?

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

IT>>С той оговоркой, что в решеаемой задаче используется ремоутинг. Такая формулировка устроит?

TK>А если ремоутинг не используется? т.е. реально считается, что System.EnterpriseServices.ServicedComponent это просто "неживое" решение (особенно библиотечные COM+ компоненты) из-за тормозов в CBO?

Можно вопрос точнее сформулировать?

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

IT>>Я не про это. Было что-типа CreateUninitializedObject

M>И каков принцип не помнишь? Может аналог FormatterServices.GetUninitializedObject, только напрямую через internal методы.

Короче, вот такой изврат получается.

using System;
using System.Runtime.Remoting.Proxies;
using System.Runtime.Remoting.Messaging;

namespace Example
{
    public class MyProxy : RealProxy
    {
        public MyProxy(Type type) : base(type)
        {
        }

        public MarshalByRefObject CreateInstance()
        {
            InitializeServerObject(null);

            return base.GetUnwrappedServer();
        }

        public override IMessage Invoke(IMessage msg)
        {
            return null;
        }
    }

    [AttributeUsage(AttributeTargets.Class)]
    public class MyClassFactoryAttribute : ProxyAttribute
    {
        public override MarshalByRefObject CreateInstance(Type type)
        {
            return new MyProxy(typeof(MyRealClass)).CreateInstance();
        }
    }

    [MyClassFactory]
    public class MyClass : ContextBoundObject
    {
    }

    class MyRealClass : MyClass
    {
    }

    class Test
    {
        static void Main()
        {
            MyClass mc = new MyClass();

            Console.WriteLine(mc.GetType().Name);
        }
    }
}

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

M>Кстати, код работоспособен. Только ужасно тормознутый

А как ты мерял тормознутось?