Здравствуйте, коллеги!
Очень прошу помощи, советов.
Есть некая платформа (закрытое решение на C#, используется у самых разных клиентов). Там реализована связь между Employee и Person через наследование:

class Employee : IEmployee, NaturalPerson 
{
   Guid PersonID { get; set; } // - id человека, от которого унаследован экземпляр Employee - это фактически поле в БД.
}

По такому же принципу наследуются, например, банки от юр.лиц: class Bank : LegalPerson (и т.д.)
Правильно ли так вообще наследовать (повторюсь — это платформа и под конкретные задачи трудно что-то определить)?

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

------------------------------------ 8< ------------------------------------
// один и тот же человек, два сотрудника в разных конторах
employee1 = ...
employee2 = ...

person1 = (NaturalPerson)employee1 
person2 = (NaturalPerson)employee2

if (person1 == person2) // True или false?
if (employee1 == employee2) // True или false?

// добиваем:
if (person1 == employee2) // True или false?
------------------------------------ 8< ------------------------------------
//а теперь контрольный:
if (object.Equals(person1, person2))

// или, в словарик с ключом типа NaturalPerson добавлен employee1
if (someDictionaryByPerson.ContainsKey(employee2))
// ------------------------------------ 8< ------------------------------------

Подумал: а не переписать ли с использованием explicit operator (I)NaturalPerson, дабы не сильно ломать то, что есть, и включить в состав Employee весь Person. Т.е.:

public class Employee  : IEmployee
{
   public static exlicit operator /*I*/NaturalPerson(Employee e) { return e.Person; }
   NaturalPerson Person {get;set;}
}

Но! С другой стороны, насколько оправданы такие опасения (я про сравнения)?

Что скажете?..

ЗЫ. Сейчас наследование помогает при частых изменениях, добавляя новое поле не надо думать о том, где оно должно ещё появится в связанных классах; функции пакетной обработки так же, благодаря ковариантности, работают как надо со всеми унаследованными типами. Правда, и проблем, тоже огребаю по самое не хочу.