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

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

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

    *retVal = a + b;

    return S_OK;
}

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

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

Да! Ты прав! Это тот самый подход который был всем нужен, и которого все ждали. Но есть пара проблем. Поменять несколько тысяч методов даже один раз сложно. Нужно как-то автоматизировать этот процесс. Нам нужен тулз для рефакторинга. Согласись — это будет удобно!

Так что же должен уметь наш тулз? Ну, предположим замена по контксту. Но могут возникнуть проблемы. При замене по контексту может оказаться так, что имена методов совпадут с чем-нибудь, что трогать не надо. Или имена переменных перепутаются. Геморроя конечно меньше, чем при ручной замене. Но все же макросы и регекспы не совершенны. Так чего же им не хватает?

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

Можно ли реализовать такую фичу в лоб? Несомненно, но есть одна проблемка. Создание примитивного парсера — это уже сложная задача. Так что делать такой парсер для локальной задачи очень расточительно. Но можно же сделать его универсальным! И тогда его можно будет подключить к макросам VS и использовать там где надо.

Эврика! Мы упростили себе работы на два порядка. Теперь такая контекстная замена делает в 5-10 нажатий мыши. Но... Но после некоторых замен мы теряем информацию. Что же делать? Наши замены оказывается необратимы! При некоторых из них мы обязаны брать информацию извне, а при других уничтожать лишнюю (на этот момент) информацию.

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

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

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

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

Ну, все кажется идея супер реплэйса доведена до идеала. Ну, и на фиг нам ваш АОП?

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

Занавес...

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

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

Большая вероятность ошибок: Запутанность кода влечет за собой код с множеством скрытых проблем. (Вот удивили-то! — ГВ.) Более того, реализация нескольких ортогональных требований в одном модуле может привести к тому что ни одно из них не получит достаточного внимания разработчика.

Трудность в сопровождении: Появление дополнительных требований в будущем потребует переработки текущей реализации, и это может затронуть большинство существующих модулей. (Курсив мой — ГВ.) Модификация каждой отдельной подсистемы в отдельности под новые требования может привести к несовместимости

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

class Main {
//...
       public void foo(int i) {
           Logger.entry("foo(int)");
           System.out.println(i++);
           Logger.exit("foo(int)");
       }
}

template<typename FrameworkPolicy>
class Main {
//...
       public void foo(int i) {
           FrameworkPolicy::method m(Main::foo); // Явное указание модификации
           System.out.println(i++);
}

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

Перемешивание кода проверки условий и соблюдения контрактов с основным кодом компонентов. Это снижает способность компонентов быть повторно использованными и снижает "читабельность" их кода.

Рассредотачивание кода проверки контрактов по всей системе. Если возникает потребность изменить какое-либо из условий, то необходимо изменить их во всех модулях, на которые оно распространяется.

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

Невозможность соблюдения контрактов во время сборки проекта. В настоящее время реализации компиляторов объектных языков (Java, C++) не позволяют соблюдать проектные соглашения при сборке проекта.

HRESULT SomeClass::getSomeValue(LONG *retVal)
{
  COM_CALL_TRACE(SomeClass, getSomeValue)
    //...
}

HRESULT SomeClass::getSomeValue(LONG *retVal)
{
  COM_CALL_TRACE_TMDEF(TraceMode<Logged>, SomeClass, getSomeValue)
    //...
}

struct Point
{
private:
    int x, y;
public:

