NO
Все зависит от того, как определить ответственность. Если ответственность - магазин должен работать, то можно вообще все в один класс запихать 😁
Нет, здесь есть чëткие критерии
Size: a a a
2020 August 30
RT
Неверное, да. АР не нарушает SRP, я использую его везде и всë отлично
Просто для протокола - я не согласен. Нарушает. Если использовать по уму - упрощает жизнь.
NO
Просто для протокола - я не согласен. Нарушает. Если использовать по уму - упрощает жизнь.
Я знаю что ты не согласен) Тех кто решил что понял SRP, переубеждать бесполезно)
В полный стакан не налить воды.
В полный стакан не налить воды.
RT
NO
Программист и заказчик по разному трактуют "действие".
Для программиста "действие" это запись в БД, в очередь, запрос к апи, валидация, применение форматирования, проверка прав доступа.
Для заказчика, действие, это то, что приносит пользу пользователю либо владельцу продукта. Приëм заявки, выставление счëта, просмотр каталога товаров.
Когда программист говорит, что приложение что-то делает, у него в голове одна картина, у заказчика приложения совершенно другая.
Поэтому и формулировку "делает что-то одно" можно трактовать по-разному.
Для программиста "действие" это запись в БД, в очередь, запрос к апи, валидация, применение форматирования, проверка прав доступа.
Для заказчика, действие, это то, что приносит пользу пользователю либо владельцу продукта. Приëм заявки, выставление счëта, просмотр каталога товаров.
Когда программист говорит, что приложение что-то делает, у него в голове одна картина, у заказчика приложения совершенно другая.
Поэтому и формулировку "делает что-то одно" можно трактовать по-разному.
A
В любом случае, получается так, что задумывалось это как одно, в итоге подучилось ещё лучше
Ибо тот, кто реально следует этому принципу, у того всегда будет чисто в коде
Возможно в плане разработке это не очень удобно, но в целом, если не лень дробить ответственностью в разные файлы, то норм
Мне очень это бывает лень :(
Ибо тот, кто реально следует этому принципу, у того всегда будет чисто в коде
Возможно в плане разработке это не очень удобно, но в целом, если не лень дробить ответственностью в разные файлы, то норм
Мне очень это бывает лень :(
NO
Нет, неверное понимание приводит к архитектурным проблемам, и часто серьëзным.
NO
Ничего не бывает без последствий
A
А ну это не исключаю
Тут скорее зависит от реализатора
Роман, как мне кажется, не относится к тем, кто делает это неправильно
Тут скорее зависит от реализатора
Роман, как мне кажется, не относится к тем, кто делает это неправильно
NO
У него разделение по слоям скорее, это хорошая практика
RT
Роман реализатор - звучит круто)
RT
Ромализатор
A
😂😂😂
NO
Впрочем, подобные структуры зависят от сложности приложения.
Слои должны прменяться в тех приложениях, где это оправдано, иначе получится либо переусложнение либо наоборот, не будет особо помогать в борьбе со сложностью.
Но про типы архитектур это отдельная большая тема)
Слои должны прменяться в тех приложениях, где это оправдано, иначе получится либо переусложнение либо наоборот, не будет особо помогать в борьбе со сложностью.
Но про типы архитектур это отдельная большая тема)
A
Вы вообще видели как обычно на go, node и тд всё это делается
Там этим вроде не заморачиваются и хорошо всё у них
Код на php выглядит более логично и правильнее в ролике ниже, но с точки зрения golang, у них тоже всё хорошо
https://youtu.be/0Z-EU2jxjkA
Там этим вроде не заморачиваются и хорошо всё у них
Код на php выглядит более логично и правильнее в ролике ниже, но с точки зрения golang, у них тоже всё хорошо
https://youtu.be/0Z-EU2jxjkA
А
я на js ещё не видел хорошего чистого кода
NO
Ещë один проверочный критерий на правильность применения SOLID - тестируемость.
Написанные по всем канонам классы тестировать легко, написанные неправильно, сложно.
За это люблю тесты и TDD ) Хочешь не хочешь, а написав тесты архитектурные косяки сразу повылезают)
Написанные по всем канонам классы тестировать легко, написанные неправильно, сложно.
За это люблю тесты и TDD ) Хочешь не хочешь, а написав тесты архитектурные косяки сразу повылезают)
RT
я на js ещё не видел хорошего чистого кода
Мне ангуляр с type script кажется симпатичным с точки зрения чистого кода.
RT
Ещë один проверочный критерий на правильность применения SOLID - тестируемость.
Написанные по всем канонам классы тестировать легко, написанные неправильно, сложно.
За это люблю тесты и TDD ) Хочешь не хочешь, а написав тесты архитектурные косяки сразу повылезают)
Написанные по всем канонам классы тестировать легко, написанные неправильно, сложно.
За это люблю тесты и TDD ) Хочешь не хочешь, а написав тесты архитектурные косяки сразу повылезают)
Полностью согласен
RT
Для протокола)