Стоит ли переписывать полностью метод в данной ситуации?

17 апреля, 11:45 Работа 3899 3
Есть метод, например: getUsers. Он юзается в 10-20 местах в проекте, и мне вдруг понадобилось получать юзеров отсортированных не по айдишнику (как сейчас), а по колонке order. В голове есть два варианта:
1) Сделать у существующего метода getUsers необязательный параметр (withSorting = false), и в тех самых 10-20 местах оно будет работать как сейчас, потому что там по дефолту проставляется фолс, а в нужном нам месте поставить true. Но мне говорили, что если добавляем всякие такие флаги то это служит нарушением SRP.
2) Создать метод getUsersSorted, например. Но как по мне, это тупо копирование метода getUsers с добавлением ордер бай.
Хотел бы спросить у знающих, как и почему лучше сделать?
3 комментария
Сортировка:
Добавить комментарий
Igor Gnatishin
Igor Gnatishin 2019, 17 апреля, 16:50
0
В вашем случае я бы последовал варианту №3
Nikolas
Nikolas 2019, 17 апреля, 14:26
0
1 вариант, вдруг ты так задумывал изначально, кто знает?
Віктор Омелян
Віктор Омелян 2019, 17 апреля, 13:47
0
Вариантов 3: 1) Добавить параметр: плюсы - просто, можно добавить гибкий параметр, например $sortField. минусы - в следующий раз понадобится менять еще и направление сортировки - прийдется снова костылить. 2) Отдельный метод - уже лучше, но все равно рано или поздно функционал надо будет менять и с параметрами что -то прийдется делать. 2.1) Передавать в качестве аргумента некий массив/объект настроек, плюсы - гибко, минусы - каждый раз надо учитывать/знать структуру объекта настроек, что не очень удобно. 3) Использовать внутренние паблик свойства объекта для настройки работы логики объекта, плюсы - не надо менять инерфейс вызова, достаточно сделать

IT Новости

Смотреть все