    Point()
    {
        x=0;
        y=0;
    }    
    virtual    int getX() 
        { 
            return x; 
        }
    virtual    int getY() 
        { 
            return y; 
        }
    virtual    void setX(int x) 
        {
            this->x = x; 
        }
    virtual    void setY(int y) 
        {
            this->y = y; 
        }

};

struct Line
{
private:
    Point* p1, *p2;
public:
    virtual    Point* getP1() 
        { 
            return p1; 
        }
    virtual    Point* getP2() { return p2; }
    virtual    void setP1(Point* p1) 
        {
                     this->p1 = p1;
               }
    virtual    void setP2(Point* p2) 
        {
                     this->p2 = p2;
               }    
};

template<typename Base>
struct    DisplayUpdateAspectBase : public    Base
{
protected:
    Display* display;
public:
    /*SetDisplay/GetDisplay*/
};

template<typename Base>
struct PointDisplayUpdateAspect : public    DisplayUpdateAspectBase<Base>
{
public:
    virtual    void setX(int x) 
        {
            Base::setX(x);
            display->Update();
        }
    virtual    void setY(int y) 
        {
            Base::setY(y);
            display->Update();
        }
};

template<typename Base>
struct LineDisplayUpdateAspect : public    DisplayUpdateAspectBase<Base>
{
public:
    virtual    void setP1(Point* p1) 
        {
                     Base::setP1(p1);
            display->Update();
               }
    virtual    void setP2(Point* p2) 
        {
                     Base::setP2(p2);
            display->Update();
               }        
};

typedef    PointDisplayUpdateAspect<Point>    DisplayPoint;
typedef    LineDisplayUpdateAspect<Line>    DisplayLine;

template<typename Base>
struct    LockAspectBase : public Base
{
protected:
    SyncObj    syncObj;
public:
    /*GetSyncObj*/
};

template<typename Base>
struct    PointLockAspect : LockAspectBase<Base>
{
public:
    virtual    void setX(int x) 
        {
            Mutex mtx( &syncObj);
            Base::setX(x);
        }
    virtual    void setY(int y) 
        {
            Mutex mtx( &syncObj);
            Base::setY(y);
        }    
};

typedef    PointDisplayUpdateAspect<Point>        DisplayPointBase;
typedef    PointLockAspect<DisplayPointBase>        DisplayPoint;

struct 3DPoint: public Point
{
protected:
    int z;
    3DPoint()
    {
        z = 0;
    }
    virtual    int getZ()
    {
        return Z;
    }
    virtual    void    setZ( int z )
    {
        this->z = z;
    }
};

template<typename Base>
struct 3DPointDisplayUpdateAspect : public    PointDisplayUpdateAspect<Base>
{
    virtual    void    setZ( int z )
    {
        Base::setZ(z);
        GetDisplay()->Update();
    }
};

template<typename Base>
struct 3DPointLockAspec : public PointLockAspec<Base>
{
    virtual    void    setZ( int z )
    {
        Mutex mtx( GetSyncObj());        
        Base::setZ(z);
    }
};

CrossContextChannel.SyncProcessMessage(message)
{
  Identity serverIdentity = InternalSink.GetServerIdentity(message);
  Context context = serverIdentity.ServerContext;

  ContextTransitionFrame frame = new ContextTransitionFrame();

  Thread.CurrentThread.EnterContext(сontext, ref frame);
  сontext.GetServerContextChain().SyncProcessMessage(message);
  Thread.CurrentThread.ReturnToContext(ref frame);
}

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

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

[MyClassFactory]
public class MyClass : ContextBoundObject
{
}

class MyRealClass : MyClass
{
}

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

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

V>Тема крайне интересная, и хотелось бы от IT услышать хоть один достойный пример, где АОП имело бы преимущество перед ООП. Хуки не предлагать , в реальных системах хуки делаются путем хаков (Win32). Интересно услышать задачу, относящуюся к целевым бизнес-объектам, а не к вспомогательным/системным вещам. (системного рода задачки на С++ весьма весело решаются, и никто не придерживается строгого ООП, если речь идет о чем-то весьма системном, типа представлении стека как списка параметров, в одной из своих библиотек на С++ я именно так и делал и даже больше, ибо возможность произвольной реинтерпретации произвольного участка памяти в С++ есть, хоть это и опускает нас на уровень древнего С... кстати, многое из Remouting в .Net именно на таком уровне и сделано, весьма это далеко от АОП и ООП)

V>Если не трудно, развития ради, интересно посмотреть на код и оценить трудоемкость подхода IT в решении его собственной задачки. ГВ предложил одну строчку кода на все интересующие методы, трудоемкость в этом случае ясна и понятна. IT, давай решение на АОЯП — справедливости ради, а то пока не ясно как все это сравнивать

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

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

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

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

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

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

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

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

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

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); // Возможный перехват возвращаемого значения.
    }
};

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>

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> А AOP — это как раз один из путей для нас увидеть всё это счастье ещё в этой жизни

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

struct MyObject
{
    int x;
    int y;
};

void MyMethod(MyObject *this)
{
}

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

