У меня есть процесс, который я автоматизирую в виде пошагового мастера с графическим интерфейсом.В основных терминах это длинный набор вычислений, который в конце концов дает вам спецификации для дизайна.
Он разбит на 6 блоков, и каждый последующий блок зависит от результатов и входных данных предыдущего блока.Первоначально я думал о том, чтобы сделать 6 отдельных «вычисляющих» классов, пока не начал думать о том, чтобы передать значения «как бы по линии».
Я только что выполнил аналогичную задачу, когда я ударил GUI в уже реализованной, очень похожей программе, где предыдущий парень делал это с отдельными классами, и было довольно трудно отследить их всех и убедиться, чтоони были переданы в правильные классы.
Я думал объединить их всех в один большой класс.У него было бы 6 методов, в которых я мог бы собирать и давать входные данные из каждого раздела графического интерфейса, и он делал бы свои вычисления за кулисами, а затем, после того как все 6 были вызваны, я могу просто создать один метод вывода, который собирает все важныеоценивает и выплевывает их.
Я склоняюсь к одному классу, потому что он проще, более похож на «черный ящик», и мне не нужно иметь грязные конструкторы, в которые я передаю ранее сделанный объектдо такой степени, что последний класс получает все 5 предыдущих, переданных ему, чтобы он мог использовать значения.
Теперь, когда я думаю об этом, этот один класс может быть «моделью» дизайна MVC и быть хорошим отдельным классом, к которому Controller и View получают доступ только через 7 видимых, очень простых методов.
Я также думаю, что это уменьшило бы объем памяти, так как с 6 отдельными классами они должны были бы существовать в течение той же продолжительности, что и 1 большой класс, за исключением того, что все внутренние компоненты Object реплицировались 6 раз.
Я вполне уверен в использовании одного класса, но я хотел спросить, является ли это ужасной ошибкой, идет ли она вразрез со всеми вещами, ориентированными на объекты и если я упускаю какое-то очевидное, гораздо лучшее решение.