GysВ С++ все легко решается с помощью множественого наследования с виртуальным базовым классом, в С# хз...онли интерфейс наверно.
Легко, но не очень удачно. Не лучшим образом с точки зрения повторного использования и с других точек зрения. Если функциональность, не являющаяся по своей сути монополией объекта, нарушающая для него принцип сильной связности (high cohesion) оказывается все-же "захардкодена" в этом самом объекте, то это не очень удачно. И повторное использование такой функциональности затруднено, и получены монолитные классы-всемогутеры, самостоятельно решающие разнородные задачи.
Многие (почти все) эксперты в области проектирования сходятся во мнении, что в дизайне следует стремиться не к монолитным классам, а отдавать предпочтение разработке маленьких, очень узко заточенных, минимальных классов. Направленных на одну задачу, повторно используемых и простых. "Ясность лучше хитроумия" (с). И эти маленькие "зернышки" реализации подключать уже через композицию к другим классам.
И вообще-то, широко известно, что множественное наследование реализаций (именно реализиций, а не интерфейсов ) - неудачный дизайн. Уже об этом во многих известных книжках гуру написано. Например, Саттер в "решении сложных задачах по C++" дает совершенно ясную рекомендацию: избегайте множественного наследования от более чем 1 абстрактного класса .

Mumbo,
очепятка вкралась. следует читать так:
избегайте множественного наследования от более чем 1 НЕабстрактного класса.

J.dсделайте один класс А с динамическим набором свойств,
в конструктор передавайте экземпляр класса Б возвращающий заготовленный набор свойств.
если требуется храните в экземпляре его "тип".

))

Такая "плагинная" конструкция очень хороша, но не всегда применима.
Если каждый из аспектов функциональности (плагинов) автономен, и не требуется поддержать особую взаимосвязь между некоторыми плагинами, и необычную взаимосвязь между плагином и его "хостом", то все шикарно. Делаем один класс Ящик. И его динамически оснащаем автономными плагинами. Если такой вариант по условиям задачи подходит - его и использовать.

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

Предположим, что в примере требуется, чтобы совместно сыграли "габариты" и "цвет". Допустим, чтобы при изменении габаритов ящика его цвет менялся (при сжатии меньше некоторого объема он бы краснел, а при растяжении больше другого значения объема - синел).

Некоторые альтернативы реализации:
(1) Плагины знают о специфике других плагинов и хоста. Но тогда эти плагины или потеряют свойства повторного использования (только для ящиков и тд) или будут генерировать очень много повторно не применимых подклассов.
(2) Хост знает о специфике плагинов. То есть, ящик бы знал, что вот это не просто какой-то плагин, а именно габариты. Ловил от него события об изменении, с их своеобразными сигнатурами. И в обработчике события управлял бы плагином цвета.
(3) Чтобы были разнообразные связующие сущности, коннекторы, которые реализуют связки и зависимости, и хост ими тоже динамически бы оснащается. Коннекторы учитывают специфику плагинов аналогично тому, как это делает хост в альтернативе (2). Но тут коннектор, неправильно работающий, может испороть всю работу хоста.

Наиболее простым, надежным, и удовлетворяющим масштабу требований представляется подход (2). Причем реализованный не в ран-тайме, а в дизайн-тайме. Тут и наследование можно применить в разумной мере, и инкапсуляция всех сторон соблюдена, и все просто, а простота лучше сложности.