Как можно всегда писать две-три тысячи строк класса контроллера?

задняя часть
Как можно всегда писать две-три тысячи строк класса контроллера?

«Это третий день моего участия в ноябрьском испытании обновлений. Подробную информацию об этом событии см.:Вызов последнего обновления 2021 г."

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

  • слишком много длинных функций
  • В классе много полей и функций

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

1 Модульность программы

Задумывались ли вы о том, почему вы не записываете весь код в файл? Потому что ваше подсознание понимает:

  • Одни и те же функциональные модули нельзя использовать повторно
  • Сложность далеко за пределами личного понимания

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

Самое эффективное решение проблемы сложности — «разделяй и властвуй». Поэтому различные языки программирования имеют свое модульное деление (modularity)план:

  • Разделить по файлу от оригинала
  • Позже используйте OO для разделения по классам

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

модульность, суть проблемы в том, чтобы сломать, причина в том, что ограниченное личное понимание.

Я так много понимаю, так как же разбить основные категории на более мелкие?

Как появились 2 категории?

2.1 Обязанности не являются единственными

Наиболее вероятная причина больших категорий.

CR кусок кода:

Типичная особенность таких категорий холдингов, в том числе полей готовить: эти поля являются незаменимыми?

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

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

  • authorType, тип автора, указывает, является ли автор автором по контракту или обычным автором.Автор по контракту может установить информацию об оплате произведения, но обычный автор не имеет этого разрешения
  • authorReviewStatus, статус рецензирования автора. Когда автор становится автором контракта, должен быть процесс подачи заявки на рецензирование. Поле статуса — это статус рецензирования.
  • editorType, тип редактирования, редактор может быть главным редактором или редактором, с разными правами

Это еще не все для класса User. Но вы можете увидеть проблему, просто взглянув на них:

  • Обычные пользователи не являются ни авторами, ни редакторами

Автор и редактор этих связанных полей не имеют значения для обычных пользователей.

  • Для пользователей, которые становятся авторами, редакционная информация не имеет большого значения.

Потому что авторы не могут быть редакторами. Редакторы не станут авторами, а информация об авторе не имеет смысла для пользователей, которые станут редакторами.

Всегда есть информация, бессмысленная для одних, но необходимая для других. Суть проблемы в том, что существует только «один» пользовательский класс.

Обычные пользователи, авторы, редакторы, три разные роли, из разных сторон бизнеса, заботятся о разном контенте. Просто потому, что все они являются пользователями одной и той же системы, поместите их всех в один класс пользователей, что вызовет изменения в потребностях любой стороны бизнеса, и класс будет неоднократно модифицироваться.Серьезное нарушение принципа единой ответственности. Так что ключом к решению проблемы является разделение обязанностей.

Хотя это класс, он раздувается из-за объединения вещей, которые волнуют разных персонажей.

Просто разделите разную информацию:

public class User {
  private long userId;
  private String name;
  private String nickname;
  private String email;
  private String phoneNumber;
  ...
}

public class Author {
  private long userId;
  private AuthorType authorType;
  private ReviewStatus authorReviewStatus;
  ...
}

public class Editor {
  private long userId;
  private EditorType editorType;
  ...
}

Удалите классы Author и Editor и переместите поля, связанные с автором и редактором, в эти два класса соответственно. Каждый из этих двух классов имеет поле userId, которое используется для связывания роли с конкретным пользователем.

2.2 Поля не группируются

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

Новый класс User из предыдущего сплита:

public class User {
  private long userId;
  private String name;
  private String nickname;
  private String email;
  private String phoneNumber;
  ...
}

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

С точки зрения спроса, основная информация — это тип контента, который обычно остается неизменным после его определения, а контактная информация будет корректироваться в соответствии с реальной ситуацией, например, для привязки различных учетных записей в социальных сетях. Помещение всей этой информации в класс сделает класс менее стабильным.

Соответственно, поля класса User можно сгруппировать:

public class User {
  private long userId;
  private String name;
  private String nickname;
  private Contact contact;
  ...
}

public class Contact {
  private String email;
  private String phoneNumber;
  ...
}

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

В чем разница между двумя сплитами до и после?

  • Фронт - разделить различные объекты в соответствии с их обязанностями
  • После этого поля группируются, а разная информация инкапсулируется по классам.

Разбивка больших категорий на подкатегории — это, по сути, проектная работа, основанная на принципе единой ответственности.

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

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

Программное обеспечение построено в таком многоуровневом пакете.

Категории