#include в C#

Как известно C# множественное наследование не поддерживает, но мне надо всем классам в моей программе добавить ряд общих методов и полей. К сожалению все эти классы уже унаследованы от каких-либо других классов (Form, Component и т.п.), поэтому воспользоваться наследованием я не могу. Реализовать все это через интерфейс -- не удобно, т.к. придеться переписывать (копировать) реализацию в каждый мой класс. Я вижу следующие пути, но к сожалению не знаю как их реализовать:1) Переопределить базовый класс Object2) Использовать аналог C++ директивы #includeПрошу помочь с реализацией моей идеи.
14 ответов

А, может, лучше сэмулировать множественное наследование: http://www.codeproject.com/KB/architecture/smip.aspx?


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


magnitudo, а какие ещё могут быть идеи кроме замены наследования агрегацией?  Такие ограничения в наследовании зашиты в язык на концептуальном уровне...


Ну я предложил два варианта, которые я не знаю как реализовать.


magnitudo, первый вариант реализовать не получится, а второй в итоге выльется в такой же копи-паст, как и вариант с заменой наследования агрегированием.


magnitudo, попробуем решить проблему методом Йоды - скажи зачем тебе надо добавить методы и поля, как именно ты их будешь использовать - и мы убедим что поля добавить не нужно тебе. 


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


Extension Methods возможно помогут. Но имхо - если такая трабла - значит скорее всего просто где-то подход к решению задачи неправильный)


скажи зачем тебе надо добавить методы и поля, как именно ты их будешь использовать - и мы убедим что поля добавить не нужно тебе. 
В общем мне нужны следующие поля:ObjectID - уникальный код объектаConfigID - идентификатор конфигурационного файла (в перспективе это будет не просто файл, а допустим поток с удаленной машины) в котором храняться параметры моего объекта (файл .xml)ConfigPath - Xpath путь к параметрам объекта, которые храняться в файле ConfigIDи ряд методов типа ReadConfig, WriteConfig.Причем часть объектов может быть контейнерами для других объектов, т.е. структура конфигурациооного файла получается вложенная.


magnitudo, а общая цель какая? Просто пробежаться по всем-всем-всем объектам приложения и подтянуть определенные свойства из конфига? Т.е. понятно зачем сохранять в конфиг свойства, например, контролов или форм. Или зачем сохранять туда какие-то данные. Но не уверен насколько нужно но запихивать все это в один конфиг.Если все это делается для сохранения настроек - позиции, шрифтов - посмотри в сторону marker-интерфейсов и рекурсивного обхода дерева контролов. Выставляй свойства через reflection. Если для локализации, и ты собираешься подтягивать строки с какого-то сервера локализации - посмотри в сторону Custom Resource Manager....


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


 динамическая генерация формы с контролами (возможно вложенными) на основе конфигурационного файла. И контролем доступа пользователя к отдельным контролам.
1-в-1 одна из подзадач в проекте с моей прошлой работы  Был дизайнер форм. Формы со всеми вложенными контролами и их свойствами сериализовались в xml и хранились в базе...таких вопросов как у вас ни у кого даже не возникало...


таких вопросов как у вас ни у кого даже не возникало...
Ну и что мне с этим теперь делать   Как человек более опытный, поделитесь секретом как вы отличали формы друг от друга (10 форм типа AnyForm) и реализовали контроль прав доступа пользователей к формам и контролам?


magnitudo, а какой смысл каждую из 10 форм отличать друг от друга?у нас была ERP-шка, форма могла представлять из себя, допустим, форму для редактирования какого-либо справочника(читай "таблицы"). На разные действия с этой таблицей в БД прописаны права...а контроль возлагался на бизнес-логику и программа сама решала на основе данных из базы кому давать редактирование, а кому - нет...потом, вроде, этот функционал перешёл на уровень субд в виде хранимых процедур...но точно я уже не помню сейчас...это всё было как раз, когда я уходил уже...