Каково ваше правило для разделения класса View Controller на VC и пользовательский класс?

Question

Классы контроллера представления AFAIK должны использоваться только для управления их представлениями, IBActions, IBOutlets и другими связанными с экраном представлениями.Это означает, что класс контроллера представления должен быть максимально легким, касающимся управления его корневыми и внутренними представлениями.Однако иногда мы испытываем желание оставить код внутри класса контроллера представления и не переходить к другому пользовательскому классу.

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

ИМХО, если вы будете очень обеспокоены 100% -ной чистотой и чистотой, вы потратите больше времени (ну, по крайней мере, на начальных версиях приложения), но вы никогда не узнаете, будет ли продукт развиваться илиесли он будет заброшен.Всегда есть некоторые компромиссы, с которыми сталкиваются разработчики.

Было бы интересно узнать, какие внутренние правила вы используете для разработки своих классов.

Answer 1

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

Действительно сложный шаг - быть строгим в своем решении и не быть ленивым :), поскольку по вашему вопросу ясно, что вы понимаете, как важно быть строгим в своем коде!

Answer 2

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

Мы склонны использовать статический класс для простых вещей, например класс DateUtility для разбора и форматирования дат в разных форматах.

И агрегация для больших вещей, то есть загрузчик.

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