Я думаю, что вы говорите:
public class A {
}
public class B extends A {
}
позже в коде:
A apple = new A();
B banana = new B();
Вот несколько вариантов, которые могут оказаться полезными:
if (apple.getClass() == A.class) { // Found an A }
if (banana.getClass() == A.class) { // This is not an A, won't get here. }
if (apple instanceof A) { // This is definitely an A }
if ((apple instanceof A) && (!(apple instanceof B))) { // It's an A but not a B }
Что касается последнего варианта, вы пишете следующее:
Конечно, я могу написать что-то вроде
"объект intaceof A &&! (объект
экземпляр б) "но это очень
плохой дизайн, так как мне нужно изменить
код каждый раз, когда я добавляю новый
подклассы для А. Лучшие альтернативы?
Полиморфизм почти всегда помогает нам здесь. Ваша точка зрения об изменении кода каждый раз, когда вы добавляете подкласс, является именно тем симптомом, который вы должны признать стандартным развитием объектно-ориентированного проектирования. Подумайте о поведении, которое вы пытаетесь произвести. Можете ли вы вставить это в сам класс, а не делегировать его внешнему поставщику, который должен определить, над каким классом он работает в настоящее время?
Без дополнительной информации я не могу дать слишком много указаний, но вот довольно простой пример:
// Instead of this
if (apple.isClassA()) { // run class A code
} else if (apple.isClassB()) { // run class B code
// And so forth
}
Измените дизайн, чтобы он стал более похожим на:
public class A {
public void executeCommand() {
// run class A code
// This method knows that it's definitely an A, not a B
}
}
public class B extends A {
public void executeCommand() {
// run class B code
// This method knows that it's a B (and, therefore, an A as well).
}
}
Где позже в коде выполнения вы заменяете предыдущий тест if следующим:
apple.executeCommand();
banana.executeCommand();
По общему признанию, это почти тривиальный объектно-ориентированный обзор проекта, но он может расшатать что-то и помочь вам с проблемой подклассов.