Это хорошая идея, чтобы наследовать от стандартных виджетов и установить мои собственные значения по умолчанию в C #? - PullRequest
3 голосов
/ 14 марта 2011

При разработке приложения в Visual Studio (C #), если я знаю, что у меня будет определенное количество DataGridViews, которые имеют одинаковые свойства (такие как ширина, высота, цвет, некоторые другие свойства, такие как: отключить параметр для непосредственного редактирования строк, и т. д.) можно ли создать собственный класс («myDataGridView»), который наследует класс DataGridView, и внести в него все корректировки, а затем просто создать экземпляр этого класса позже в коде? Как это:

//my class:
class myDataGridView : DataGridView 
{
    this.BorderStyle = <someValue>
    this.ColumnCount = <someValue>
    //etc.

    public void method1() 
    {
    //some code...
    }
    public void method2() 
    {
    //some code...
    }
}

//instantiate it somewhere:
myDataGridView dgv1 = new myDataGridView();
myDataGridView dgv2 = new myDataGridView();
myDataGridView dgv3 = new myDataGridView();

Это нормально в отношении принципов ОО? Мой друг говорит, что ставит код вроде

this.BorderStyle = <someValue>

в классе myDataGridView - плохая практика, потому что настройка таких свойств приведет к переопределению свойств dataGridView, которые некоторые другие разработчики могут корректировать визуально в Visual Studio, если вы понимаете, что я имею в виду. Это имеет значение? Я имею в виду, что если я хочу рассматривать мой DataGridView как объект, тогда он может иметь свои свойства и поведение, верно? И иметь код, который корректирует свойства DataGridView в моем классе, нормально, читабельно, и любой другой разработчик, который хочет изменить некоторые свойства, может изменить его в классе myDataGridView. Это такая практика плохо или неправильно? Если это так, то какова лучшая практика, когда вы знаете, что в вашем приложении будет много DataGridViews с одинаковыми свойствами / поведением? Спасибо.

Ответы [ 2 ]

5 голосов
/ 14 марта 2011

На мой взгляд, это не правильный подход.Наследование элементов управления только для нескольких модификаций свойств не имеет смысла.Вы не вводите никакого дополнительного поведения в элемент управления, скорее попробуйте написать некоторые вспомогательные методы инициализации, чтобы сделать это.

1 голос
/ 14 марта 2011

Если вы беспокоитесь о том, что ваши изменения в свойствах перезаписываются визуальными настройками разработчика, вы можете скрыть их, используя атрибут [Browsable (false)].

Однако, с точки зрения ООП, наследование не поощряется, если это действительно не необходимо. Существует золотое правило: «Пользуйся композицией, а не наследством». Как это. __curious_geek сказал, что не очень хорошая идея наследовать элементы управления для установки свойств таким способом, но это хорошая практика, чтобы всегда иметь общий базовый класс для ваших бизнес-классов и экранов. Вы можете сделать функцию в базовом классе всех экранов, чтобы правильно настроить сетки для вас так, как вы хотите. Если вы сделаете его виртуальным, вы можете переопределить его в производных классах, чтобы при необходимости настроить поведение для каждого случая.

...