std::vector<void *> vec;

class Object
{
public:
   virtual Object() {}
   virtual Read(istream & is) = 0;
   virtual Write(ostream & os) const = 0;
};

std::vector<Object *> vec;

КЛ>Это зависит от контекста. Вон даже wikipedia утверждает, что не существует единственного формального определения термина метаданные. Откуда ж я знаю, что Вы имеете в виду?

КЛ>Вот это, как раз, и называется абстрагированием, т.к. для описания структуры формы (или контрола) — что в чем содержится — совершенно не важен тип конкретных объектов. Т.е. в рамках конкретной задачи — структурирования — мы абстрагируемся от несущественных для этой задачи деталей.

КЛ>А вообще-то, я очень сильно сомневаюсь, что layout алгоритм как-то сильно изменится в ближайшие лет 10 — 20. Оперирует он прямоугольниками и боксами и будет оперировать еще долго. Сильно сомневаюсь, что для расположения контролов на форме Вы будете оперировать тетраэдрами.

Топологическая модель может быть представлена структурами:

ID.
X.
Y.
Width.
Height.

Изменение, добавление или удаление отдельного атрибута приводит к реорганизации иерархии.

Злоупотребление оператором преобразования типов (dynamic_cast в C++ или as в C#) и, как результат, нарушение LSP.

        public IEnumerable<T> FilteredElements<T>() where T : class, IElementBase
        {
            foreach (IElementBase element in m_Elements)
            {
                T filteredElement = element as T;
                if (filteredElement != null)
                    yield return filteredElement;
            }
        }

            foreach (IProperty prop in type.FilteredElements<IProperty>())

    public interface IAttachedElement : IElementBase
    {
        bool Recursive { get; }
        bool CanAttach(object owner, object instance);
    }

    public interface IAttachedEvent : IEventBase, IAttachedElement
    {
        void AddEventHandler(object owner, object instance, Delegate handler);
        void RemoveEventHandler(object owner, object instance, Delegate handler);
    }

    public interface IAttachedProperty : IPropertyBase, IAttachedElement
    {
        object GetValue(object owner, object instance);
        void SetValue(object owner, object instance, object value);
        void AddValueChanged(object owner, object instance, EventHandler handler);
        void RemoveValueChanged(object owner, object instance, EventHandler handler);
        bool CanResetValue(object owner, object instance);
        void ResetValue(object owner, object instance);
        bool ShouldSerializeValue(object owner, object instance);
    }

    public interface IDomain
    {
        IType GetType(Type type);
    }

    public interface IElement : IElementBase
    {
    }

    public interface IElementBase
    {
        string Name { get; }
        IType Owner { get; }
    }

    public interface IEvent : IEventBase, IElement
    {
        void AddEventHandler(object instance, Delegate handler);
        void RemoveEventHandler(object instance, Delegate handler);
    }

    public interface IEventBase : IElementBase
    {
        IType EventHandlerType { get; }
    }

    public interface IProperty : IPropertyBase, IElement
    {
        object GetValue(object instance);
        void SetValue(object instance, object value);
        void AddValueChanged(object instance, EventHandler handler);
        void RemoveValueChanged(object instance, EventHandler handler);
        bool CanResetValue(object instance);
        void ResetValue(object instance);
        bool ShouldSerializeValue(object instance);
    }

    public interface IPropertyBase : IElementBase
    {
        IType PropertyType { get; }
        bool CanRead { get; }
        bool CanWrite { get; }
    }

    public interface IType
    {
        string Name { get; }
        Type SystemType { get; }
        IType[] BaseTypes { get; }
        IDomain Domain { get; }
        IEnumerable<T> FilteredElements<T>()
            where T : class, IElementBase;
        T Find<T>(string name)
            where T : class, IElementBase;
        bool IsExtended { get; }
    }

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

Какие задачи должно решать проектирование? Одна из них, конечно, -- достижение простоты, но простоты в каком смысле? Допустим, что проект должен развиваться. Т.е. систему придется расширять, переносить, настраивать, вообще по-разному изменять, и заранее нельзя предвидеть, как именно...

Из этого вытекает, что система должна быть спроектирована так, чтобы оставаться как можно проще после серии внесенных в нее изменений. Мы должны закладываться изменения в проект, т.е. мы должны стремиться к:
* гибкости;
* способности к расширению;
* переносимости.
Лучше всего это достигается попытками инкапсулировать те области системы, которые вероятно будут изменяться, и обеспечением такого способа работы, когда последующие проектировщики/программисты вносят изменения в одну область, на затрагивая другие. Это обеспечивается путем определения для данной разработки ключевых понятий и придания каждому классу исключительной ответственности за содержание всей информации, относящейся к отдельному понятию. В этом случае изменение можно внести, модифицировав только один класс. В идеале изменение одного понятия может быть произведено созданием производного класса или заданием другог аргумента шаблона. Естественно, этот идеал легче провозгласить, чем ему следовать.

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

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

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

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

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

Итак, рассмотрим, как можно подойти к проектированию компоненты. Поскольку зачастую это непростая задача, стоит разбить ее на этапы, чтобы логичным образом сфокусироваться на разных подзадачах.Как обычно, для этого нет универсального правильного способа. Однако, вот последовательность действий, которая кое-кому помогла:
[1] Выявите понятия/классы и их самые фундаментальные взаимосвязи.
[2] Уточните классы, определив набор операций над ними.
* Классифицируйте это операции. В частности, рассмотрите потребность в конструкторах, деструкторах и копировании.
* Рассмотрите минимальность, полноту и удобство/
[3] Уточните классы, определив их взаимозависимость.
* Рассмотрите параметризацию, наследование и воспользуйтесь зависимостью.
[4] Определите интерфейсы:
* Разделите функции на открытые и защищенные.
* Определите точный тип операций над классом.

1. Понятие идеальной программы. Почему выгодно ориентироваться на идеальность.
   
2. Этапы развития "кода" (как архитектуры, так и самого кода). Волнообразная модель.
   
3. Метод группировки разнородных сущностей. Ему посвящены этапы 1.3 и 2.2. Обычно группируют, находя похожие атрибуты и вынося их в базовые классы. В презентации говорится, что контекст для группировки нужно искать со стороны, т.е. не по похожести атрибутов, а потому, как и для чего объекты используются.
   
4. Схлопывание иерархии в класс.
   
5. Этапы свертывания. В частности, то, что задание одинаковых интерфейсов для различных сущностей — первый шаг к дальнейшему их свертыванию.
   
6. То, что различия между объектами "надо продвигать вниз" (на нижние слои).
   
7. То, что нижние слои поглощают средние.
   
8. То, что сначала нужно выявлять не классы/понятия, а действия. И проектировать конкретные структуры данных под эти операции (назовем их макро-операции или бизнес-функции).

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

WH>Ты заводишь абсолютно левые сущьности якобы для того чтобы не плодить сущьности...

std::vector<void *> vec;

WH>        public IEnumerable<T> FilteredElements<T>() where T : class, IElementBase
WH>        {
WH>            foreach (IElementBase element in m_Elements)
WH>            {
WH>                T filteredElement = element as T;
WH>                if (filteredElement != null)
WH>                    yield return filteredElement;
WH>            }
WH>        }
WH>

Мне как-то рассказывали на фирме Sun, что когда в 1995 году оставалось три дня до сдачи «Соляриса», им нужен был тест для Фортран-транслятора. Послали в Новосибирск заказ (у Sun была там своя группа) — сделать за два дня тест. Через неделю получили ответ, что через месяц будет замечательный тест на все случаи жизни.

1. Создать форму и контролы.
   
2. Правильно структурировать дочерние контролы (т.е. прикрепить дочерние элементы к родительским).
   
3. Правильно расположить контролы на форме и внутри других контролов.
   
4. Отобразить форму и контролы.
   
5. Обрабатывать команды от контролов.
   
6. И т.д. (список далеко не полон).

1. Структурная модель.
   
2. Визуальная модель.
   
3. Топологическая модель.
   
4. Динамическая модель.

Свертывание

* Средство борьбы со сложностью
* Количество полезных функций, выполняемых «кодом», остается тем же, а количество структур данных, модулей сокращается

A>Почему после refinement (как это по русски? ) type T = A1 по идее дальше во всех наследниках тип T должен иметь вполне конктретный тип Base1.A1, но компилятор продолжает упорно втыкать Base11.this.T Base1.this.T и т.д. Т.е. делкарация requires не дает возможности нормально наследоваться, т.к. все методы будут постоянно требовать переорпеледения типа и будут тотально несовместимы при любом refinement...

you're forgetting that when you write type T = A1, you're really writing type T=this.A1, so that
base11.T = base11.A1 (actually, type T=this.type#A1 and base11.type#T = base11.type#A1)

A>>Еще по теме хорошая статейка, где на scala рассматриваются два варианта реализации вычислителя в стороготипизированном языке и анализ проблем (а так же их преодоление )

trait Show extends Base {
  type exp <: Exp;
  trait Exp extends super.Exp {
    def show: String;
  }
  class Num(v: int) extends super.Num(v) with Exp {
    def show = value.toString();
  }
}

trait ShowPlus extends BasePlus with Show {
 class Plus(l: exp, r: exp) extends super.Plus(l, r)
                               with Exp {
   def show = left.show + "+" + right.show;
 }
}

trait ShowDblePlusNeg extends ShowPlus
                         with DblePlus {
  type exp <: Exp;
  trait Exp extends super[ShowPlus].Exp
               with super[DblePlus].Exp;
  class Num(v: int)
    extends super[ShowPlus].Num(v)
       with super[DblePlus].Num(v)
       with Exp;
  class Plus(l: exp, r: exp)
    extends super[ShowPlus].Plus(l, r)
       with super[DblePlus].Plus(l, r)
       with Exp;
}

    FileProcessor().ProcessLines(inFileName, outFileName, lines => lines.
        MapLazy(line => regexp match (line) {
        | @"[^:]+:(?<time>\d+:\d+:\d).*\]\s*(?<ip>\S+).*" => Some((time, ip))
        | _ => None()
        }).
        FilterOptionalLazy().
        GroupLazy((x, y) => x[0] == y[0]).
        MapLazy(seq => seq.
            CountAllToArray().
            SortInplace((x, y) => y[0] - x[0]).
            MapLazyFiltered
                ( (count, _) => count > 100
                , fun(count, (time, ip)) { $"$time $count $ip" }
                )
        ).
        FlattenLazy()
    );

    FileProcessor().ProcessLines(inFileName, outFileName, seq => seq
        .RegexpMapFiltered(@"[^:]+:(?<time>\d+:\d+:\d).*\]\s*(?<ip>\S+).*") //{time : string, ip : string}
        .Group(time)
        .Map(seq => seq
            .Count(count) //{count : int, time : string, ip : string}
            .Filter(count > 100)
            .Sort(-count)
            .Map($"$time $count $ip")
        )
        .Flatten()
    );

1. Загрузить форму из файла.
   
2. Редактировать форму.
   
3. Сохранить форму в файле.

1. Создать пустую форму.
   
2. Редактировать форму.
   
3. Сохранить форму.

• Считывание данных формы из файла.
  
• Создание пустой формы.
  
• Создание и добавление контролов к форме.
  
• Размещение контролов на форме в соответствии с заданным порядком.
  
• Отображение (визуализация) формы и контролов.
  
• Ассоциация обработчиков событий с контролами.

1. Создание контрола и добавление его к форме.
   
2. Удаление контрола (с формы и вообще).
   
3. Размещение контрола на форме.
   
4. Задание и редактирование визуальных параметров контрола.
   
5. Задание обработчика события для контрола.

1. Загрузить форму из файла.
   
2. Отобразить форму на экране и реагировать на события.

1. Считывание данных формы из файла.
   
2. Сохранение данных формы в файле.
   
3. Создание пустой формы.
   
4. Удаление формы.
   
5. Создание контрола.
   
6. Удаление контрола.
   
7. Добавление контрола к форме.
   
8. Удаление контрола из формы.
   
9. Размещение контрола на форме.
   
10. Размещение всех контролов на форме.
    
11. Отображение формы и контролов.
    
12. Создание обработчика событий.
    
13. Удаление обработчика событий.
    
14. Ассоциирование обработчика событий с конкретным контролом.

1. Структурная. К ней относится все то, что связано со структурой (с содержанием контролов внутри формы и внутри других контролов).
   
2. Визуальная. Отвечает за создание и визуализацию контролов (за цвет контрола, надпись на кнопочке или картинку).
   
3. Топологическая. Отвечает за расположение контролов на форме.
   
4. Динамическая. Отвечает за привязку обработчиков событий к конкретным контролам.

1. Parent ID.
   
2. ID.

1. ID.
   
2. Type (button, listbox, combobox, checkbox, radiobutton, edit и т.д.).
   
3. Text.
   
4. Picture.

1. ID.
   
2. X.
   
3. Y.
   
4. Width.
   
5. Height.

1. ID.
   
2. Col.
   
3. Row.

1. ID.
   
2. Handler.

    public interface IElementBase
    public interface IEventBase : IElementBase
    public interface IPropertyBase : IElementBase

    public interface IAttachedElement : IElementBase
    public interface IElement : IElementBase

    public interface IProperty : IPropertyBase, IElement
    public interface IEvent : IEventBase, IElement
    public interface IAttachedProperty : IPropertyBase, IAttachedElement
    public interface IAttachedEvent : IEventBase, IAttachedElement

    public interface IType

1. Почему участники обсуждения
   Автор: igna
   Дата: 03.03.07
   так и не пришли к "очевидному" решению, которое описано в презентации?
   
2. Почему Вы не уловили связь между задачей, изложенной в презентации, и обсуждением про квадрат и прямоугольник
   Автор: igna
   Дата: 03.03.07
   ? На мой взгляд, эта связь тоже очевидна.

ГВ>>Я не зря упомянул об усреднённых цифрах. Средняя величина не колеблется в пределах "от" и "до". Она — единственная и неповторимая.

КЛ>Простите, но я в упор не понимаю, как проект, продолжительностью в год, можно "усреднить" до проекта, в продолжительностью в месяц.

ГВ>>>>Вот эта картинка на основе каких данных получена?
КЛ>>>На основе анализа ряда примеров. Один из них приведен здесь. Но есть и другие.
ГВ>>Сколько их было всего? И ещё: что у вас по оси ординат?
КЛ>Сложность системы: количество модулей, классов и т.п.