Использование классов для организации кода?

Question

На данный момент мой код Form1 очень тяжелый, в основном полный меню и событий управления.Одна вещь, которую я хотел бы сделать, это каким-то образом организовать ее, чтобы я мог развернуть или свернуть «связанный код» (в Visual Studio).

Моя первая попытка заключалась в размещении кода, относящегося к главному менюНапример, внутри вложенного класса MainMenu, который был внутри класса Form1, чтобы я мог просто свернуть вложенный класс, когда он мне не нужен.Это привело к возникновению всевозможных проблем (то есть я не смог найти способ настроить главное меню внутри этого вложенного класса).

Есть ли более простое решение, которое я пропускаю?Или кто-то может пролить свет на то, почему моя идея вложенного класса неверна?

Answer 1

Хотя ответ @ testalino , безусловно, выполняет то, что вы просите, я бы сказал, что ваша реальная проблема, вероятно, связана с дизайном кода.Скорее всего, класс формы просто содержит больше кода, чем нужно, и что некоторые из него должны перейти в другие классы.

Если все сделано правильно, это может дать вам некоторые преимущества:

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

Answer 2

Вы можете использовать #region и #endregion для организации кода в классе. Эти области затем разрушаются.

Answer 3

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

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

В будущем вы можете попробовать разные подходы к отделению пользовательского интерфейса от логики приложения, например, изучить паттерны MVP / MVC.

Answer 4

Используйте частичное ключевое слово class для разделения вашего класса на несколько файлов.

Answer 5

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

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

Существует множество хорошо известных шаблонов, которые могут помочь вам организовать свой интерфейс и код домена. Эта серия рассказывает именно об этом и знакомит вас с шаблонами MVC, MVP, EventAggregator и многими другими.Он обсуждает шаблоны в контексте оконных форм так, как вам нужно.

Answer 6

Я согласен с тем, что говорят другие ответы о группировании одинаковых обработчиков событий в #regions, учитывая большое количество событий.Кроме того, если сам код в обработчиках также объемный, вы можете подумать о том, чтобы преобразовать его в классы логической бизнес-логики.Пример:

псевдокод до:

private void SomeButton_Click(...)
{
    using (FileStream fs = ...)
    {
        fs.Write(some form data);
        fs.Write(some more form data);
    }

    DoMoreBusinessLogicStuff();
    ...
    // lots more stuff
    ...
}

псевдокод после:

private void SomeButton_Click(...)
{
    IBusinessObject obj = new BusinessObject(injectable form data);

    using (IPersistence store = new FilePersistence(...))
    {
        obj.Persist(store);
    }

    obj.DoBusinessRules();
}

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

Answer 7

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

В VB:

''' <summary>
''' 
''' </summary>
''' <remarks></remarks>

In C #

/// <summary>
///
/// </summary>
/// <remarks></remarks>

Answer 8

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

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

Если Form1 становится очень тяжелым с кодом, то это потому, что у вас слишком много всего происходит в Form1? Не могли бы вы выделить его в другую / новую форму?

Answer 9

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

Вы должны стремиться выразить объекты, которые у вас есть, в виде отдельных бизнес-классов в вашем коде: один класс, один файл.Есть ли какая-то конкретная причина, по которой вы этого не делаете?