Я понимаю, что уже много чего сказано по этой теме, и что нормального (в понимании программиста, всю сознательную жизнь писавшего на Delphi) наследования в visual studio 2005 нет, НО... Непонятно одно - как с этим со всем жить??? Есть ли какая-то альтернатива наследованию? Кто как обходит эту ситуацию? Поделитесь опытом. Не понимаю, как можно написать более-менее серьезный проект без наследования!?
P.S.: Помогите человеку заново обрести веру в .net-программирование.

язык какой ?
c# вполне себе имеет наследование :

в сравнении с Delphi как раз отличий почти нету.
в сравнении с с++ есть : нет множественного наследования реализации, нет приватного и защищенного наследования....

Я про наследование форм и последующее их редактировании/отображении в дизайнере.
Вот, например: http://www.gotdotnet.ru/Forums/Windows/436460.aspx

mlitkin, я не знаю как там в 2005-ой студии, но в 2008-ой никаких проблем с визуальным наследием форм нет.
для компонент формы, которые ты хочешь давать изменять потомкам ставишь модификатор доступа protected и без проблем редактируешь их в редакторе.
собственно говоря это вполне ожидаемое поведение, такое же как и при наследовании других классов.
возможно вы просто не до конца разобрались и в 2005-ой данный вопрос также решается?

не делайте поспешных выводов.
Да еще в такой категоричной форме 

гыгыгы сначала почитай любую книжку по C# - наследование имеецо))
а чебы наследоватца от любой формы - тут так же само как и с другого класса:

и все...
вобшем сначала думай потом пиши  

Не ждите нормального ответа от людей, которіе НЕ работали никогда на Делфи... они никогда не видели по-настоящему удобного дизайнера. Это как при совке не могли себе представить 100 сортов колбасы на прилавке да к тому же без очереди в километр.
Но наследование в С# есть, просто все дочерние компоненты по-умолчанию шарп делает private, поэтому их не должно быть видно (и соответственно невозможно редактировать) в потомках, а "ставишь модификатор доступа protected..." не всегда и не для всех компонентов помогает (например DataGridView в потомках будет закрыт "замочком" даже при выставленом public)
Дизайнер студии не умеет с наследованием грамотно работать, поэтому некоторые визуальные компоненты на форме вам нивжисть не изменить в потомках редактором. Ручками в коде - возможно, но грабель там понатыкано... 
Например, для организации мультиязыковой поддержки стандартным методом является выставлять для формы свойство Localizable=True, потом для каждого языка выбрать соответствующий Language и для каждого визуального компонента на этом языке прописать нужные свойства (Text, к примеру). Соответственно студия создаст для формы набор ресурсных файлов для каждого языка. Но как получить записи в ресурсных файлах для колонок от DataGridView, который "на замке" и колонки которого "прикручено ручками" ?!!

Я выкручивался (если упростить) так:
1) проверяю компонент на "наследственность". Ставлю его на голую форму (обязательно "ставишь модификатор доступа protected..." или public), компилирую, создаю форму-наследник от той и смотрю "замкнут" ли компонент. Еслы не замкнут - можно отложить шаманский бубен до лучших времен.
2) Если компонент "закрыт", то в родительской форме я этот компонент НЕ ставлю на форму вообще но делаю под него поле (свойство) соответствующего типа (например protected DataGridView dgv) в "партиал" определении формы сам, ручками. Далее в нужных методах (например сортировка, поиск по гриду) я использую эту переменную (dgv). А вот в форме-потомке я реально кидаю на форму DataGridView, даю ему имя например DGV, могу с ним делать всё, что душе угодно (колоночки на нужных языках). A в конструкторе формы-наследника дописываю после InitializeComponent(); dgv = DGV;

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

с чего вы это взяли


а что есть такой дизайнер "Делфи"

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

Когда нет возможности, часто ищутся пути при которых нет необходимости...
Я об том и говорю, что прошедшим С++ у которого "никакого дизайнера", дизайнер от VS - уже счастье.

А "второстепенные" задачи не требуют решения? Или в их решении использование наследования становится преступлением?

Так может тогда выбросить эти окошки и вернуться к добрым старым текстовым интерфейсным наработкам?

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

