Атомарные свойства создания основ C#
У меня была эта проблема, не уверенная, если она поможет, но мой был вызван при наличии двух различных версий того же проекта, на который ссылаются два различных решения. Когда я создал решение со ссылкой на корректный проект сначала, второе решение создаст прекрасный, однако, если бы я убрал первое решение и попытался создать второе решение, то это перестало бы работать с этими dll ссылочными сообщениями об ошибках.
решение для меня выясняло, что у меня было два проекта с тем же именем, которое было случайно дублировано и удаление ссылки на старый неправильный проект и добавление ссылки на новую.
В любом случае кажется, что эти сообщения являются определенным отвлекающим маневром, я проверил бы Ваш вывод сборки и нашел бы первый проект, которому не удается создать и очень тщательно проверить ссылки на том проекте.
5 ответов
Microsoft действительно пытается сказать: «Не создавайте свой класс таким образом, чтобы вызов свойств в произвольном порядке привел к неожиданному поведению». Пользователи вашего класса не ожидают, что запрос значения (с использованием свойства) будет иметь неудобные побочные эффекты.
Это подпадает под принцип наименьшего удивления.
Я думаю, что это полностью практичное руководство следовать. Свойства не должны иметь неожиданных побочных эффектов.
Вы поднимаете отличный вопрос: «Как вам удается сохранять независимость ваших свойств друг от друга?». Очень осторожно! Я исключаю состояние (и соответственно уменьшаю количество свойств) в максимально возможной степени. Кроме того, еще одна тактика - разделение состояния путем разделения классов. Само по себе это был бы отличный вопрос ...
Что касается класса треугольников, я думаю, что оба решения, которые вы представили в коде, действительны. Если бы это зависело от меня, я бы спроектировал треугольник так, чтобы он был неизменным, и взял бы ширину и высоту в конструкторе.
Думаю, я бы выбрал класс Triangle, у которого есть конструктор, который принимает Base и Height в качестве параметров, поскольку Triangle не может существовать (imho) без основания или высоты.
В другом месте свойство Area зависит от Base & Height, а я не вижу в этом проблемы? Я думаю, что руководство MS следует интерпретировать следующим образом:
свойства не должны зависеть от друг друга и не полагаться на установить в любом определенном порядке.
Это означает, что у вас не должно быть ограничения, которое вы должны сначала установить для свойства Base, и только после того, как свойство Base было установлено, вы можете установить свойство Height.
I think that this is what is meant by the above guideline.
Next to that, your Area property is not settable, thus there is no problem with it. :)
Некоторые свойства будут внутренне связаны и взаимозависимы. Дело в том, что сначала установка базы, затем высоты должна иметь тот же эффект, что и установка высоты, а затем базы. Если не установить один из них, тогда проверка области не имеет смысла.
Choose option 2. Make Area a method and call it CalculateArea. Properties should be used to encapsulate state and not behavior. That Area can be calculated from Base and Height does not mean that it should itself be state; on the contrary, this is a strong argument that Area should not be state.
class Triangle
{
public Triangle(double b, double h)
{
Base = b;
Height = h;
}
public double Base { get; set; }
public double Height { get; set; }
public double CalculateArea()
{
return (Base * Height) / 2;
}
}
This lets consumers know that getting the area of the triangle requires real work, rather than simply accessing state.
Простейшим способом было бы принять значения базы и высоты только в конструкторе, а затем предоставить их все как свойства только для чтения:
class Triangle
{
private double base;
private double height;
private Triangle() { }
public Triangle(double base, double height)
{
this.base = base;
this.height = height;
}
public double Base
{
get
{
return this.base;
}
}
public double Height
{
get
{
return this.height;
}
}
public double Area
{
get
{
return (this.base * this.height) / 2;
}
}
}