Блог

Главная - Вопросы по программированию - Вложенный класс перечисления Kotlin

Вложенный класс перечисления Kotlin

#kotlin #enums #inner-classes

#kotlin #перечисления #внутренние классы

Вопрос:

Пока я играл с enum s, я создал это:

 enum class ElectricPart {
    // Wow, what I had implemented here? Is it good or bad?!
    ;
    enum class VisionLight(val id:String){
        LIGHTS_OFF("lights_off"),
        POSITION_LIGHTS("lights_position"),
        DRIVING_LIGHTS("lights_driving"),
        LONG_RANGE_LIGHTS("lights_long_range"),
        LONG_RANGE_SIGNAL_LIGHTS("lights_long_range_signal")
    }
    enum class DirectionLight(val id:String){
        DIRECTION_LIGHTS_RIGHT("lights_direction_right"),
        DIRECTION_LIGHTS_LEFT("lights_direction_left"),
        DIRECTION_LIGHTS_STRAIGHT("lights_direction_straight")
    }
    //More enum classes if needed
}

В автомобиле есть электрические детали ( ElectricPart ). VisionLight S и DirectionLight s являются частью электрики автомобиля.

Хорошая ли это реализация? Разве это плохо? Конечно, это кажется странным!
Я хотел бы услышать ваши комментарии по этому поводу!

Комментарии:

1. Если вы не знаете, что вы создали, это плохо

2. @TimCastelijns Как я уже сказал, я играл и не вводил случайные символы! Я сделал это специально, и мне интересно, хороший ли это путь! Является ли хорошей практикой использование вложенных классов перечисления? И почему кажется, что он нужен ; перед новым enum классом?

3. Является ли хорошей практикой использование вложенных классов перечисления? — вероятно, нет. Я не могу придумать ситуацию, в которой вы могли бы его использовать (или как)

4. Если вы что-то делаете, у вас должна быть причина для этого. Мы не можем сказать, хорошо это или плохо в пустоте. Какую цель он выполняет? Что вы пытаетесь передать с помощью этой структуры?

5. Я отредактировал и попытался быть более конкретным. Это простая идея / пример, о котором я думал.

Ответ №1:

Вам нужно подумать о том, как эти перечисления будут использоваться внешним кодом. По сути, вы создаете другой namespace . Первое пространство имен — это пакет, а второе — класс. Это может стать утомительным для разработчиков при вводе. Для запуска автозаполнения IDE также требуется, чтобы класс был введен первым.

Если пакет не насыщен слишком большим количеством определений или существуют потенциальные конфликты имен, возможно, было бы лучше определить их вне класса. Kotlin позволяет по-прежнему определять перечисления в том же файле, что и класс, если это помогает поддерживать организованность на физическом уровне.

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

Ответ №2:

Согласно вашему коду, нет никаких оснований для ElectricPart того, чтобы быть enum class — перечисление без счетчиков бессмысленно.

Для целей пространства имен, ElectricPart также может быть class (с частным конструктором, т. Е. Без экземпляров) или object (ровно один одноэлементный экземпляр). Обратите внимание, что классы изначально не предназначены для использования в качестве пространств имен в Kotlin, т. Е. Они создаются за счет накладных расходов во время выполнения JVM, даже если вы используете их имя только во время компиляции.

В автомобиле есть электрические детали ( ElectricPart ). VisionLight S и DirectionLight s являются частью электрики автомобиля.

Это звучит как типичная взаимосвязь: огни обзора и указатели поворота являются электрическими частями автомобиля. Это отношение обычно моделируется с помощью наследования и реализации интерфейса, поэтому вы могли бы сделать это:

 interface ElectricPart
enum class VisionLight(val id:String) : ElectricPart {...}
enum class DirectionLight(val id:String) : ElectricPart {...}

Имейте в виду, что интерфейсы в первую очередь полезны, когда у вас есть методы, которые переопределяются в каждой реализации, для достижения полиморфного поведения. Тем не менее, также возможно использовать интерфейсы маркеров (интерфейсы без методов) в местах, где в противном случае вам пришлось бы использовать менее типобезопасный Any .