Необходимо определить тип объекта во время выполнения Java.Плохой дизайн? - PullRequest
0 голосов
/ 18 октября 2011

Я пишу код переноса частиц.В этом коде физические объекты реализуют интерфейс Volume.Один из примеров реализации Volume представляет интерес для этого кода - класс Particle.В моем дизайне Тома содержат другие Тома вплоть до самого маленького реализатора Тома, Particle.Это будет прекрасно работать до тех пор, пока Частицы хотят летать без наблюдения через тома, имеющие взаимодействия.

Однако, в тот момент, когда я хочу реализовать какой-то объем детектора частиц, который будет записывать информацию о частице, у меня возникла проблема.Интерфейс Volume не содержит способа получить специальный тип информации, которую имеет Particle.Если Частица пробьется в Объем детектора, мне нужно будет сделать что-то вроде проверки ее типа с помощью отражения, прежде чем я приведу ее к Частице из Объема и вызову методы Частицы.Обычно (из того, что я видел) этот тип вещей помечается меткой «плохой дизайн».

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

Так это звучит как плохой дизайн?Есть ли другой очевидный способ справиться с этой проблемой?Я приложу код, если это необходимо, но общая проблема кажется независимой от моих данных (и довольно независимой от языка).

Заранее спасибо.Я действительно ценю все знания здесь, на SO.

Ответы [ 3 ]

1 голос
/ 18 октября 2011

Мне кажется, что частицы на самом деле не объем, потому что объемы могут содержать другие объемы, а частицы не могут этого сделать.Это нарушает принцип подстановки Лискова .Вы должны учитывать, что частицы не наследуются от интерфейса Volumes, а вместо этого наследуются от чего-то другого.

1 голос
/ 18 октября 2011

Из того, что я прочитал, динамическое приведение не считается ужасным в Java.Простая проверка типов намного менее экстремальна, чем использование полного API Reflection.

Вы можете либо выполнить динамическое приведение и поймать возможное ClassCastException, либо выполнить проверку isinstance Particle перед приведением.* Концептуально, для Particles может иметь смысл реализовать интерфейс, который указывает, что у них есть информация, которую ваш детектор частиц хочет записать.Не зная больше о вашем дизайне, мы не можем сказать.

0 голосов
/ 16 апреля 2013

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

Например, если приложение имеет коллекцию объектов, которые все наследуются от общего базового типа, уникального для этого приложения, и о новом типе объекта необходимо уведомлять, когда что-то происходит, можно определить интерфейс для такого уведомления и иметь прикладную петлю через все объекты и отправлять уведомления тем, кто реализует интерфейс, но можно также добавить к базовому типу метод notify «notify» к базовому типу и вызывать этот метод для всех объектов в коллекции , Также может быть полезно иметь метод для проверки необходимости уведомления (чтобы позволить приложению поддерживать коллекцию, содержащую только объекты, требующие такого уведомления), но во многих случаях вызов метода бездействия будет проще и более эффективен, чем проверка необходимости вызова метода.

...