Великая Пирамида Древнего Кода
Подробнее
public override bool Equals(object obj) { if (!obj is User) return false; if (((User)obj).FirstName — this.FirstName) { if (((User)obj).LastName — this.LastName) { if (((User)obj).EmailAddress this.EmailAddress) { if (((User)obj).Password — this.Password) { if (((User)obj).AvatarURL — this.AvatarURL) { if (((User)obj).DisplayName =** this.DisplayNarae) { if (((User)obj).Language -- this.Language) { if (((User)obj).PhoneNumber — this.PhoneNumber) { if (((User)obj).LastLoginDate — this.LastLoginDate) { if (((User)obj).RegistrationDate -• this.RegistrationDate) { if (((User)obj).DateOfBirth — this.DateOfBirth) { if (((User)obj).Address — this.Address) { if (((User)obj).SuitNo — this.SuitNo) { if (((User)obj).ZipCode -« this.ZipCode) { if (((User)obj).State «= this.State) { if (((User)obj).Country — this.Country) if (((User)obj).AccountBalance — this.AccountBalance) { if (((User)obj).SecretQuestionCode -• this.SecretQuestionCode) { if (((User)obj).SecretQuestionAnswer — this.SecretQuestionAnswer) { if (((User)obj).LastPurchaseDate — this.LastPurchaseDate) { if (((User)obj).Fetish — this.Fetish) { return true; > } > > } a > > return false;
it-юмор
Еще на тему
На каждое условие поставить отрицание, если оно срабатывает - возвращать false.
В самом днище вернуть true.
Да и там 95% проверок вообще нафиг не нужны для логики работы приложения, можно даже ID сделать уникальный, который и на уровне БД будет контролироваться и гарантировать идентификацию конкретного Юзера внутри самого приложения. А ещё представим, что мы сравниваем две копии Юзера, одна до внесения изменений в понравившееся мне поле User.Fetish, а другая после - и один и тот же по сути Юзер уже не эквивалентен самому себе.
public override bool Equals(object obj) => obj is User user && user.x == this.x && ...
В данном, конкретном случае я вижу только фиксированный перечень свойств.
Методы для экземпляров будут содержать одни и те же ссылки.
Следовательно. Все будет работать.
Этот "фиксированный перечень свойств" может быть иметь свойства, которые не должны сравниваться (в каждом экземпляре они могут быть разные). И если есть свойства, доступные по значению, то ты будешь сравнивать адреса, а не значения. :/
Экземпляры одного класса не могут иметь разных свойств.
Ещё раз повторю, что в данном конкретном куске кода все будет работать через логический оператор. Применительно к (справедливо замеченным ниже поправкам ЯП - Шарп) оператр будет сравнивать объекты приведенные к определенному типу данных.
Итого. Даже с учётом моих косяков.
Приводим к одному типу объекта и сравниваем объекты.
Если надо проверить ряд свойств - делаем какой-нибудь toString по перечню свойств нужных для сравнения - простой конкатенацией. Сравниваем.
И т.д. и т.п.
Да и то, что написано выше обернуть в метод класса. Это кагбэ тривиально.
Можешь сериализовать и сравнить строки. И ещё
Стопицот вариантов
Кто ж запрещает.
адреса в памяти в php
Пусть будут адреса. По адресам находятся объекты.
Физически - области памяти. Примени соответственно методами доступными в конкретном ЯП.
а вариантов в упрощении 2а, либо через рефлексию перебор параметров по атрибутам, не эффективно но в рот ебать, зато не этот ужас, и добавлять ноывые проверяемые элеметы проще, просто въебать их в класс и усе
либо завести массив типа
static List> conditions = new List>() {
(a, b) => a.FirstName == b.FirstName,
(a, b) => a.LastName == b.LastName
};
lst.All(f => user1, user2);
return
a.FirstName == b.FirstName &&
a.LastName == b.LastName &&
...
a.Fetish == b.Fetish;
не устроило?
да это менее эффективно чем портянка, но я вообще не понимаю зачем использовать шарп если нужна производительность, единственное чем он мне нравится так это гибкость и быстрота разработки, нужна скорость юзай ++
var u = obj as User;
return u != null && (u == this || (u.FirstName == this.FirstName && u.LastName == this.Last name ... ... u.Fetish = this.Fetish));
рефлексия медленная и не даст контроля над списком сравниваемых полей. А вообще Equals переопределять не надо, ни к чему хорошему это не приведёт.
я поэтому и написал, что не эффективно, но если используется не часто, то допустимо, особенно если полей дофига, и они будут добавляться, проще пометить атрибутом нужные поля и оставить все на рефлексию, чем лесть и править портянки
твой вариант я и сам использую если код для себя, но это один хер огромная портянка неудобная для чтения
https://msdn.microsoft.com/ru-ru/library/2dts52z7(v=vs.110).aspx
весь WPF это сплошная рефлексия, там плюнуть негде попадешь в рефлексию
можно запилить один хелпер, и иметь во все щели все объекты опятьже руля лишь атрибутами
Результат:
user1 & user2 are different
user1 & user3 are different
user2 & user4 are equivalent
=> if(!(obj is user)