Все решения, в том числе принятые, имеют некоторые проблемы, как указано в их соответствующих комментариях. Принимаемый ответ by @ jonathan-leffler уже неплохой, но не предполагает, что предпосылки не обязательно должны быть построены по порядку (например, во время make -j
). Однако простое перемещение предпосылки directories
с all
до program
провоцирует перестройки на каждом запуске AFAICT. Следующее решение не имеет этой проблемы, и AFAICS работает по назначению.
MKDIR_P := mkdir -p
OUT_DIR := build
.PHONY: directories all clean
all: $(OUT_DIR)/program
directories: $(OUT_DIR)
$(OUT_DIR):
${MKDIR_P} $(OUT_DIR)
$(OUT_DIR)/program: | directories
touch $(OUT_DIR)/program
clean:
rm -rf $(OUT_DIR)
Взгляните на ТВЕРДЫЕ принципы . Они помогут вам в ваших проектах. В частности, принцип единой ответственности скажет вам не смешивать две проблемы в одном классе, а принцип подстановки Лискова скажет вам не создавать подклассы, которые нарушают контракт суперклассов, как то, что вы также предлагаете.
Так, каково было бы решение в вашем случае? Вы можете создать абстрактный базовый класс, который будет независим от типа выбора, а затем создать 2 подкласса, один для одиночного выбора, а другой для множественного выбора.
Зависит от наличия / отсутствия эволюции объекта - если вы хотите, чтобы особый случай, подклассификация или инъекция (DI) «выберите» поведение (стратегию) хорошо.
Но если вы также хотите, чтобы Field_List динамически изменял свое поведение, тогда свойство или метод мутации - единственный путь.
Пример: экран регистрации с различными «планами» - базовый, где вы можете выбрать только одну вещь и премиум, где вы можете выбрать столько, сколько хотите. Смена плана будет переключаться между выпадающим и несколькими флажками, при этом все еще имея тот же объект, включая его содержимое.
Я бы проголосовал за свойство / мутировать метод.
Должен ли я сделать это путем реализации свойства multip_choice_allowed в существующем свойстве List_Field
Если вы можете сделать это, я думаю, что это лучшее решение, потому что таким образом вы избегаете распространения классов. Если при этом вы слишком усложняете свой класс List_Field, возможно, создание производного класса может иметь некоторые преимущества в отношении удобства сопровождения вашего кода.