И как же я в таком случае буду узнавать, столкнулся солдат с себеподобным, или же его задавил танк? ) Или он при хотьбе наткнулся на стоящий джип, например.
Этот вариант исключен.
У меня в сеттере помимо простого назначения, еще и получаются разные свойства от передаваемого объекта, например тип солдата, в соответствии с которым ему задается максимальная скорость, выносливость, передается ссылка на массив "отряд" и т.д. Короче говоря, во-первых я не понимаю, чем вариант со звездочкой в сеттере лучше или красивее изначалного (со звездочкой в userData), а во-вторых, с ним мне все равно пришлось бы приводить к типу и делать те же проверки.

Мой вывод: звездочка полезна, и нужна.

п.с. Никаких претензий к скорости исполнения такого кода у меня нет совершенно. Все работает так быстро, как мне и нужно.

Архитектуру пересмотреть не желаете? Пока не поздно...

Может, Вы просто кода кусочек покажете, потому что я решительно не понимаю, о чем Вы. Когда Вам надо будет узнать, солдат это или танк, Вы как ни крутите, будете проверять тип. Что со звездочкой, что с IForce. Вот только "в звездочку" залезет любая зараза, а в IForce – только боевые силы.
Надеюсь, это не ко мне? Потому что я вроде доказывал что от звездочек надо избавляться в пользу интерфейсов.
Ладно, ну объясните мне по существу, по конкретному вопросу: зачем ЭТО?
Что по-вашему здесь делает кастинг? Какова его ответственность? Какие изменения он инициирует? Что делает возможным, или какой оставляет след?

архитектуру чего? бокс2д? ) Это к Эрину Катто.
У меня в приложении архитектура нормальная.
Не залезет туда ничего кроме IMovable и ISoldier. Кусочек кода показывать смысла не вижу, я же не вопросы тут задаю ) Меня в моем коде все устраивает. Работает отлично, написано все чисто и понятно.
Вместо IForce тут можно было бы и просто DisplayObject заюзать. Но не вижу необходимости.

Да это вообще простейший пример был. Какая разница что он тут делает? Это просто пример того, что Object не всегда можно использовать вместо *, и ничего более.

бокс 4Ы, естессна.

В общем ладно, хватит меня убеждать, что звездочка зло )
Ничего плохого в ней нет, если не злоупотреблять.

Вопрос то был в другом: Object == * ?
ответ: нет.

Это был пример того, что Object не реализует интерфейс IDisposable, а для звездочки никто этого не проверяет.
То есть вместо интерфейса нельзя подсунуть Обжект, а вместо любого класса – можно? Я сегодня спать спокойно точно не буду.
И получаем абсолютно ту же ошибку.

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

Если вы знаете что она может вернуть несколько типов, лучше проверить их на выходе с помощью switch-is инструкций

Добавлено через 2 минуты
Звездочка - зло ))) я это отношу туда же, куда и обращение вида parent.parent.parent - вроде синтаксис позволяет, но использовать никому не порекомендую.

На вопрос Вы ответили верно, Object != *

Я и сам это знаю. Мог и не писать as IDisposable, ничего бы не изменилось
Что-то я не понял вопроса. Пора мне наверное спать идти уже ))
Тут каждый решает для себя сам.

Благодарю, Капитан! Имелось ввиду, что в рамках одного проекта вероятность возникновения ситуации, когда не известен тип возвращаемого, или вообще его наличие (единственное, где нам поможет *) стремится к 0.