obj.Do<MyClass::Action1>(Tuple(12,Aliased<xParam>(2)));

struct MyClass
{
    struct Action1
    {
        typedef int ret;
        template<typename P>
        static int Do(MyClass& This, const P& p)
        {
            Get<1>(p);
                // доступ к параметру по индексу
            Get<xParam>(p);
                // доступ по как-нибудь ассоциированному типу (xParam - какой-то уникальный тип)
            ForEach(p,SomeFunctor()); //просто перечисляем все параметры
        }
    };
    struct Action2
    {
        template<typename P>
        static int Do(MyClass& This, const P& p)
        {
        }
    };
};

// можно специализировать для любого действия и для любого класа статически
// + дефолтавая реализация может подобрать что-то в rt
template<typename T, typename A>
struct ProxyHlpr
{
    typedef typename A::ret ret;
    template<typename P>
    static void after(T& t, const P& p)
    {
    }
    template<typename P>
    static void before(T& t, const P& p)
    {
    }
    template<typename P>
    static ret call(MyClass& t, const P& p)
    {
        return MyClass::Action1::Do(t,p);
    }
};


template<typename O>
struct UnrealProxy
{
private:
    O obj;
public:
    UnrealProxy():obj(){}
    template<typename T, typename P>
    typename ProxyHlpr<O,T>::ret Do(const P& p)
    {
        ProxyHlpr<O,T>::before(obj,p);
        ProxyHlpr<O,T>::ret ret=ProxyHlpr<O,T>::call(obj,p);
        ProxyHlpr<O,T>::after(obj,p);
    }
};

...........................

//а это уже более высокий уровень

UnrealProxy<MyClass> obj;
obj.Do<MyClass::Action1>(Tuple(12,Aliased<xParam>(2)));

M>Интересно, а причем здесь АОП? Я конечно понимаю, что тормоза, погода, красный цвет — это все у тебя к стилю программирования относиться

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

M>Ага. Щаз! Только вот те тормоза, которые при этом возникают, это не в счет. Конечно, зачем их учитывать, если мы программируем с использованием АОП.

N>>>хотя причём тут RealProxy до сих пор понять не могу

M>>В Нете это одна из реализаций аспектной сущности.

IT>В .NET — это механизм перехвата создания и вызова методов объектов, который можно использовать для имплементации идей AOP, за счёт значительной потери производительности. Но в случае ремоутинга это вполне допустимо.

M>Ладно. Теперь перейдем к метапрограмированию. Атрибуты — это хорошо. Очень хорошо. Но! Только тогда, когда они в меру и когда они реально нужны. Или для тебя Reflection ничего не значит, вернее его производительность?

M>Во-первых, RealProxy в .NET реализован средствами ООП. Это к тому, кто тут путает теплое с мягким.

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

ремоутинг нужен для передачи объектных сообщений через канал

внутренние вызова внешних объектов

IT>Кстати. О фабриках и синглетонах в .NET. AOP в действии

........

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

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

Console.WriteLine(System.Runtime.Remoting.RemotingServices.IsTransparentProxy(mc));

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

IT>using System;
IT>using System.Runtime.Remoting.Proxies;

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

IT>[MyClassFactory]
IT>public class MyClass : ContextBoundObject
IT>{
IT>}

IT>class MyRealClass : MyClass
IT>{
IT>}

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

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

struct MyClassBase
{

};

typedef    MyClassBase    MyClass;

int main(...)
{
    MyClass* mc= new MyClass();
}

template<typename Base>
struct    MyRealClass: public    Base
{

};

typedef    MyRealClass<MyClassBase>    MyClass;

int main(...)
{
    MyClass* mc= new MyClass();
}

template<typename Base>
struct    MyRealClassWithAdittionalStrategy : public Base
{

};

typedef    MyRealClassWithAdditionalStrategy<MyRealClass<MyClassBase> >     MyClass;

int main(...)
{
    MyClass* mc= new MyClass();
}

M>> В С++ нет ТР. Это ведь не значит, что там не может быть АОП.

M>>идет перпендикулярно.

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

Именно для перехвата вызовов она и предназначена.

AVK>Блин, Мика, почитай что такое ExecuteMessage и что он делает

