Ответственность и DRY, KISS

Рейтинг: 1Ответов: 1Опубликовано: 20.02.2023

Пишу преимущественно на .NET(Core, Xamarin). Сейчас работаю над проектом с фронтом на React JS(фронт тоже я пишу), и словил себя на мысли, что много повторяю код похожий друг на друга, то есть нарушаю DRY. И казалось бы нет проблемы вынести всё похожее куда то в одно место, разнести по dependency сервисам и т.п., но я боюсь последствий в лице принципа единственной ответственности в случае расширения функциональности.

И так вопрос, банально, я создаю методы по работе например с контроллером пользователя:

  1. Index - лист юзеров
  2. Create - создаем
  3. Edit - редактируем

Для edit и create я создаю отдельные как action так и view компоненты реакта, которые достаточно похожи друг на друга, отличия минимальны, не большая разница в наличии данных(id, active, etc) viewmodel и набором методов по манипуляциям с БД. Дополнительно я создаю для индекса например UsersViewModel и для edit\create общую UserViewModel.

Правильно ли я делаю или стоит использовать один action и один view с ветвлениями?

Под ветвлениями я подразумеваю ряд проверок на предмет что сейчас происходит create\edit. Тоже самое и на view, один компонент для всего. Но это по мимо ответственности может еще и нарушать KISS(Keep it simple, stupid).

Поделитесь опытом.

c# шаблоны-проектирования solid
Источник: Stack Overflow на русском

Ответы

▲ 3Принят

Здесь возникает вопрос, а какие варианты решения возникших вопросов вы видите. Если есть сомнения в правильности, значит должно быть представление альтернативного решения.

DRY - решается декомпозицией операции до такой степени, чтобы ее части могли участвовать в разных операциях.

KISS - пока у вас не пухнет голова от стараний уместить в себе знания о том, что где валяется, то всё нормально. Ну и плюс здесь может быть воздержание от вкручивания модных штук тогда, когда от них кода много и толку мало. Например, я не вкручиваю IoC контейнер в минипроекты на 1,5 VM и 2,5 View, это и есть KISS.

SRP - когда вам задают вопрос "что делает этот класс/метод/библиотека?", если вы можете кратко ответить без перечислений списков возможностей, то SRP соблюдается. Например "этот метод складывает 2 числа", "этот класс работает с API через HTTP", "эта библиотека содержит полезные MVVM примочки".

Ну и не стоит забывать про остальне SOLID-составляющие, они в совокупности с используемыми шаблонами проектирования должны дать понимание, куда двигаться, приращивая к проекту всё больше и больше новых штук.

Если у вас есть коллекция чего-то, и вы для нее реализуете какой-то CRUD, это вполне может быть реализовано в рамках одного класса. А внешние интеграции типа HTTP-API можно вкрутить в него через зависимости (DI). Это не должно быть сложно.