런타임 Java에서 오브젝트 유형을 판별해야합니다. 나쁜 디자인?

Question

입자 전송 코드를 쓰고 있습니다. 이 코드에서 실제 객체는 인터페이스 볼륨을 구현합니다. Volume의 한 구현자인이 코드의 경우 Particle 클래스입니다. 제 설계에서 볼륨은 다른 볼륨을 가장 작은 Volume 구현자인 Particle까지 포함합니다. 파티클이 상호 작용이있는 볼륨을 통해 모니터되지 않은 상태로 날아 다니기를 원한다면이 작업이 효과적입니다.

그러나 Particle detector에 대한 정보를 기록하는 Volume을 구현하려고 할 때 문제가 있습니다. Volume 인터페이스에는 Particle에있는 특별한 유형의 정보를 가져 오는 방법이 없습니다. Particle이 Detector Volume으로 나아가는 경우 볼륨에서 Particle으로 캐스트하고 Particle 메서드를 호출하기 전에 리플렉션을 사용하여 형식을 확인해야합니다. 일반적으로 (내가 본 것에서)이 유형의 것은 "나쁜 디자인"레이블로 표시됩니다.

볼륨 인터페이스의 볼륨 경계를 넘을 수있는 입자 만 만들 수 있습니다 (인터페이스를 특수한 경우 입자에 연결).하지만 코드에이 제한을 적용하고 싶지는 않습니다. 볼륨을 이동하고 나중에 참여하도록 허용 할 수 있습니다.

이렇게 나쁜 디자인처럼 들리니? 이 문제를 해결할 또 다른 확실한 방법이 있습니까? 필요한 경우 코드를 첨부 하겠지만 일반적인 문제는 내 세부 정보와는 독립적으로 보입니다 (그리고 언어와는 상당히 독립적입니다).

미리 감사드립니다. 나는 여기에 대한 모든 지식을 정말로 고맙게 생각한다.

Answer 1

내가 읽은 바로는 동적 캐스팅은 Java에서 끔찍한 것으로 간주되지 않습니다. 간단한 유형 검사는 전체 Reflection API를 사용하는 것보다 훨씬 덜 극단적입니다.

캐스팅하기 전에 동적 캐스팅을 시도하고 ClassCastException을 잡거나 isinstance Particle 검사를 수행 할 수 있습니다.

개념적으로 입자가 입자 감지기가 기록하고자하는 정보가 있음을 나타내는 인터페이스를 구현하는 것이 더 이해할 수 있습니다. 디자인에 대해 더 많이 알지 못하면 말할 수 없습니다.

Answer 2

입자와 같은 소리는 볼륨이 아니므로 볼륨은 다른 볼륨을 포함 할 수 있으며 입자는이를 수행 할 수 없습니다. 이는 Liskov Subsitiution Principle을 위반합니다. 파티클을 Volumes 인터페이스에서 상속받지 않고 대신 다른 것으로부터 상속받는 것을 고려해야합니다.

Answer 3

참조에 저장 될 수있는 모든 유형을 제어 할 수없고 일부 유형에 다른 기능이 부족한 경우 가장 실용적인 방법은 다음과 같은 기능을위한 인터페이스를 정의하는 것입니다. 질문, 객체가 원하는 인터페이스를 구현하는지 여부를 확인하고 객체가 필요한 경우이를 캐스팅합니다. 그러나 유형을 제어 할 수있는 경우 다른 접근 방식이 더 좋을 수 있습니다.

예를 들어 응용 프로그램에 해당 응용 프로그램에 고유 한 공통 기본 유형에서 상속 된 개체 모음이 있고 새 개체 유형이 발생했을 때이를 알릴 필요가있는 경우 해당 인터페이스에 대한 인터페이스를 정의 할 수 있습니다 알림을 보내고 모든 객체를 통해 응용 프로그램을 반복하고 인터페이스를 구현하는 사람들에게 알림을 보냅니다. 기본 유형에 기본 유형에 "알림"메소드를 추가하고 기본 유형에 모든 객체에 대해 해당 메소드를 호출 할 수도 있습니다 수집. 통지가 필요한지 여부를 테스트하는 메서드를 사용하는 것이 좋습니다 (응용 프로그램이 이러한 알림이 필요한 개체 만 포함하는 컬렉션을 유지 관리하는 옵션을 허용하기 위해). 그러나 대부분의 경우 무변화 메서드를 호출하는 것이 더 간단하고 메서드를 호출해야하는지 여부를 테스트하는 것보다 효율적입니다.