M>>Сужаем круг требований. Так глядишь дойдем до того, что это можно было бы предвидеть на этапе проектирования

M>>Думаю, вот для этого

M>>CrossContextChannel.SyncProcessMessage(message)
M>>{
M>>  Identity serverIdentity = InternalSink.GetServerIdentity(message);
M>>  Context context = serverIdentity.ServerContext;

M>>  ContextTransitionFrame frame = new ContextTransitionFrame();

M>>  Thread.CurrentThread.EnterContext(сontext, ref frame);
AVK>M>  сontext.GetServerContextChain().SyncProcessMessage(message);
M>>  Thread.CurrentThread.ReturnToContext(ref frame);
M>>}
M>>

Context.GetServerContextChain()
{
  return new ServerContextTerminatorSink();
}

ServerContextTerminatorSink.SyncProcessMessage(message)
{
  IMessageSink sink = InternalSink.GetServerIdentity(message).GetServerObjectChain(out obj);
  return sink.SyncProcessMessage(message);
}

ServerIdentity.GetServerObjectChain()
{
  IMessageSink sink = new ServerObjectTerminatorSink(serverObj);
}

ServerObjectTerminatorSink.SyncProcessMessage
{
      IMessage iMessage2;

      IMessage iMessage1 = InternalSink.ValidateMessage(msg);
      if (iMessage1 != null)
      {
        return iMessage1;
      }
      IMethodCallMessage iMethodCallMessage = msg is IMethodCallMessage;
      LogicalCallContext logicalCallContext1 = null;
      bool flag = false;
      try
      {
        object local1 = _server;
        VerifyIsOkToCallMethod(local1, iMethodCallMessage);
        LogicalCallContext logicalCallContext2 = null;
        if (iMethodCallMessage != null)
        {
          logicalCallContext2 = iMethodCallMessage.LogicalCallContext;
        }
        else
        {
          logicalCallContext2 = (LogicalCallContext)msg.Properties["__CallContext"];
        }
        logicalCallContext1 = CallContext.SetLogicalCallContext(logicalCallContext2);
        flag = true;
        logicalCallContext2.PropagateIncomingHeadersToCallContext(msg);
        PreserveThreadPrincipalIfNecessary(logicalCallContext2, logicalCallContext1);
        if (IsOKToStackBlt(iMethodCallMessage, local1) && ((Message)iMethodCallMessage).Dispatch(local1, fExecuteInContext))
        {
          iMessage2 = new StackBasedReturnMessage();
          ((StackBasedReturnMessage)iMessage2).InitFields((Message)iMethodCallMessage);
          LogicalCallContext logicalCallContext3 = CallContext.GetLogicalCallContext();
          logicalCallContext3.PropagateOutgoingHeadersToMessage(iMessage2);
          ((StackBasedReturnMessage)iMessage2).SetLogicalCallContext(logicalCallContext3);
        }
        else
        {
          MethodBase methodBase = GetMethodBase(iMethodCallMessage);
          object[] locals1 = null;
          object local2 = null;
          RemotingMethodCachedData remotingMethodCachedData = InternalRemotingServices.GetReflectionCachedData(methodBase);
          object[] locals2 = Message.CoerceArgs(iMethodCallMessage, remotingMethodCachedData.Parameters);
          local2 = PrivateProcessMessage(methodBase, locals2, local1, methodPtr, fExecuteInContext, out locals1);
          CopyNonByrefOutArgsFromOriginalArgs(remotingMethodCachedData, locals2, ref locals1);
          LogicalCallContext logicalCallContext4 = CallContext.GetLogicalCallContext();
          iMessage2 = new ReturnMessage(local2, locals1, (locals1 != null) ? (int)locals1.Length : 0, logicalCallContext4, iMethodCallMessage);
          logicalCallContext4.PropagateOutgoingHeadersToMessage(iMessage2);
        }
        CallContext.SetLogicalCallContext(logicalCallContext1);
      }
      catch (Exception e)
      {
        iMessage2 = new ReturnMessage(e, iMethodCallMessage);
        ((ReturnMessage)iMessage2).SetLogicalCallContext(iMethodCallMessage.LogicalCallContext);
        if (flag)
        {
          CallContext.SetLogicalCallContext(logicalCallContext1);
        }
      }
      return iMessage2;
}