Comments 21
Статья хорошая даже несмотря на то, что вызывает эффект дежавю. ;-)
SOLID не работает на практике и в реальной жизни во фронтенд разработке, вообще никак, никогда, без вариантов. Да и не только на фронте, в принципе он очень сильно мешает комфортной разработке, и плюсы которые он дает никаким образом не перекрывают минусы. Слишком уж серьезные минусы.
На hello world'ах которые вы показываете и сами пробуете для тестов, это ещё более менее терпимо, но когда речь заходит о реальном проекте где множество страниц, логики, компонентов, взаимосвязей и т.п. то это всё, там начинается полнейшая дичь, видел я несколько таких попыток применения SOLID'a на реальных проектах. это нечто) Сложность на ровном месте просто повышается в разы, по сравнению с так сказать традиционными подходами.
И самые жирные минусы как раз кроются в том, какой "классный и удобный код" приходится писать если придерживаться всех этих принципов, бонусом как раз таки усложнение серьезное и увеличения кода как таковое и отсюда вытекает ещё один жирнющий минус, это время затраченное на написание кода.
Если его использовать правильно и понимать, для чего ты его используешь, то все работает прекрасно, как на helloWorld примерах, так и на крупных проектах
Если использовать просто лишь бы использовать или потому что так делают все, то можно любую технологию/фреймворк/библиотеку подставить в ваш комментарий вместо слова "SOLID" и сказать, что это не работает
просто с ходу солид применить достаточно сложно.
Сначала нужно проработать архитектуру приложения. К сожалению, реальность таков, что это не то что не возможно, а скорее просто нет на это времени.
всегда проще сделать "побыстрее", а потом закопаться в тех долге, как раз подобные принципы говорят о том, что нужно продумывать свои решения, прежде, чем их реализовывать
Ну а вообще это же вопрос рефакторинга, который как говорил один известный деятель "Нужно делать ежедневно". Никто не говорит, что нужно взять и переписать огромный проект под какую-то определенную методологию сразу целиком.
Можно представить это как переход с одной устаревшей библиотеки на другую новомодную) Весь новый функционал пишем, используя новую, а в тех местах, где используем старую, в рамках тех долга или по личной инициативе не спеша тоже переводим на новую и в конечном счете в какой-то момент времени все обновится
По разному бывает.
Мне приходилось работать с проектами, которые предпочли переписать с реакт на вью. Но, честно говоря, проще было бы рефакторинг сделать. Многие до сих пор ошибочно думают, что переписать проект - это серебренная пуля. Хотя на самом деле новый проект - это новые баги.
А еще хорошо, когда есть тз, но так тоже не везде и не всегда бывает.
СЕ ЛЯ ВИ
Вот тут с вами вынужден согласиться)
В базовом классе
Paymentмы определяем методprocessPayment, который будет обрабатывать платеж. Этот метод должен быть реализован в подклассах.
А почему метод избыточно назван processPayment, а не просто process?
Оба подкласса (
CreditCardPaymentиPayPalPayment) реализуют методprocessPayment, каждый по-своему. Но оба класса сохраняют контракт, заданный базовым классом, и могут быть использованы взаимозаменяемо.
А что мы будем делать, если придумаем ещё один вид платежа? Будем вводить ещё один класс? А если мы хотим сделать это (ввести новый вид платежа) без перекомпиляции приложения?
А почему метод избыточно назван processPayment, а не просто process?
Это уже DRY, а не SOLID :)
А что мы будем делать, если придумаем ещё один вид платежа? Будем вводить ещё один класс? А если мы хотим сделать это (ввести новый вид платежа) без перекомпиляции приложения?
В данной статье приводится пример расширения через использование паттерна "стратегия". Для ваше примера расширения нужно использовать другой подход, уже не используя расширение через ввод новых классов
В примере выше, стоит в компонент
UserNameпередавать только поле имени, а не весь объект
В таком решении таится опасность: если кто-то захочет изменить логику работы компонента, то может потребоваться получить больше информации от объекта. Но это всё, лишь, взгляд со стороны.
Конечно, если компонент UserName станет более сложным и решит, что кроме имени, он будет еще показывать фамилию и дату рождения, то конечно же придется передать в компонент еще два поля.
Возможно в конечном счете данный компонент разрастется настолько, что в него уже проще будет передать весь объект, (даже если в нем будут лишние поля — да иногда не нужно слепо руководствоваться методологиями), чем 10 пропсов. Хотя в таком варианте уже следует пересмотреть реализацию компонента =)
Пример про лисков какая-то фигня, там нету никакого реакт компонента
Принцип подстановки Барбары Лисков на примере React компонента:
А где тут React?
Статья о том, как делать не надо. Можно было бы долго объяснять почему, но на это ушла бы еще одна статья. Если кратко - SOLID это набор костыльных ООП принципов, от которых в React приложениях лучше отказаться полностью, как и от ООП.
Костыльных? Да это по определению костыльности чисто не так. SOLID как раз про абстракцию ради избавления от костыльности
Попытаюсь представить полный отказ от SOLID. Получаем десятки и сотни хуков в каждом компоненте. В каждый компонент добавляем switch для обработки всех компонентов, которые он получает через children. Для каждой кнопки с отличным действием на onClick делаем новый компонент-кнопку, т.к. каждый onClick работает не с абстрактными функциями, а только с одной конкретной функцией.
SOLID – костыльная методология, а Роберт Мартин – дурачок, так получается?)
еще раз можно повторить, что нужно не слепо следовать методологиям, а применять их там, где они нужны, а где не нужны - применять не обязательно )
SOLID in React