Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Вот такое сейчас написал
PD>if(a == b) PD> a = b;
PD>Никакой ошибки здесь нет. Все так и должно быть. PD>Да здравствует перегрузка операций! Каким понятным она делает код!
PD>Придется к этому хороший комментарий написать, а то ведь Бог знает что могут подумать
Если код выглядит глупо — значит ошибка проектирования.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>if(a == b) PD> a = b;
PD>Никакой ошибки здесь нет. Все так и должно быть. PD>Да здравствует перегрузка операций! Каким понятным она делает код!
PD>Придется к этому хороший комментарий написать, а то ведь бог знает что могут подумать
Значит ты вложил какой-то странный смысл в одну из операций.
ЧС>Если код выглядит глупо — значит ошибка проектирования.
Код совершенно верный. Смысл всего этого такой
if(a==b)
a= b;
b — "старый" экземпляр класса. a — только что сделанный новый экземпляр.
Сравнение (операция ==) идет по бизнес-полям. Кроме бизнес-полей, есть еще другие поля, которые в сравнении не участвуют, и именно так и должно быть. В старом экземпляре эти поля установлены (точнее, прочитаны из БД, например, identity). В новом — равны 0.
Таким образом, смысл такой
Если новый экземпляр в бизнес-смысле равен старому, то взять старый (т.е с прежними значениями не-бизнес полей).
Здравствуйте, Mycopka, Вы писали:
Кё>>Значит ты вложил какой-то странный смысл в одну из операций.
M>Например сравнение по контенту, а присвоение по ссылке. Не виже большой странности, хотя удобочитаемость убийственная.
Ну нельзя так. Это как если бы для умного указателя переопределить == на сравнение содержимого, а не указателей.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Черепнин Сергей, Вы писали:
ЧС>>Если код выглядит глупо — значит ошибка проектирования.
PD>Код совершенно верный. Смысл всего этого такой
PD>if(a==b) PD> a= b;
PD>b — "старый" экземпляр класса. a — только что сделанный новый экземпляр.
PD>Сравнение (операция ==) идет по бизнес-полям. Кроме бизнес-полей, есть еще другие поля, которые в сравнении не участвуют, и именно так и должно быть. В старом экземпляре эти поля установлены (точнее, прочитаны из БД, например, identity). В новом — равны 0.
PD>Таким образом, смысл такой
PD>Если новый экземпляр в бизнес-смысле равен старому, то взять старый (т.е с прежними значениями не-бизнес полей).
PD>Вот и все.
В данном случае, всместо того чтобы замусоривать код коментариями, лучше
не перегружать ==, а использовать метод с осмысленным именем.
Здравствуйте, Шахтер, Вы писали:
Ш>В данном случае, всместо того чтобы замусоривать код коментариями, лучше Ш>не перегружать ==, а использовать метод с осмысленным именем.
Ну в действительности там стоит как раз вызов метода с вполне осмысленным именем.
public override bool Equals(Object other)
А сооружать еще один метод с другим именем и таким же кодом я точно не буду.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Шахтер, Вы писали:
Ш>>В данном случае, всместо того чтобы замусоривать код коментариями, лучше Ш>>не перегружать ==, а использовать метод с осмысленным именем.
PD>Ну в действительности там стоит как раз вызов метода с вполне осмысленным именем.
PD> public override bool Equals(Object other)
PD>
PD>А сооружать еще один метод с другим именем и таким же кодом я точно не буду.
Abuse.
Два объекта должны считаться равными, если они обладают одинаковым внешним поведением.
В этом случае заменять один другим бессмысленно.
Если же внешнее поведение разное, то мы имеем дело не с равенством, а с каким-то другим, болеее слабым отношением эквивалентности. Называть его словом Equals или == не стоит. Название должно отражать смысл данного отношения эквивалентности.
Здравствуйте, Mikhail Polykovsky, Вы писали:
PD>>Придется к этому хороший комментарий написать, а то ведь бог знает что могут подумать
MP>Напишите его сюда, пожалуйста.
Наверное, если поля объектов равны сделать чтобы обе переменные ссылась на один объект. Или типа того.
Здравствуйте, Шахтер, Вы писали:
Ш>Abuse.
Ш>Два объекта должны считаться равными, если они обладают одинаковым внешним поведением.
Два объекта должны быть равными, если при включении элемента в множество (в данном случае ISet из Iesi.Collection) при том, что равный ему там уже есть, никакого включения не будет. Проверку на равенство ISet делает по Equals, как ему и положено.
Мне не надо, чтобы объект включался дважды в сет, если равный ему (в бизнес-смысле) объект там уже есть. Это приведет к серьезным проблемам при сохранении в БД.
Таким образом, Equals написана так мной, чтот она отражает равенство в бизнес-смысле. Никак иначе я ее написать не могу, иное поведение мне не нужно.
Ш>В этом случае заменять один другим бессмысленно.
Ш>Если же внешнее поведение разное, то мы имеем дело не с равенством, а с каким-то другим, болеее слабым отношением эквивалентности. Называть его словом Equals или == не стоит. Название должно отражать смысл данного отношения эквивалентности.
Должен ли я после этого написать специально еще одну функцию с тем же кодом, что и у Equals ?
Здравствуйте, Шахтер, Вы писали:
Ш>Если же внешнее поведение разное, то мы имеем дело не с равенством, а с каким-то другим, болеее слабым отношением эквивалентности. Называть его словом Equals или == не стоит. Название должно отражать смысл данного отношения эквивалентности.
Отсюда вывод — перегруженные операции должны сохранять логический смысл исходных. Перегружать () для индексных операций — нельзя.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, McSeem2, Вы писали:
MS>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Вот такое сейчас написал
PD>>if(a == b) PD>> a = b;
MS>Мне время от времени приходится писать что-то типа: MS>
MS>if(a == 875)
MS>{
MS> a = a;
MS>}
MS>
MS>Угадайте с одного раза, для чего. Никакой перегрузки.
PD>Таким образом, Equals написана так мной, чтот она отражает равенство в бизнес-смысле. Никак иначе я ее написать не могу, иное поведение мне не нужно.
Разумно было бы сделать метод а-ля CopyTo и писать не a=b а b.CopyTo(a)
...Ei incumbit probatio, qui dicit, non qui negat...
McSeem2 wrote: > MS>>Угадайте с одного раза, для чего. Никакой перегрузки. > DШ>давай подсказку > Не дам! Ня-ня-ня...
Ээээ... Может чтобы проверить, что this — валиден?
Здравствуйте, McSeem2, Вы писали:
MS>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Вот такое сейчас написал
PD>>if(a == b) PD>> a = b;
MS>Мне время от времени приходится писать что-то типа: MS>
MS>if(a == 875)
MS>{
MS> a = a;
MS>}
MS>
MS>Угадайте с одного раза, для чего. Никакой перегрузки.
Чтобы поставить контрольную точку, на которой отладчик остановится, когда а будет равно 875. Контрольная точка ставится именно на строчку а = а.
Здравствуйте, Dirichlet, Вы писали:
D>Чтобы поставить контрольную точку, на которой отладчик остановится, когда а будет равно 875. Контрольная точка ставится именно на строчку а = а.
Бывают условные точки останова.
Здравствуйте, vitaly_spb, Вы писали:
PD>>Таким образом, Equals написана так мной, чтот она отражает равенство в бизнес-смысле. Никак иначе я ее написать не могу, иное поведение мне не нужно.
_>Разумно было бы сделать метод а-ля CopyTo и писать не a=b а b.CopyTo(a)
