Операторы выбора могут почти всегда заменяться полиморфизмом
И также
boolean investable = customer.isInvestable();
, Так как вызов к isInvestable является полиморфным, фактический алгоритм, используемый для совершения вызова, определяется типом клиента.
я думаю, что Вы оба неправы . Что, если это - просто "investibility" логика для клиента, желающего бизнес-кредита. Возможно, innvestibility решение клиента для другого продукта действительно очень отличается, и возможно не на основе "категории", но где они живут, женаты ли они, в каком секторе задания они работают?
кроме того, что, если существуют новые продукты, выходящие все время, каждый с различными investibility решениями и я не хочу обновлять свое ядро Customer
, классифицируют каждый раз, когда это происходит?
Как я сказал, я не говорю switch
, всегда прекрасен - но одинаково это может быть совершенно законно. Если используется хорошо, это может быть чрезвычайно ясный способ записать прикладную логику.
Проблема просто в том, что проверка AllowMultiple
сравнивает только атрибуты одного и того же фактического типа (т.е. конкретный тип, созданный) - и, возможно, лучше по этой причине используется с запечатанными
атрибутами.
Он, например, будет применять следующее (как недопустимый дубликат), наследуя это от BaseAttribute
:
[DerivedAttributeB()]
[DerivedAttributeB()]
public string Name { get; set; }
Короче говоря, Я не думаю, что вы можете делать здесь то, что хотите ... (применять не более одного экземпляра , включая подклассы из BaseAttribute
для каждого свойства).
Аналогичный пример этого проблема будет в следующем:
[Description("abc")]
[I18NDescriptionAttribute("abc")]
public string Name { get; set; }
class I18NDescriptionAttribute : DescriptionAttribute {
public I18NDescriptionAttribute(string resxKey) : base(resxKey) { }
}
Целью выше является предоставление [Description]
из resx во время выполнения (полностью поддерживается ComponentModel
и т.д.) - но это может 't запрещает вам также добавлять [Описание]
.