Что делать, если класс формы становится слишком большим?

Question

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

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

Редактировать : Так что я использую частичные классы и должен сказать, что они мне не очень нравятся. Я не уверен, что делать в этот момент.

Я могу вернуться к использованию блоков регионов, так как не уверен, что пользовательские элементы управления помогут моей проблеме вообще. Честно говоря, я не возражал против того, чтобы блоки региона так сильно. Этот класс был единственным местом, где я их использовал, и он довольно хорошо организовал различные разделы кода (обработчики событий меню, обработчики событий Toolstrip, поддержка перетаскивания и т. Д. И т. Д.).

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

Answer 1

1000 строк кода - ничто, и это не должно быть основанием для рефакторинга вашего кода. Рефакторинг вашего кода там, где это имеет смысл; не только потому, что класс содержит больше строк кода, чем другие ваши классы. Некоторые классы требуют больше кода, чем другие, и это совершенно нормально.

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

Я должен еще раз напомнить вам, не разбивайте ваш код на , просто , чтобы уменьшить количество строк кода.

Answer 2

Если вы еще этого не сделали (вы не упомянули об этом), я бы разделил различные отдельные элементы управления на пользовательские элементы управления.Вы можете обрабатывать все события из класса UserControl и выставлять только те события, которые родительская форма должна обязательно обработать.Скорее всего, их будет немного, и это значительно сократит обязанности вашей основной формы.

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

Answer 3

Вы можете либо разделить функциональность на отдельные классы (например, создать UserControls, как предложил Эд), либо подумать об использовании partial классов (где один класс может быть разделен между многими файлами).Я обнаружил, что partial классы удобны для группировки связанных кусков кода, когда размер файла "main" становится большим.Иногда это первый шаг к реорганизации этих частей кода в отдельные классы и / или элементы управления.

Трудно дать конкретную рекомендацию, не видя код, но это некоторые из ваших вариантов.

Answer 4

Я бы предложил использовать больше решений ООП.Не добавляйте UserControls, поскольку вы добавляете больше * сложности *.Давайте попробуем сохранить сложность, которую у вас уже есть , но сделайте вещи более понятными , потому что это то, что вы действительно просите, я полагаю.

DI вроде .На практике, если вам нужно обрабатывать много событий для большого количества контролов, создайте ControlManagers, который принимает в ctor элемент управления и подписывается на его события.

Так что для каждого элемента управления у вас будет свой менеджер.

Преимущества:

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

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

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

РЕДАКТИРОВАТЬ

Пример псевдокод :

UserControl1 mycontrol1; UserControl2 mycontrol2; 
public class MyControl1Manager  {
    public MyControl1ManagerFor1  (UserControl1 uc1) {
          //subscribe to events of uc
          // here all code to handle events
    }
     public MyControl1ManagerFor2  (UserControl2 uc2) {
          //subscribe to events of uc
          // here all code to handle events
    }
}

и где-то в коде:

   MyControl1ManagerFor1  controlManager1 = new MyControl1ManagerFor1  (mycontrol1);
   MyControl1ManagerFor2  controlManager2 = new MyControl1ManagerFor2  (mycontrol2);

Примерно так.

Надеюсь, это поможет.

Answer 5

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

SideViewHelper sideView = new SideViewHelper(parentForm, gridControlMaster, gridControlDetail, buttonSubmit);

Вся логика, которая обрабатывает события gridControl, события кнопок обрабатываются внутри вспомогательного класса.

После инициализации главной формы (parentForm) может изменить состояние многих элементов пользовательского интерфейса одним вызовом метода ViewHelper.

Эти классы созданы для этой единственной формы и настолько легки, насколько это возможно.