If you are familiar with OOP and its standard terminology, then you should probably be aware that the field and the property are different concepts that look alike. In your question, you obviously call the property that in OOP is called a field. However, the property is something else. A property is essentially syntactic sugar over a method (or a pair of methods) for returning a certain value. More specifically:
class Person { // это поле. Не свойство private int _someField; // а вот это уже свойство public int Age {get; set; } }
So far both of them look similar to each other (equal to the fact that we spent a little more than characters on property declaration). However, the difference, and quite significant, is still there. As already mentioned, the property is syntactic sugar, and the above example for the compiler will be something as follows:
class Person { // то же самое поле, ничего нового private int _someField; // весь код, описанный ниже // представляет собой то, // во что раскрывается свойство private int age; public int get_age() { return age; } public int set_age() { return age; } }
What is it for? You can do the usual field and not fool yourself a head. It turns out you need. A field is simply a "piece" of data, or even a "guts" of a class, and the end user can do anything with these "guts" just give him a free rein. For example, if this field is a person's age, then the end user can easily make this age negative, or very large, which can break the internal logic of the program. Therefore, it would be more convenient to wrap the field in some kind of logic that would limit the user's riot (by the user here is meant the programmer who will work with this class). For example:
class Person { private int _age; public int Age { get { return _age; } set { if(value <= 0 || value > 120) throw new SomeException("A terrible exception was thrown!"); } } }
Already more reliably - the user can not break the logic associated with age. The same could be done with a private _age field and a couple of public methods GetAge and SetAge, but it looks more elegant (an impression is created that Age is still a field) and less code is spent. Plus, you can always make public only a getter or only a setter, which is not the case with a field.
Now regarding your question - the property that returns the area of the figure should just be something like
// вариант для прямоугольника public override double Square { get { return _width * _height; } }
where _width and _height are the fields in which the length and width are stored respectively. It is not a good idea to calculate the area in the constructor, and without this there is something to do, especially since if the size of your figure changes during the life of the object, then it is completely useless.
ZY By the way, a little funny either a bug or a feature of the language: The following, seemingly quite correct code will not be compiled:
public class Foo { public int Prop { get; set; } // ошибка public int get_Prop() { return 10; } }
In the line marked with a comment, the compiler will tell you that the get_Prop method has already been declared. This is obviously due to the fact that the Prop compiler decomposes the property into a couple of get_Prop and set_Prop methods (plus the corresponding field).
