Здравствуйте, Аноним, Вы писали:

IAZ>>Хороший способ расширения библиотеки классов — это использование оберток.

А>Хороший! Тем не менее, он не всегда срабатывает. Например, если нужно добавить не просто методы, а и члены-данные.

Почему? Кто запрещает поместить вместе с методом и атрибуты?

template<class T>
class X
{
public:
   X(T* _a) : a(_a) {}
   void h(); // метод
   int k;    // атрибут
   T* operator->()
   {
     return a;
   }
private:
   T* a;
};

А>Думаю, что не мешает ввести немного конкретики. Допустим у нас есть класс Figure с методом move(int, int) и классы Square и Circle, которые наследуются от Figure и реализуют move(int, int) по-своему.
<skip>
А>Вроде все нормально. Но следует заметить, что количество дополнительного кода прямо пропорционально количеству прямых наследников от Figure, что не есть хорошо. Но и это еще не все! Данные изменения касаются только объектов, созданных разработчиком, который знает о подписке и знает, что теперь нужно создавать объекты класса SquareWithSubscription а не просто Square. Т.е. подписаться на премещения объектов, которые были созданы где-то в недрах библиотеки невозможно.

Подобные (со сложной иеррархией и интенсивным использованием полиморфизма) библиотеки классов (не объектов!) создаются для их дальнейшего использования и рассширения другими программистами. Что означает, что внутри этой библиотеки объекты не порождаются. Просто может не быть тех классов от которых можно создать объект. А если и можно то что с ним делать? Вопрос который может разрешить только пользователь этой библиотеки. Может тот который и решил рассширить ее для получения извещения при перемещении фигур. А другим это возможность может и не нужна! Зачем навязывать всем свое мнение о перемещении фигур? А то получается, что написал я графический редактор с использованием обычной библитеки классов (без извещения). А в один прекрасный момент программа стала посылать кому-то какие-то извещения!


А>А после этого следить, чтобы все двигали фигуры только через врапперы!

За кем следить? Подробнее см. выше.

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

Вот это действительно так. А может библиотека специально спроектирована не расширяемой!?

А>Впрочем, чтобы немного упростить себе жизнь, придумали аспектно-ориентированное программирование.

За каждым упрощением скрывается море проблем.

А>В частности, задача с перемещениями фигур могла бы решаться при помощи такого аспекта (здесь приведен псевдокод):

С теоретической точки зрения возможно это иногда нужно. Но только при обязательном условии: чтобы можно было это оключать или недопускать распространения на определенные объекты!