Как избежать instanceof в Java
Наличие цепочки операций "instanceof" считается "запахом кода". Стандартный ответ "использовать полиморфизм". Как бы я это сделал в этом случае?
Есть несколько подклассов базового класса; Ни один из них не под моим контролем. Аналогичная ситуация была бы с классами Java Integer, Double, BigDecimal и т. Д.
if (obj instanceof Integer) {NumberStuff.handle((Integer)obj);}
else if (obj instanceof BigDecimal) {BigDecimalStuff.handle((BigDecimal)obj);}
else if (obj instanceof Double) {DoubleStuff.handle((Double)obj);}
У меня есть контроль над NumberStuff и так далее.
Я не хочу использовать много строк кода, где бы пригодились несколько строк. (Иногда я делаю HashMap, отображающий Integer.class на экземпляр IntegerStuff, BigDecimal.class на экземпляр BigDecimalStuff и т. Д. Но сегодня я хочу что-то попроще.)
Я хотел бы что-то простое, как это:
public static handle(Integer num) { ... }
public static handle(BigDecimal num) { ... }
Но Java просто не работает таким образом.
Я хотел бы использовать статические методы при форматировании. Вещи, которые я форматирую, составные, где Thing1 может содержать массив Thing2s, а Thing2 может содержать массив Thing1s. У меня была проблема, когда я реализовал мои средства форматирования следующим образом:
class Thing1Formatter {
private static Thing2Formatter thing2Formatter = new Thing2Formatter();
public format(Thing thing) {
thing2Formatter.format(thing.innerThing2);
}
}
class Thing2Formatter {
private static Thing1Formatter thing1Formatter = new Thing1Formatter();
public format(Thing2 thing) {
thing1Formatter.format(thing.innerThing1);
}
}
Да, я знаю HashMap, и немного больше кода может это исправить. Но "instanceof" кажется таким читаемым и понятным для сравнения. Есть что-нибудь простое, но не вонючее?
Примечание добавлено 5/10/2010:
Оказывается, что новые подклассы, вероятно, будут добавлены в будущем, и мой существующий код должен будет обрабатывать их изящно. HashMap on Class не будет работать в этом случае, потому что класс не будет найден. Цепочка операторов if, начиная с самого конкретного и заканчивая самым общим, в конце концов, вероятно, является лучшей:
if (obj instanceof SubClass1) {
// Handle all the methods and properties of SubClass1
} else if (obj instanceof SubClass2) {
// Handle all the methods and properties of SubClass2
} else if (obj instanceof Interface3) {
// Unknown class but it implements Interface3
// so handle those methods and properties
} else if (obj instanceof Interface4) {
// likewise. May want to also handle case of
// object that implements both interfaces.
} else {
// New (unknown) subclass; do what I can with the base class
}
10 ответов
Возможно, вас заинтересует эта запись из блога Стива Йегге на Amazon: "когда полиморфизм не удается". По сути, он рассматривает такие случаи, когда полиморфизм вызывает больше проблем, чем решает.
Проблема в том, что для использования полиморфизма вы должны сделать логику "обработки" частью каждого "переключающего" класса - то есть целочисленного и т. Д. В этом случае. Очевидно, это не практично. Иногда это даже не логически правильное место для кода. Он рекомендует подход "instanceof" как меньшее из нескольких зол.
Как и во всех случаях, когда вы вынуждены писать вонючий код, держите его в нажатом положении одним методом (или не более одного класса), чтобы запах не вытек.
Как подчеркивается в комментариях, шаблон посетителя будет хорошим выбором. Но без прямого контроля над целью / акцептором / посетителем вы не сможете реализовать этот шаблон. Вот один способ, которым шаблон посетителя мог бы все еще использоваться здесь, даже если у вас нет прямого контроля над подклассами с помощью оберток (на примере Integer):
public class IntegerWrapper {
private Integer integer;
public IntegerWrapper(Integer anInteger){
integer = anInteger;
}
//Access the integer directly such as
public Integer getInteger() { return integer; }
//or method passthrough...
public int intValue() { return integer.intValue(); }
//then implement your visitor:
public void accept(NumericVisitor visitor) {
visitor.visit(this);
}
}
Конечно, завершение финального класса может рассматриваться как отдельный запах, но, возможно, оно хорошо подойдет вашим подклассам. Лично я не думаю instanceof Это плохой запах здесь, особенно если он ограничен одним методом, и я бы с радостью воспользовался им (вероятно, по моему собственному предложению выше). Как вы говорите, он довольно читабелен, безопасен и удобен в обслуживании. Как всегда, будь проще.
Вместо огромного if, вы можете поместить экземпляры, которые вы обрабатываете в карту (ключ: класс, значение: обработчик).
Если поиск по ключу возвращается nullвызовите специальный метод-обработчик, который пытается найти соответствующий обработчик (например, вызывая isInstance() на каждом ключе на карте).
Когда обработчик найден, зарегистрируйте его под новым ключом.
Это делает общий случай быстрым и простым и позволяет обрабатывать наследование.
Вы можете использовать отражение:
public final class Handler {
public static void handle(Object o) {
try {
Method handler = Handler.class.getMethod("handle", o.getClass());
handler.invoke(null, o);
} catch (Exception e) {
throw new RuntimeException(e);
}
}
public static void handle(Integer num) { /* ... */ }
public static void handle(BigDecimal num) { /* ... */ }
// to handle new types, just add more handle methods...
}
Вы можете расширить идею общей обработки подклассов и классов, которые реализуют определенные интерфейсы.
Я думаю, что лучшим решением является HashMap с классом в качестве ключа и обработчиком в качестве значения. Обратите внимание, что решение на основе HashMap работает с постоянной алгоритмической сложностью θ(1), в то время как цепочка обоняния if-instanceof-else работает с линейной алгоритмической сложностью O(N), где N - количество ссылок в цепочке if-instanceof-else (т.е. количество различных классов, которые будут обработаны). Таким образом, производительность решения на основе HashMap асимптотически выше в N раз, чем производительность цепного решения if-instanceof-else. Учтите, что вам нужно по-разному обрабатывать разных потомков класса Message: Message1, Message2 и т. Д. Ниже приведен фрагмент кода для обработки на основе HashMap.
public class YourClass {
private class Handler {
public void go(Message message) {
// the default implementation just notifies that it doesn't handle the message
System.out.println(
"Possibly due to a typo, empty handler is set to handle message of type %s : %s",
message.getClass().toString(), message.toString());
}
}
private Map<Class<? extends Message>, Handler> messageHandling =
new HashMap<Class<? extends Message>, Handler>();
// Constructor of your class is a place to initialize the message handling mechanism
public YourClass() {
messageHandling.put(Message1.class, new Handler() { public void go(Message message) {
//TODO: IMPLEMENT HERE SOMETHING APPROPRIATE FOR Message1
} });
messageHandling.put(Message2.class, new Handler() { public void go(Message message) {
//TODO: IMPLEMENT HERE SOMETHING APPROPRIATE FOR Message2
} });
// etc. for Message3, etc.
}
// The method in which you receive a variable of base class Message, but you need to
// handle it in accordance to of what derived type that instance is
public handleMessage(Message message) {
Handler handler = messageHandling.get(message.getClass());
if (handler == null) {
System.out.println(
"Don't know how to handle message of type %s : %s",
message.getClass().toString(), message.toString());
} else {
handler.go(message);
}
}
}
Дополнительная информация об использовании переменных типа Class в Java: http://docs.oracle.com/javase/tutorial/reflect/class/classNew.html
Вы могли бы рассмотреть шаблон цепочки ответственности. Для вашего первого примера, что-то вроде:
public abstract class StuffHandler {
private StuffHandler next;
public final boolean handle(Object o) {
boolean handled = doHandle(o);
if (handled) { return true; }
else if (next == null) { return false; }
else { return next.handle(o); }
}
public void setNext(StuffHandler next) { this.next = next; }
protected abstract boolean doHandle(Object o);
}
public class IntegerHandler extends StuffHandler {
@Override
protected boolean doHandle(Object o) {
if (!o instanceof Integer) {
return false;
}
NumberHandler.handle((Integer) o);
return true;
}
}
а затем аналогично для других ваших обработчиков. Тогда это случай объединения вместе StuffHandlers по порядку (наиболее специфичный для наименее специфичного, с окончательным обработчиком 'fallback'), и ваш код отправки просто firstHandler.handle(o);,
(Альтернативой является использование цепочки вместо List<StuffHandler> в вашем классе диспетчера, и пусть он перебирает список до handle() возвращает истину).
Просто иди с instanceof. Все обходные пути кажутся более сложными. Вот сообщение в блоге, в котором говорится об этом: http://www.velocityreviews.com/forums/t302491-instanceof-not-always-bad-the-instanceof-myth.html
Я решил эту проблему, используя reflection (около 15 лет назад в эпоху до дженериков).
GenericClass object = (GenericClass) Class.forName(specificClassName).newInstance();
Я определил один общий класс (абстрактный базовый класс). Я определил много конкретных реализаций базового класса. Каждый конкретный класс будет загружен с className в качестве параметра. Это имя класса определяется как часть конфигурации.
Базовый класс определяет общее состояние для всех конкретных классов, а конкретные классы будут изменять его, переопределяя абстрактные правила, определенные в базовом классе.
В то время я не знаю названия этого механизма, который был известен как reflection,
Еще несколько альтернатив перечислены в этой статье: Map а также enum кроме размышлений.
Добавьте метод в BaseClass, который возвращает имя класса. И переопределите методы с определенным именем класса
public class BaseClass{
// properties and methods
public String classType(){
return BaseClass.class.getSimpleName();
}
}
public class SubClass1 extends BaseClass{
// properties and methods
@Override
public String classType(){
return SubClass1.class.getSimpleName();
}
}
public class SubClass2 extends BaseClass{
// properties and methods
@Override
public String classType(){
return SubClass1.class.getSimpleName();
}
}
Теперь используйте корпус переключателя следующим образом:
switch(obj.classType()){
case SubClass1:
// do subclass1 task
break;
case SubClass2:
// do subclass2 task
break;
}
Что я использую для Java 8:
void checkClass(Object object) {
if (object.getClass().toString().equals("class MyClass")) {
//your logic
}
}