Проверка типов когда-либо в порядке?

Question

Проверка типов считается плохой практикой, даже если вы проверяете интерфейс? Я понимаю, что вы всегда должны программировать на интерфейс, а не на реализацию - это ли это значит?

Например, в PHP это нормально?

if($class instanceof AnInterface) {
   // Do some code
}

Или есть лучший способ изменить поведение кода в зависимости от типа класса?

Редактировать : Просто чтобы прояснить, я говорю о проверке, реализует ли класс интерфейс, а не только то, что это экземпляр определенного класса.

Answer 1

Пока вы следуете за LSP , я не вижу проблемы. Ваш код должен работать с любой реализацией интерфейса. Это не проблема, что некоторые реализации заставляют вас следовать различным путям кода, если вы можете корректно работать с любой реализацией интерфейса.

Если ваш код не работает со всеми реализациями интерфейса, то вам не следует использовать интерфейс в первую очередь.

Answer 2

В моей практике любая проверка на тип (а также приведение типов) всегда показывала, что что-то не так с кодом или с языком.

Поэтому я стараюсь по возможности избегать этого.

Answer 3

Если вы можете избежать проверки типа, вы должны; однако, один сценарий, где я нашел это удобным, был у нас веб-сервис, который принимал сообщение, но содержимое сообщения могло измениться. Мы должны были сохранить сообщение обратно в БД, чтобы получить правильный компонент для разбиения сообщения на его надлежащие таблицы, мы в некотором смысле использовали проверку типов.

То, что я считаю более распространенным и гибким, чем если ($ class instanceof SomeOtherType) определить, например, стратегию IP-обработки, а затем с помощью фабрики, основанной на типе $ class, создать правильный класс.

Так что в c # примерно так:

void Process(Message msg)
{
    IProcessor processor=ProcessignFactory.GetProcessor(msg.GetType()); 
    processor.Process(msg); 
}

Однако иногда это может быть излишним, если вы имеете дело только с одним вариантом, который не изменится, реализуйте его, используя проверку типа, и когда / если вы обнаружите, что вы ошиблись и требуется больше проверок, то реорганизуйте его в более надежный решение.

Answer 4

Проверка типов во время выполнения часто необходима в ситуациях, когда интерфейс предоставляет все методы, необходимые для выполнения чего-либо, но не предоставляет достаточно для его успешного выполнения. Ярким примером такой ситуации является определение количества элементов в перечисляемой последовательности. Можно сделать такое определение, перечислив последовательность, но многие перечисляемые объекты «знают», сколько элементов они содержат. Если объект знает, сколько предметов он содержит, то, вероятно, будет более эффективно спросить его, чем перечислять в коллекции и подсчитывать предметы по отдельности.

Возможно, IEnumerable должен был предоставить несколько методов, чтобы спросить, что он знает о количестве элементов, которые он содержит [признавая возможность того, что объект может знать, что число не ограничено или что оно не более 4591 (но может быть намного меньше) и т. д.], но это не так. Что могло бы быть идеальным, было бы, если бы была произведена новая версия интерфейса IEnumerable, которая включала бы реализации по умолчанию для любых «новых» методов, которые он добавляет, и если такой интерфейс мог бы рассматриваться как реализованный любыми реализациями настоящей версии. К сожалению, поскольку такой функции не существует, единственный способ получить счетчик перечислимой коллекции без ее перечисления - проверить, реализует ли она какие-либо известные интерфейсы коллекции, включающие член Count.