Корректное поведение для методов интерфейса, которые не могут быть реализованы
Это не сработает, потому что упаковщик уже упаковал файлы. По той же причине, по которой вы не можете динамически требовать.
Вам необходимо изменить логику, чтобы она, вероятно, принимала строку, а затем иметь фабрику для динамической визуализации компонента. Примерно так:
<Parent child='one'/>
render(){
let Component = One;
switch(this.props.child){
case: 'one':
Component: One; break;
case: 'two':
Component: Two; break;
}
return <Component/>
}
5 ответов
Любой метод, который не может быть реализован согласно семантике интерфейса, должен бросить UnsupportedOperationException.
Тот набор только для чтения, уже обеспеченный броском Java UnsupportedOperationException во время операций записи уже, является неудачным взломом дизайна. Классы набора должны были быть записаны с отдельными интерфейсами только для записи и только для чтения, которые оба наследованы полным интерфейсом чтения-записи. Затем Вы знаете то, что Вы получаете.
Это зависит от Вашей экономической модели. 2 опции:
- Ничего не сделайте.
- Бросьте
UnsupportedOperationException.
Используйте, какой бы ни имеет больше смысла. Если Вы ничего не делаете, Вы не повинуетесь контракту интерфейса. Однако выдача исключения на этапе выполнения может нанести ущерб коду вызова. Таким образом решение должно будет быть принято на основе того, как Вы будете использовать класс. Другая опция состояла бы в том, чтобы использовать более простой или другой интерфейс, если это возможно.
Действительно обратите внимание, что библиотека Java идет путем исключения в конкретном случае наборов только для чтения.
Это было отмечено ниже, что UnsupportedOperationException является частью платформы наборов Java. Если Ваша ситуация за пределами наборов, и семантика беспокоит Вас, можно прокрутить собственное
NotImplementedException, или если Вы уже используете Ленга свободного городского населения, Вы могли бы использовать их. Ваши два варианта действительно только:
- Ничего не сделайте.
- Выдайте исключение.
У обоих есть недостатки. В первом случае, при наличии пустого метода, Вы могли ввести в заблуждение программиста в размышление, что что-то произошло с Вашими данными. Второй случай повреждает всю эту мысль о полиморфизме, свойственном от интерфейсов.
Обратите внимание, что UnsupportedOperationException только в порядке из-за особого свойства Платформы Наборов Java, что реализациям разрешают "лентяйничать", реализовывая часть интерфейса, потому что они неизменны.
Таким образом, это хорошо для помещенного () (предполагающий, что все мутаторные методы делают то же самое), но Карта, которая бросает UnsupportedOperationException от размера () метод, была бы просто повреждена. При попытке реализовать своего рода карту, которая не знает, насколько большой это, можно быть в беде (хотя иногда можно возвратить Целое число. MAX_VALUE).
Также обратите внимание, что в документации класса для UnsupportedOperationException говорится, что это - часть Платформы Наборов Java. Вне платформы наборов, бросая UnsupportedOperationException не ожидаться и мог привести к клиентскому коду, что плоскость не работает. Несомненно, это - RuntimeException, но просто потому что можно бросить его, не означает, что метод будет работать, если это всегда сделает.
Вместо этого Вы могли или осуществить рефакторинг интерфейс (возможно, разделение его в два) или иначе заново обдумать, почему этот класс утверждает, что был Нечто, когда это явно не, так как это не может сделать вещей, которые Foos определяются, чтобы смочь сделать.