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

Question

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

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

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

Answer 1

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

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

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

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

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

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

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

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

Комплекс.