transformDateToString — не раскрывает РЕАЛИЗАЦИЮ transformDateToStringUsingSimpleFormatter — а вот такой — уже лишнее
transformDate
само по себе не содержит контекста действия, трансформ как? зачем? во что? Такое имя было бы уместно только внутри класса ToStringUtils/ ToStringTransformer — так как тут уже класс является контекстом.
Опять же — имя должно быть лаконичным, но с учетом контекста. При нейминге я беру(стараюсь) одно из 2 правил:
1) это общепринятые и известные имена (i j для циклов и тд)
2) имя отражает логику / цель использования (с учетом контекста использования)
Планирую еще одну статью делать на следующей недел. Там буду поднимать тему DI. Сам же предпочитаю доработанную версию сервис локаторов. Если кратко, то там что-то вроде типизированных многоуровневых сервисов.
object ModuleNameServices : Services{
val serviceX by services{ServiceX()} //cached
val serviceY by services("key"){ServiceY()} //scoped
val serviceZ get() = ServiceZ() //newInstance
val serviceU = AnotherModuleService //ref
}
Сам же класс Services — под капотом хэшмеп для хранения скоуп и хэшированых сервисо + функции возвращающие делегаты (services), ну и для тестирования — ф-ция для моков (положить в хэш сервис) — обертки и тд.
А использую через конструктор
class SomeClass(services: Services = ModuleServices){
val sX get()= services.serviceX // Вот тут важно get()= - защити от рантайм модификации и статических ссылок
}
Плюс такого подхода — прямая связност кода (ктрл+клик и найти вожно всё), легко тестить, нереально запутаться, нету рантайм ошибок, нету кодгенерации.
Минус — не по клинархитектуре… нету интерфейсов и тд… хотя при желании можно и доработать
transformDateToString — не раскрывает РЕАЛИЗАЦИЮ
transformDateToStringUsingSimpleFormatter — а вот такой — уже лишнее
само по себе не содержит контекста действия, трансформ как? зачем? во что? Такое имя было бы уместно только внутри класса ToStringUtils/ ToStringTransformer — так как тут уже класс является контекстом.
Опять же — имя должно быть лаконичным, но с учетом контекста. При нейминге я беру(стараюсь) одно из 2 правил:
1) это общепринятые и известные имена (i j для циклов и тд)
2) имя отражает логику / цель использования (с учетом контекста использования)
Сам же класс Services — под капотом хэшмеп для хранения скоуп и хэшированых сервисо + функции возвращающие делегаты (services), ну и для тестирования — ф-ция для моков (положить в хэш сервис) — обертки и тд.
А использую через конструктор
Плюс такого подхода — прямая связност кода (ктрл+клик и найти вожно всё), легко тестить, нереально запутаться, нету рантайм ошибок, нету кодгенерации.
Минус — не по клинархитектуре… нету интерфейсов и тд… хотя при желании можно и доработать