Комментарии 9
Если вкратце у нас есть userRepository будь то файл или модуль, в котором есть функция getUserByID, что уже является принципом "S".
Нет, не является.
Класс UserService может иметь другие методы, такие как getAllUsers, createUser, updateUser и т. д. Но класс UserController использует только getUserById, ему не нужно реализовывать все методы и ему не нужно знать о существовании других методов.
...а какая связь между тем, какие методы UserController использует, а какие - реализует?
Следуя ISP, класс UserController не вынужден реализовывать какие-либо ненужные методы, что делает код более гибким и простым для понимания.
При чем тут ISP? Почему это не SRP?
Такой подход делает код более удобным для сопровождения и более простым для изменения, поскольку изменения в классе UserService повлияют только на классы, которые фактически используют измененные методы, а не на классы, которые их не используют.
Какой именно подход? Почему без него изменения в классе UserService будут влиять на классы, которые не используют измененные методы?
Класс UserService закрыт для модификации, но его можно расширить, передав другую реализацию userRepository.
Каким образом передача другого репозитория расширяет класс UserService?
"D" - принцип инверсии зависимости, гласит что классы не могут быть зависемы от класс низкого уровня
Что, простите?
Впрочем, у вас и пример на DIP такой же непонятный, как ваше объяснение.
ChatGPT отличная штука для документирования или как минимум поможет вам найти ответы, в которых вы застряли в процессе изучении чего-либо.
Ваша статья, к сожалению, это никак не демонстрирует.
Я уже в ожидании статей "SOLID и квантовые вычисления", "SOLID и Stable Diffusion", "SOLID и Принц-полукровка"
Спасибо за примеры. Но вот принцип инверсии зависимости на мой взгляд раскрыт плохо.
Я бы прокомментировал его так. То что при изменении объекта более низкого уровня не требуется менять объект более высокого. То есть он все-таки зависим (он зависит от интерфейса, но не от реализации).
Данный пример демонстрирует как раз обратное. ChatGPT не лучший способ для демонстрации принципов SOLID. Взятая для примера композиция никак не отразает принцип Dependency Inversion.
Гораздо нагляднее это может показать абстрактный класс который может наследоваться простым, но при этом нельзя сделать наоборот - абстрактный класс не может наследовать простой. В данной композиции роль абстрактрого класса играет голая функция, что вообще неочевидно.
Single Responsibility Principle: Каждая функция должна иметь одну и только одну ответственность
Принцип не об этом. Такое определение ближе к истине:
The single-responsibility principle (SRP) is a computer programming principle that states that "A module should be responsible to one, and only one, actor." The term actor refers to a group (consisting of one or more stakeholders or users) that requires a change in the module.
Круто. Нужно было просто сказать «юзайте интерфейсы, с помощью di делайте декорации на их основе. А чтобы провайдить функционал из сервис-леера в контроллеры, юзайте интерфейс фасадов сервис-леера :)
Только непонятно, что нового открыл для нас этот AI чего раньше не было в туториалах/литературах ?)
Только не Лискова, а Лисков. Барбары Лисков.
SOLID на примере JavaScript с chatGPT