Начнем эту статью с вопроса: что может делать класс 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. Я открыт для различных возможностей, таких как сотрудничество, внештатная работа, стажировки, неполный или полный рабочий день. Для меня было бы огромным счастьем изучить эти возможности.
До следующих встреч, сохраняйте любопытство и продолжайте учиться!