Как мне создавать классы при выполнении пользовательского интерфейса?

Question

Я замечаю шаблон, когда я программировал C++ и backend (на C# или на любом языке), все мои классы аккуратные и аккуратные. Недавно я заметил, что весь мой код находится в классе, и у меня буквально есть> 50 функций в нем. Теперь я понимаю его, потому что я делаю пользовательский интерфейс. Если бы я мог их разделить по страницам или формам/диалогам, у меня были бы файлы LOT MORE, больше строк кода и более длинная строка кода. Если я их отделяю, я получаю ту же проблему (больше файлов, строк, более длинных строк). Очевидно, что чем меньше строк, тем лучше (меньше кода = меньше для отладки, изменения или прерывания во время обслуживания).

Этот конкретный проект представляет собой 5k строк с 2k из Интернета или библиотек. Все мои файлы .cs: < 1k строк. Является ли это приемлемым, хотя у меня есть 50 + функций в одном классе?

Бонус: Я замечаю, что большинство из этих функций вызывается только один раз. и поместить определенные блоки кода (например, одна функция делает два вызова в db), поскольку их собственная функция затрудняет редактирование, поскольку они делятся между файлами и этим значением функции шара. Итак, я вроде как не знаю, что делать. Я создаю больше классов, чтобы уменьшить количество функций (для каждого класса, он будет увеличивать вызовы функций в целом и уже большинство из них вызывается только один раз)? Как мне создавать классы, выполняющие интерфейс/пользовательский интерфейс?

Answer 1

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

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

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

Пользовательский интерфейс должен быть восприимчивым ко всем неправильным, непоследовательным или непредвиденным вводам и действиям пользователя. Хотя мы, как дизайнеры, можем заранее подумать об этом (и даже свести его к минимуму такими вещами, как Combo-box и Command Buttons, a). все это требует дополнительного обратного кода, и б) все эти вещи могут тогда взаимодействовать по-разному.

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

И, наконец, чем сложнее проект, тем сложнее будет пользовательский интерфейс, и чем больше это должно продолжаться.

Управление действиями машины, заданными входами и выходами, которые мы, как программисты, явно определяем, EASY по сравнению с прогнозированием, управлением и обработкой случайных причуд, наложенных на наши вещи пользователем. Если бы они обратили внимание, верно?

В любом случае, я считаю, что все это потому, что код для пользовательского интерфейса становится больше и сложнее. Что касается того, как разгадать его с помощью майнинга, ребята сверху покрыли его. Аннотация двух. Я проектирую форму. Я определяю меню для ввода пользователем данных и/или указываю, что они хотят сделать дальше. Затем я определяю способ, которым эта форма может передавать эти вещи с моими четкими, чистыми классами задних конечностей. Затем я предоставляю механизмы проверки и средства, помогающие контролировать пользователя при навигации по нему (например, кнопка не включена, пока пользователь не выберет элемент из списка ...).

Комплекс.