Дмитрий, если это в одном месте, то я поступлю как вы советуете, так как зачем мне переменование. Но если куча файлов, тогда мой лучше выходит... Но опят такие... Пятый принцим и нужен чтобы расширать классы.. ох
Дмитрий, ну вы тоже по своему правы. Но чето я не догоняю зачем тогда это солид правила, когда можно тупо править классы и не парится. Я отталкивался от такого момента. Вот написал я метод который выдает определенную структуру данных, и начили другие классы это использовать, и пока эта структура не изменится все будет хорошо работат, как только она изменится добавлением нового атрибута, есть вероятность ошибки
Adamos, тут не так просто же, ну добавил я поле в UserRepositoryDto, и UserService уже принемает данные не те к которым он был написан, может он там их в array загоняит и т.д. Я к тому что в UserSErvice данные уже идут нового формата, и значит мне и юзер сервис надо править, чтобы правильно обрабатывал и все классы что использую этот юзер сервис. А SOLID создан для быстрого изменения а не правки кучи файлов. Вот а тут и туплю, не могу понять. Нужен человек кто уже это все применил и прокачал в себе.
Adamos, ну это выдрючивание уже идет с чистой архитектуры, это обеспечивает изляцию по уровням и всегда знаеш что должно приходить. я наверно усложнил код... Извиняюсь, учусь только
Дмитрий, но как это может быть в рамках этого принципа, когда выходные данные с этого репозитория другие, представьте что UserRepository используют 10 классов, и часть из них выдают данные пользователям, тогда мало того что данные уже будут скриптам передоватся не стандартные там будет доп поле, так еще и на выходет в апи будут поля которые не хотелось бы показывать. Это уже называется сайд эффектами. Или я не прав в чем то ?
И я показал очень простой пример чтобы разобратся по факту там может быть много использований классов UserService, UserRepository другими классами, и если мы поменяем что то, то надо будет править и другие места. а второе правило обеспечивает нам возможность добавлять и не ломать старый функционал
