🪄Как применять S из SOLID
Про принцип единственной ответственности написаны тонны статей, но как, чёрт возьми, применять его в реальной разработке? Для того, чтобы успешно применить этот и другие принципы, необходимо осознать одну вещь: наш код не существует сам по себе в сферическом вакууме, это модель реального мира. Связи между компонентами/классами/функциями в нашем коде должны быть такими же, как в реальном мире.
Например, вам нужно сделать формы авторизации и регистрации. На макете они выглядят одинаково, и вы задумываетесь: сделать один универсальный компонент или два отдельных. Для того, чтобы ответить на этот вопрос, вспомните, как проходят эти процессы в реальной жизни. Например, в моем фитнес клубе они существенно отличаются: для регистрации в клубе я заполняла договор с паспортными данными, а для ежедневной регистрации в клубе мне достаточно приложить браслет к турникету. Совершенно разные действия, разные цели, разные сценарии. То же самое и в вебе: регистрация и авторизация - это два разных бизнес-процесса. Даже если сегодня их формы выглядят одинаково, эти компоненты живут своей независимой жизнью: например, на форме авторизации в какой-то момент может появиться галочка “мне уже есть 18”, а на форме регистрации - нет. Или поменяются поля, логика валидации, поведение при ошибках.
Другой пример: вы реализуете карточки товаров, и в разных разделах они имеют разные цвета. Использовать один компонент или делать разные? Давайте подумаем, как бы мы действовали бы в реальном мире. Представьте, что вы печатаете ценники на принтере. Шаблон один и тот же - вы просто вставляете бумагу нужного цвета: белую, жёлтую, синюю. Цвет меняется, но структура остаётся прежней.Если вы решите изменить размер ценника, например, сделать его больше - это уже изменение шаблона, которое повлияет на все ценники сразу. Точно так же в вебе: если мы хотим поменять структуру или размер карточек, то, как правило, мы хотим сделать это у всех карточек сразу. Таким образом, карточка - это один компонент с настраиваемым цветом.
#solid #srp
Про принцип единственной ответственности написаны тонны статей, но как, чёрт возьми, применять его в реальной разработке? Для того, чтобы успешно применить этот и другие принципы, необходимо осознать одну вещь: наш код не существует сам по себе в сферическом вакууме, это модель реального мира. Связи между компонентами/классами/функциями в нашем коде должны быть такими же, как в реальном мире.
Например, вам нужно сделать формы авторизации и регистрации. На макете они выглядят одинаково, и вы задумываетесь: сделать один универсальный компонент или два отдельных. Для того, чтобы ответить на этот вопрос, вспомните, как проходят эти процессы в реальной жизни. Например, в моем фитнес клубе они существенно отличаются: для регистрации в клубе я заполняла договор с паспортными данными, а для ежедневной регистрации в клубе мне достаточно приложить браслет к турникету. Совершенно разные действия, разные цели, разные сценарии. То же самое и в вебе: регистрация и авторизация - это два разных бизнес-процесса. Даже если сегодня их формы выглядят одинаково, эти компоненты живут своей независимой жизнью: например, на форме авторизации в какой-то момент может появиться галочка “мне уже есть 18”, а на форме регистрации - нет. Или поменяются поля, логика валидации, поведение при ошибках.
Другой пример: вы реализуете карточки товаров, и в разных разделах они имеют разные цвета. Использовать один компонент или делать разные? Давайте подумаем, как бы мы действовали бы в реальном мире. Представьте, что вы печатаете ценники на принтере. Шаблон один и тот же - вы просто вставляете бумагу нужного цвета: белую, жёлтую, синюю. Цвет меняется, но структура остаётся прежней.Если вы решите изменить размер ценника, например, сделать его больше - это уже изменение шаблона, которое повлияет на все ценники сразу. Точно так же в вебе: если мы хотим поменять структуру или размер карточек, то, как правило, мы хотим сделать это у всех карточек сразу. Таким образом, карточка - это один компонент с настраиваемым цветом.
#solid #srp
👍20🔥2🤡1