Реализация IEquatable <T>, где T является интерфейсом
Так как у Вас действительно есть два отдельных приложения, скомпилируйте их с различными версиями класса "Человек" - с приложением для получателя, не имеющим @XmlRootElement(name="person") на Person. Мало того, что это ужасно, но и это побеждает пригодность для обслуживания, которую Вы хотели от использования того же определения Человека и для отправителя и для получателя. Его один плюс - то, что это работает.
3 ответа
Вместо реализации IEquatable , не могли бы вы реализовать IEqualityComparer в отдельном классе? В большинстве случаев, когда вас интересует равенство, вы можете вместо этого указать компаратор, и я подозреваю, что так он будет чище.
На основании вашего вопроса кажется как будто вы знаете, каким будет алгоритм Equals и что он будет одинаковым для ClassA и ClassB. Почему бы не сделать следующее
- Определить IMyInterface для наследования от
IEquatable - Определить абстрактный базовый класс MyInterfaceBase, который реализует IMyInterface и имеет реализацию
IEquatableHave - ClassA и ClassB являются производными от MyInterfaceBase
Я бы подумал, что если интерфейс не может быть преобразован в абстрактный класс, не имеет большого смысла сравнивать два реализованных класса друг с другом напрямую или автоматически. Это означает, что реализация пользовательского сравнения для каждого класса будет правильным решением. Я уверен, что вы можете каким-то образом реорганизовать код сравнения, чтобы впоследствии было легче его изменить.