Добрый день.

Есть разные классы от одного предка (SomeClass). Внутри функции необходимо определить, какой из этих классов был передан через параметр типа SomeClass.

Вопрос в следующем - что будет производительнее: проверять переданный object при помощи оператора is на соответствие всем этим классам по-очереди, или создать у класса SomeClass поле перечеслимого типа (которое содержало бы "идентификаторы" всех дочерних классов) и проверить это поле через switch?

Вопрос можно переформулировать еще проще - что производительнее: an_object is SomeClass2 или an_object.OurType == OurTypes.SomeClass2?

Заранее спасибо .

amarenkov, быстрее будет конечно-же 

но правильнее все-таки 

т.к. более наглядно отображает смысл.
P.S. А еще лучше приведи фрагмент кода, где ты хочешь использовать такую проверку.

Это сообщение отредактировал(а) DVariuS - 25.6.2009, 13:45

Это зависит от архитектуры и зачем оно нужно. Например если у тя много класов, то для каждого создавать перечислимое поле - геморно. Тем более информация будет повторяться - уже есть тип класа, то зачем же его еще прописывать в поле?
Но перечисляемые поля имеют свой "+". Где-то можно добавить какую-то гибкость, не усложняя при этом иерархию:


Добавлено @ 14:08
И вообще помойму is будет быстрее ==. Ток вопрос на самом деле не в скорости, а удобстве. Я надеюсь)

Это сообщение отредактировал(а) archeg - 25.6.2009, 14:09

amarenkov, быстрее - и правильнее - не писать switch или цепочку if-else по типам, а вынести типозависымый код в виртуальные функции. 
Это классический Switch Code Smell, вот пример с картинкой: https://elearning.industriallogic.com/gh/su...evLanguage=Java

Не получится . 

Задача (если сильно упростить) сводится к работе с графическими объектами. Есть базовый Figure, и есть наследники: Point, Line, Polygon и т.п.

И есть функция отрисовки. Вне этих классов. Вносить эту функцию в них я категорически не хочу, т.к. это было бы некорректно с точки зрения модели .

Вот, собственно, и все. В функцию отрисовки передается Figure. Функция должна узнать, что это за фигура такая и отрисовать ее.

В принципе, вопрос снимается.

Сделал простой тест, и на 1 000 000 объектов проверка через перечислимый тип дает 156 250 тиков, а через is - 312 500. 

Жаль . Хотелось сделать красивее, через is, но быстрее через перечислимый тип.

Хоть это и банально, но
"Преждевременная оптимизация - корень всех зол"

Вот если после написания прога будет тормозить, и профайлер покажет, что данная проверка это слабое место по производительности, тогда и оптимизируй. Хотя многие опытные люди говорят, что обычно слабое место оказывается совсем не там где предполагали разработчики, а от оптимизации второстепенных(в плане производительности) кусков кода толку будет мало и читабельность программы ухудшится.

amarenkov,

Что мешает в каждый из классов добавить виртуальный метод Render, когда каждый элемент сам знает как себя нарисовать?

Это вообще-то корректно с точки зрения модели, более того - пример с фигурами и функцией отрисовки есть практически в любой книжке по ООП, в главе про полиморфизм. Настолько корректно, что пример даже есть в MSDN, в топике Полиморфизм (руководство по программированию в C#). Figure по ненашему Shape, кстати.

А если включить саму отрисовку, то результат будет 300 и 301. 1 тик стоит жертвы. 

не хочешь в классе делать (например, если класс этот представляет из себя нечто вроде DTO) - вынеси в стратегию
только тогда придётся параллельно вести две иерархии, что само по себе не очень удобно, но порой оправдано


Это сообщение отредактировал(а) mihryak - 26.6.2009, 11:27

mihryak, сорри...не очень ясно с какой целью Figure ака Shape в метод Render передавать надобно?


а то получается какая-то циклическая зависимость... Figure содержит IRenderStrategy...а потом в Render этого интерфейса тоже надо передать Figure... просто сугубо интересно - зачем?

хм, это вполне обычный ход

конкретная фигура имеет собственную стратегию отрисовки, а стратегия общая для всех фигур определённого класса
это может позволить, например, держать один инстанс стратегии на все её фигуры, позволяет сделать её stateless

mihryak, ok, идея ясна