разных модулей приложения. К примеру, есть класс
enum class AppLanguage(val langCode: Int) {
EN(0),
RU(1),
UK(2)
}
Какими должны быть имена enum для presenation / domain / data?
Знаю, что для data class используют
- presentation - ClassNameModel
- domain - ClassNameEntity
- data - ClassNameDto
И Mapper'ами туда-сюда их перегоняют. Как быть с enum?
Вот это тебя загнало, приятель! Я бы называл, как и остальные классы. P.S. нейминг конвеншены могут отличаться от команды к команде. Про то, чтобы именно data class называть как-то по-особенному, вообще слышу впервые.
А зачем суффиксы менять, если в маппере оно именем пакета разруливается, а дальше по слоям ходят только их собственные модели?
два варианта вижу: - хранить AppLanguage в domain, а остальные модули будут его использовать. - дать разные имена, чтобы в маппере разошлось все
Если нет деления на модули по слоям то сложно такое контролировать
одинаковые имена разойдутся в маппере, если - имена будут разные - полное имя класса будет прописана во входном параметре или в возвращаемом - использовать as в импортах
пример по нэймингу: - https://www.youtube.com/watch?v=rTWCxow5IJQ - https://www.reddit.com/r/androiddev/comments/dwnqx9/comment/f7ksqqq/?utm_source=share&utm_medium=web2x&context=3 - https://enterprisecraftsmanship.com/posts/dto-vs-value-object-vs-poco/
можете поделиться своей задачей, которая требует для каждого слоя объявлять свой собственный енум для одной и той же сущности?
Задача простая - возможность смены языка приложения с помощью кнопок на экране с последующим хранением в Shared Preferences. Сама задача ничего не требует))) Это я упоролся, и хочу сделать(набить руку) максимально по архитектуре.
Была мысль не плодить сущности enum, а использовать ту, что в домене.
я уверен, что свойства сущности языка не будут различаться между слоями. а если и будут, то скорее всего нарушается первый принцип solid так что я бы ограничился единственным енумом на проект
ok. понял. спасибо)))
Обсуждают сегодня