Есть user-controls и есть Forms
Для наследования используются классы Form & UserControl соответственно. Можно наследоваться от своей формы так же, как и от класса Form. Аналогичная ситуация с наследованием от собственного контрола.
Таким образом вид "наследования форм" существует.

Ну а то, что какие-то элементы в классах Form или UserControl являются public, protected, private - это (извините меня) признаки ООП .... и тот, кто не признает право любого класса иметь свои закрытые члены (хотя бы для защиты от ошибок своих же потомков), тот немного ... неправ 

Но Вы, IApple, вполне можете наследоваться от любого класса в иерархии UI (от Control или даже от object) и определить все члены класса открытыми. Потом компилируете класс и библиотеку и ссылаетесь на нее в проекте, вместо ссылки на System.Windows.Forms

Вот так и решатся все проблемы

Я писал, про наследование форм, что в нем необходимости нет, а то о чем вы говорите это наследование логики (см. MVC или PoEAA Фаулера).  Т.е. создаем одну форму, как я уже писал, а наследование делаем в логиках. Т.е. у вас одна форма (представление) и класс логики для этой формы. В случае необходимости создаем класс наследник логики или вешаем несколько логик на одну форму. Можно сделать фабрику логик, которая в зависимости от юзверя создает нужный ему интерфейс. В вашем случае можно еще и UserControl создать.


Я за наследование, но против наследования форм, если вы внимателльно прочитали, то там написано, что нет необходимости в наследовании интерфейса, а есть необходимость в наследовании логики или в применении нескольких логик к одному представлению (форме). Т.е. форма она отвечает только за отображение данных, а уже отображаемые данные поставляются логикой. При такой модели мы можем легко и просто от одного представления перейти к другому (от Windows к Linux аль Web) или создать несколько видов представлений (Win и Web) одних и тех же данных.



Я писал, что работал с Делфи, потом с VS и считаю, что удобство это дело привычки. А в проекте в котором нет никакого дизайнера был создан 
класс Manager Control - ов, который красивенько выравнивал (сам!!!) контролы на панелях. Еще раз повторюсь что удобство дизайнера дело привычки. Любому перешедшему к Delphi с VS дизайнер Delphi будет казаться неудобным, а из Delphi в VS наоборот.

Я не имел ввиду, что юзабилити не важная задача, но она по моему мнению занимает в 10-ки если не 100-ни раз меньше времени и усилий, чем написание бизнес-логики, поэтому ее легко изменить в случае необходимости. И нафига классный интерфейс с неработающей логикой, что вы клиенту скажете: "Смотрите какой классный интерфейс, но правда все остальное неправильно работает "?
P.S: Модераторы: Извиняюсь что тема превращается в религиозные войны.

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

Её легко изменить в случае неодходимости если использовать наследование. Если у меня в суперсложном по логике приложении имеется 100 похожих простых справочников, то намного легче изменить их вид, если они наследуются от одного предка. Меняеш предка - все синхронно изменились. В противном случае, прийдется лезть в каждый из сотни и добавлять ручками-с.

Спасибо за понимание. Но, почитав ответы на свою тему (и вот здесь тоже: http://sql.ru/forum/actualthread.aspx?bid=...8632&pg=-1), я прихожу к выводу, что видимо для .net-проектов действительно применяется иной (относительно той же делфи) подход к проектированию UI... Возможно, действительно подход с одной формой и наследованием бизнес-логики в большинстве случаев оправдывает себя, т.к. с наследованием форм в делфи тоже есть определенные неудобства. Ну например, если есть 30 форм, наследованных от базовой, то изменив положение какого-то контрола в базовой форме, можно поиметь проблемы с взаимным расположением контролов в дочерних формах. В этом случае бывает необходимо открыть каждую и расставить все по местам... В случае с одной формой и несколькими логиками такой проблемы не будет.

Gelis 

Прочитал, как применить в моем конкретном случае? Если до банальности упростить условия до таких (уж не взыщите, что у меня так сильно к визуальным компонентам привязано): тулбар на 2 кнопки и менюшка на аналогичных 2 пункта меню (сортировка и поиск) для грида на форме.

Тут совсем не понимаю. Если у меня два однотипных (визуально) справочника Городов и Улиц, то как это стыкуется с тем, что "создаем одну форму" ?

Тоже, очень было бы интересно посмотреть на код.