У меня есть приложение "тестировщик". В любом тестировании есть минимум 3 секции:
Дабы контролировать введённые данные в первой секции, выводить новые билеты по нажатию на кнопку "Следующий билет", также показывать прогресс и т.п. по 2 пункту списка и выводить результаты теста нужно создать некий class TestingController
.
В нём такого рода код (я не писал ещё кучу нужных вспомогательных полей, свойств и методов, которые нужны для каждой секции):
class TestingController
{
/// ПЕРВАЯ СЕКЦИЯ (НАСТРОЙКА И НАЧАЛО ТЕСТИРОВАНИЯ)
// Время тестирования
DateTime TestingTime { get; set; }
// Количество билетов
int TicketsAmount { get; set; }
// Этот метод будет вызываться при нажатии на кнопку "Начать тестирование"
void GetStarted()
{
//// Выводим вторую секцию
}
//////////////////////////////////////////////////////
/// ВТОРАЯ СЕКЦИЯ (БИЛЕТЫ)
// Вывод нового билета
void GetNextTicket()
{
//// код замены значений у UIElement'ов
}
// Выводим "пройдено_билетов/осталось"
void OutputTestingProgress()
{
//// код
}
// Выводим оставшееся время на прохождение теста каждую секунду с помощью класса Timer
void OutputTimeLeft()
{
//// код
}
//////////////////////////////////////////////////////
/// ТРЕТЬЯ СЕКЦИЯ (РЕЗУЛЬТАТЫ)
void GetResults()
{
// выводим третью секцию
}
}
Стоит ли так делать: объединять весь функционал 3-х секций приложения в один класс_контроллер? Или же всё таки более правильным будет разделить этот класс на 3 таких же контроллера для каждой секции, в каждом из которых будут хранится их свойства и методы для отображения секции?
Помогите, пожалуйста! Я новичок в создании приложений и не очень-то и понимаю как необходимо правильно выстраивать архитектуру приложения.
Не хочется писать плохой код).
Моё мнение: объединять не стоит. Есть такой термин в программировании -- god object, когда у класса становится очень много ответственности. Вы сейчас движетесь по направлению к созданию такого класса. Вы уже сейчас вербализовали, что у вас есть три секции, что у них есть три разные ответственности ("начать тестирование", "отрисовка билетов").
И вот это стремление обьединить разное в единое -- путь к god object, который делает сразу всё. А ещё он не только кнопки отрисовывать будет, но и кофе варить и рассчитывать проценты по кредиту.
При этом фактически вы некоторые разные ответственности почему-то объединили с другими. Например, для меня очевидно, что ответственность "начать тестирование" и "настройки приложения" -- это совершенно разные вещи, но вы их мысленно объдиняете в "секция один". Нумерация -- вообще плохой советчик в этом вопросе. Если вы напишете public class Section1 вроде как всё логично, но если вы будете давать имя по смыслу, значению, ответственности -- то всегда насторожитесь, когда в названии класса вдруг появляется слово "And": КлассНачатьТестированиеИещёНастройки.
В вопросе разделения ответственностей вообще крайне редко приходится что-то объединять, как раз ООП подход рекомендует дробить классы как можно меньше.
Поэтому вам не нужен один мега-контроллер, вам нужно три (и даже более) независимых класса, которые будут отвечать только за свою часть.
Айфон мало держит заряд, разбираемся с проблемой вместе с AppLab
Как ограничить вращение объекта по одной из осей, например, на 30 градусов? Объект двигается зажатой кнопкой мыши
Хотите улучшить этот вопрос? Переформулируйте вопрос так, чтобы он был сосредоточен только на одной проблеме
Нужно сделать плавный переход между двумя блоками, но не знаю как это можно реализоватьс #C4C4C4 к #000000
Вобщем делаю я меню и просмотрел код элемента появился вот этот длинный прямоугольникМеню находиться в теге section