Должен ли я реализовать IEquatable или IComparable?

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

Однако бывает так, что редко бывает, что нужно оценивать эти вещи, но часто нужно проверить, равны ли две такие вещи.

Итак, я могу реализовать как IEquatable для моего класса, так и IComparable. Хотя IComparable предоставляет некоторые дополнительные функции, маловероятно, что кто-то будет заботиться об этой дополнительной функциональности. Ни один из них, по-видимому, не дает явного преимущества, логически или функционально.

Какой интерфейс мне следует реализовать, IEquatable, IComparable или и то, и другое? Зачем? (Я просто задаюсь вопросом об изменениях в рамках всего интерфейса или интерфейса)

Этот вопрос похож, но ответы только указывают на очевидное, что не помогает мне.

В случае, если вам интересно, класс должен представлять нуклеотид. Нуклеотиды можно легко отождествлять, но их также можно сравнить (например, в алфавитном порядке).

Ответ 1

Я бы определенно реализовал IEquatable<T>, но пока пропустил IComparable/IComparable<T>.

Как вы сказали, нет никакого способа сравнить нуклеотиды. Кому-то может потребоваться сравнить их в алфавитном порядке, кому-то может понадобиться другой способ их сортировки. Я бы предпочел предоставить различные реализации IComparer<Nucleotide> для реализации самой IComparable/IComparable<T>.

Ответ 2

В первую очередь это основано на мнениях, но я бы не реализовал IComparable, если сопоставимость не очевидна (как в числе). Например, если кто-то хочет сортировать нуклеотиды, он может предоставить свою собственную реализацию IComparer. В качестве автора библиотеки я бы предоставил набор возможных IComparer s, например, чтобы отсортировать их по алфавиту, как вы сказали.

Ответ 3

Если объекты по своей сути сопоставимы, я бы выполнил дополнительную работу и выполнил IComparable<T> поверх IEquatable<T>. Как автор этого типа вы находитесь в лучшем положении для обеспечения правильной реализации. Оставляя его другому разработчику для реализации, увеличивается вероятность следующего события.

Неправильное внедрение сравнения. Другие разработчики, скорее всего, будут менее знакомы с данными, чем вы, и, следовательно, с большей вероятностью будут пропускать угловые случаи.
Повторяющееся кадо. Если вы не предоставите сравнение defacto, каждый разработчик отдельно должен сделать это сам, что приведет к дублированию кода.

Ответ 4

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

Трудно решить, как долго будет выполняться будущая коррекция. Но при добавлении дополнительной функции будущего относительно просто, я всегда предпочитаю не делать их. Вы можете обнаружить, что вам никогда не нужно IComparable, и даже если это крошечное дополнение, оно по-прежнему требует обслуживания и рассмотрения.