Чтобы реализовать свойство или реализовать подкласс

У меня есть класс под названием List_Field, который, как следует из названия, строит поля ввода списка. Эти поля ввода списка позволяют пользователям выбирать один элемент в списке.

Я хочу иметь возможность создавать поля ввода списка, которые позволят пользователям выбирать несколько элементов в списке, поэтому у меня есть следующая дилемма:

Должен ли я сделать это с помощью реализации свойства multiple_choice_allowed в существующем свойстве List_Field или я должен реализовать подкласс Multiple_Choice_List_Field класса List_Field?

Каким инженерным принципом я должен следовать, когда сталкиваюсь с такими дилеммами, как этот?

Ответ 1

Взгляните на принципы SOLID. Они помогут вам в ваших проектах. В частности, принцип единой ответственности подскажет вам не смешивать две проблемы в одном классе, а принцип подстановки Лискова будет предлагать вам не создавать подклассы, нарушающие договор о суперклассах, как то, что вы также предлагаете.

Итак, каково было бы решение в вашем случае? Вы можете создать абстрактный базовый класс, который был бы агностиком для типа выбора, а затем создать 2 подкласса, один для одного выбора, а другой для множественного выбора.

Ответ 2

Зависит от наличия/отсутствия эволюции объекта - если вы хотите, чтобы особый случай, подкласс или инъекция (DI) "выберите" поведение (стратегия) хорош.

Но если вы также хотите разрешить Field_List динамически изменять свое поведение, то метод property или mutating - единственный способ пойти.

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

Я проголосовал бы за метод property/mutate.

Ответ 3

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

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

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

Просто сделайте это так, чтобы вам было удобно создавать и поддерживать (и в конечном итоге продлевать).

Ответ 4

Должен ли я сделать это путем внедрения свойство multiple_choice_allowed в существующее свойство List_Field

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

Ответ 5

Лично я бы сказал, что нет: вместо этого используйте конструктор, который принимает multiple_choice_allowed, а затем имеет свойство, отображающее ListFields как коллекцию (только один элемент, если разрешен только один, все из них, когда разрешено более одного). Сделайте это только для чтения (это означает, что вы должны копировать его всякий раз, когда вы возвращаете список).