Начнем эту статью с вопроса: что может делать класс User? Подумайте об этом в первую очередь.

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

Сам того не осознавая, я уже совершил распространенную ошибку среди программистов — «Класс Бога». Класс Бога — это термин, обозначающий класс, который имеет множество обязанностей одновременно. Так где же ошибка? Все в User Class связано с пользователем.

Полное теоретическое объяснение этого принципа я задокументировал в своей предыдущей статье под названием: Принцип единой ответственности: S в SOLID — теория. Вы можете получить к нему доступ, чтобы изучить теоретическую сторону.

В этой статье я расскажу о практической части. О том, как применить принцип единой ответственности для преодоления вышеперечисленных случаев. Код за кодом и построчно.

Что такое класс Бога?

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

Изначально все хорошо. Но что, если нужны только a и b, исключая c по f? Использование всего God Class является расточительным, поскольку неиспользованный код истощает ресурсы. Вместо этого мы будем использовать Human Class и функции копирования a и b.

Это тоже работает, но приводит к дублированию кода. Как насчет включения God Class в Human Class? Human class нужно только создать функцию, которая вызывает a и b только из God Class.

Это может показаться глупой идеей, но я делал это раньше, и вы, возможно, тоже, даже не осознавая этого. Он перемещается только туда, где вы определяете God Class, в Human Class, чтобы его не было видно. Это будет серьезной угрозой для наших ресурсов, поскольку каждый раз, когда создается объект Human Class, также создается объект God Class.

Другая проблема заключается в том, хотим ли мы добавить другие возможности. Чем больше возможностей в God Class, тем более запутанным будет код.

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

Чем больше кода вы дублируете, тем сложнее будет вносить изменения в дальнейшем. Например, если у вас есть функция с именем a, которая находится в трех разных файлах, и вам нужно что-то изменить в этой функции, вам придется внести изменения во всех трех местах. Это большая работа, и легко допустить ошибку.

Как избежать Класса Бога?

Избегание класса Бога — важный шаг в улучшении дизайна программного обеспечения и обеспечении организованности, понятности и хорошего управления кодом. Один из способов сделать это — применить Принцип единой ответственности (S в SOLID). Согласно этому принципу, объект всегда должен создаваться для одной конкретной цели. Вот несколько шагов по реализации принципа единой ответственности:

  • Определите обязанности каждого объекта. Каково конкретное назначение каждого объекта? Какие задачи или функции он выполняет? Затем группы работают вместе в соответствии со своими обязанностями. Тесно связанные функции следует группировать вместе, а функции, имеющие разные цели, следует разделять.
  • Создайте новые объекты для функций, которые не принадлежат текущему объекту. Если у объекта много разных обязанностей, рассмотрите возможность создания новых объектов для каждой ответственности.
  • Выполните рефакторинг кода для перемещения функций в новые объекты. Убедитесь, что каждый объект имеет четкую ответственность и функциональность, связанную с его конкретным назначением.

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

Как это применяется в реальном случае разработки программного обеспечения?

Давайте начнем с случая, о котором я упоминал в начале этой статьи, и речь идет о классе User. Первоначально я создал user class с функциями register как пользователь, login как пользователь, update профиль пользователя, view профиль пользователя и так далее. Давайте проанализируем, следует ли этот класс принципу единой ответственности или нет.

Во-первых, давайте посмотрим на обязанности каждой функции в классе.

  • login() отвечает за аутентификацию существующих пользователей.
  • register() отвечает за аутентификацию новых пользователей.
  • viewUser() отвечает за просмотр нашего собственного профиля и профилей других пользователей.
  • updateUser() несет ответственность за обновление данных нашего профиля в случае их изменения.

Несмотря на то, что все эти функции связаны с пользователями, это не означает, что они все принадлежат User Class. Помните, что функции следует группировать по их основному назначению. Тесно связанные функции следует группировать вместе, а функции с разными целями следует разделять.

Понятно, что login() и register() больше ориентированы на аутентификацию, а viewUser() и updateUser() ориентированы на чтение и запись данных Пользователя.

Поэтому нам нужно создать новый класс для работы с аутентификацией. После этого переместите код login и register в этот класс.

После того, как все сделали, поздравляю! Вы внедрили принцип единой ответственности, который является частью SOLID.

Поздравляем!

Добро пожаловать в конец урока! Поздравляю с тем, что уже многому научился.

Во-первых, вы узнали, что такое класс Бога. Это класс, который делает все и имеет все. Ты даже

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

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

В-четвертых, вы научились применять свои знания в реальных сценариях разработки программного обеспечения. Вы узнали, как исправить ситуацию, когда класс User не соответствует SRP.

От писателя

Здравствуйте, разрешите представиться — я Мухаммад Резкий Сулихин. Мы подошли к концу этой статьи, и я искренне благодарю вас за то, что нашли время ее прочитать. Если у вас есть какие-либо вопросы или отзывы, свяжитесь со мной напрямую по электронной почте [email protected]. Я более чем рад получить ваше мнение, будь то мои навыки письма на английском языке или что-то еще, я могу ошибаться. Ваши идеи помогут мне расти.

С нетерпением ждем возможности связаться с вами в будущих статьях! Кстати, я мобильный разработчик, сейчас учусь в Apple Developer Academy. Я открыт для различных возможностей, таких как сотрудничество, внештатная работа, стажировки, неполный или полный рабочий день. Для меня было бы огромным счастьем изучить эти возможности.

До следующих встреч, сохраняйте любопытство и продолжайте учиться!