Czy IEquatable <T>, IComparable <T> może być zaimplementowane w klasach nie zamkniętych?

Każdy ma jakieś opinie na temat tego, czyIEquatable<T> lubIComparable<T> powinien na ogół tego wymagaćT jestsealed (jeśli to jestclass)?

To pytanie przyszło mi do głowy odkąd piszę zestaw klas bazowych, które mają pomóc w implementacji niezmiennych klas. Część funkcjonalności, którą ma zapewnić klasa bazowa, to automatyczna implementacja porównań równości (przy użyciu pól klasy wraz z atrybutami, które można zastosować do pól w celu kontroli porównań równości). Powinien być całkiem niezły, gdy skończę - używam drzew ekspresowych do dynamicznego tworzenia skompilowanej funkcji porównania dla każdegoT, więc funkcja porównania powinna być bardzo zbliżona do wykonywania regularnej funkcji porównywania równości. (Używam niezmiennego słownikaSystem.Type i podwójnie sprawdzaj blokadę, aby przechowywać wygenerowane funkcje porównania w sposób, który jest wystarczająco skuteczny)

Jedna rzecz, która jednak pojawiła się, to jakie funkcje mają być używane do sprawdzania równości pól składowych. Moim początkowym zamiarem było sprawdzenie, czy typ pola każdego członka (do którego zadzwonię)X) narzędziaIEquatable<X>. Jednak po zastanowieniu nie sądzę, aby można było bezpiecznie używać, chyba żeX jestsealed. Powodem jest to, że jeśliX nie jestsealed, Nie wiem na pewno, czyX odpowiednio przekazuje kontrolę równości do metody wirtualnejX, dzięki czemu podtyp może zastąpić porównanie równości.

Pojawia się wtedy bardziej ogólne pytanie - czy typ nie jest zapieczętowany, czy naprawdę powinien implementować te interfejsy w ogóle? Myślę, że nie, ponieważ twierdziłbym, że umowa dotycząca interfejsów polega na porównaniu dwóchX typy, nie dwa typy, które mogą, ale nie muszą byćX (oczywiście muszą byćX lub podtyp).

Co myślicie? PowinienIEquatable<T> iIComparable<T> unikać w przypadku klas niezapieczętowanych? (Zastanawia mnie też, czy istnieje reguła fxcop)

Moją obecną myślą jest, aby moja generowana funkcja porównania była używana tylkoIEquatable<T> na polach członkowskich, którychT jestsealedi zamiast tego użyć wirtualnegoObject.Equals(Object obj) JeśliT jest rozpieczętowany, nawet jeśliT narzędziaIEquatable<T>, ponieważ pole może potencjalnie przechowywać podtypyT i wątpię w większość wdrożeńIEquatable<T> są zaprojektowane odpowiednio do dziedziczenia.

questionAnswers(4)

yourAnswerToTheQuestion