Почему GetHashCode не является свойством как HashCode в.NET

То, что происходит, - это то, что экземпляр проекта в вашем классе контроллера не изменяется, когда вы передаете его в класс Register, но проект в классе Register изменился, и это изменение не будет передано классу Controller, и путь к нему делать что-то вроде этого

class Controller():
    def __init__(self):
         self.project = Project()

    def proc(self):
        self.r = Register(self.project)
        self.r.load()
        self.project = self.r.project

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

10
задан Joan Venge 11 February 2009 в 21:12
поделиться

6 ответов

Я не думаю, что существует любое серьезное основание. Любой implemention GetHashCode должно быть достаточно быстрым для помещения в свойство. Тем не менее существует много недостатков дизайна в платформе .NET, некоторые маленькие, некоторые серьезные. Это походит на маленький.

4
ответ дан 3 December 2019 в 16:55
поделиться

Вероятно, потому что это требует вычисления и представления его, поскольку propery мог бы подразумевать, что хэш-код уже доступен бесплатно.

Править: Инструкции по этому: Свойства по сравнению с Методами

"Операция является достаточно дорогой, который Вы хотите передать пользователю, что они должны рассмотреть кэширование результата".

Возможно, GetHashCode является достаточно дорогим в некоторых случаях.

19
ответ дан 3 December 2019 в 16:55
поделиться

Необходимо помнить, что Платформа.NET разработана, чтобы быть полученной доступ большим разнообразием языков.

В теории Вы могли создать компилятор, который неспособен к правильно переопределяющим свойствам. В то время как это сделало бы для довольно дрянного компилятора, это не обязательно будет недопустимо. (Помните, что свойства являются просто методами с некоторыми метаданными),

-2
ответ дан 3 December 2019 в 16:55
поделиться

свойства должны только использоваться, если вычисление позади них действительно быстро или кэшируется

помимо большей части времени единственная логика в свойствах должна быть проверкой

0
ответ дан 3 December 2019 в 16:55
поделиться

Помимо того, что свойство является не чем иным, как методом получения и установки, с точки зрения дизайна свойство никогда не должно содержать никаких вычислений, кроме инициализации или проверки, например:

private object _obj;
public object Obj
{
  get
  {
    if(_obj == null)
    {
      _obj = new object();
    }
    return _obj;
  }
  set
  {
    if(value == badvalue)
    {
      throw new ArgumentException("value");
    }
    _obj = value;
  }
}

GetHashCode () не содержит обширных вычислений, но может содержать такие длительные операции (просто из-за того, что он может вычислять хэш-код объекта сложным образом), поэтому это метод, а не свойство.

1
ответ дан 3 December 2019 в 16:55
поделиться

Часто невозможно определить HashCode для класса, который делает, поскольку:

например. объекты класса не имеют четко определенную концепцию идентичности.

Поэтому обычно метод GetHashCode () генерирует исключение NotImplementedException. Если бы HashCode был свойством, это, конечно, привело бы к всевозможным проблемам, поскольку большинство людей (и отладчиков) полагают, что всегда допустимо получить значение свойства

2
ответ дан 3 December 2019 в 16:55
поделиться
Другие вопросы по тегам:

Похожие вопросы: