Actually, the question is: properties (auto-property) in c # is this behavior or the state of an object?

    3 answers 3

    We define the terminology:

    1. The object possesses state and behavior. ( Grady Booch )

      I will underline once again object . Not a type, not a class (the class only describes the future object), but an object .

    2. The state of an object is characterized by a list (usually static) of all properties of a given object and the current (usually dynamic) values ​​of each of these properties. (see the link in point number 1)

    3. Behavior is how an object acts and reacts; behavior is expressed in terms of the state of the object and the transfer of messages. In other words, the object's behavior is its observed and externally verifiable activity. (see the link in point number 1)

    4. A property is a member that provides a flexible mechanism for reading, writing, or calculating the value of a private field. Properties can be used as if they were members of shared data, but in fact they are special methods called access methods. This makes it easy to access data and helps improve the security and flexibility of methods. (link to MSDN see below)

    5. Properties allow you to access a method in the source code of a program using a simplified syntax. (Link to Richter see below)

    6. Careful approach to the definition of properties. Personally, I don’t like properties, and I would be happy if their support was removed from the Microsoft .NET Framework and related programming languages. The reason is that properties look like fields, actually being methods. This creates a lot of misconceptions and misunderstandings. Faced with the code that accesses the field, the developer habitually assumes the existence of a mass of conditions that are simply not always true when it comes to the property. (Link to Richter see below)

    And now let's figure out what's what. An example from the same Richter chapter 9.

    public sealed class Employee { private String m_Name; // Это состояние private Int32 m_Age; // Это состояние public String GetName() // Это поведение { return(m_Name); } public void SetName(String value) // Это поведение { m_Name = value; }

    Equivalent to this example from the same chapter (Richter himself says it himself):

     public sealed class Employee { private String m_Name; // Это состояние private Int32 m_Age; // Это состояние public String Name // Это поведение { get { return(m_Name); } set { m_Name = value; } } }

    Here it becomes clear that properties are the mechanism of access to closed fields, which is carried out through methods. And that means Properties is a behavior . Richter just criticizes the properties for the fact that they look like fields, and in fact these are methods (which gives access to private fields). Richter generally proposes to remove the properties in order to avoid confusion (in the book he considers the problem with properties on the other hand, but this is another facet of the problems associated with properties).

    And, regarding the properties in the interfaces, they are marked as abstract, and look like this:

     public abstract String GetName(); public abstract void SetName(String value);

    These are just bare methods without implementation. They can be neither a state nor a behavior, since only an OBJECT can have a state and a behavior. An instance of an interface and an abstract class cannot be created; therefore, the application of the concept of state and behavior to them is impossible.

    References:

    I. Reference to MSDN (Property Definition).

    Ii. Link to Richter (Property Definition, Chapter 9, p. 204 on the book).

    • In the original, Richter does not propose removing properties from .NET, he simply regrets that they exist: "I’m not really supported by the Microsoft .NET Framework." And besides, properties in C # are added not only for the sake of the fact that they allow to declare two metda beautifully. They are added for the sake of metadata, which are hung on this pair of methods. Compared to languages ​​in which there is no metadata (for example, old Java) - yes, this seems like an unnecessary complication. - PashaPash ♦
    • If you need to add more links - write in the comments, or paste as plain text - someone inserts into the body of the post. - PashaPash ♦
    • @PashaPash thanks for editing. You are right, he regrets that they are, but also in the second part of the sentence he proposes to remove support for the properties (it seems to me identical to deletion). In this chapter on Properties, he explicitly says that he would refuse If I ’ve had properties that I’ve been involved in; Instead, I would have programmers actually implement the GetXxx and SetXxx methods as desired. johnchukwuma.com/training/clr_via_c_4th_edition.pdf 235 pages on the site. - bason

    This is a language / compiler feature that simultaneously generates a class field (which stores the state) and a property as metadata + two methods for accessing this property (behavior).

    UP based on comments from Topicaster:

    C # uses a similar syntax to declare common properties in interfaces and auto-implemented properties in classes. Despite the similar syntax, the result is different.

    In the classes of auto-implemented, properties simultaneously set the state and behavior:

     class SomeClass { // компилятор создаст приватное поле + пару методов для доступа к нему int MyProperty { get; set; } }

    In interfaces, properties are declared without the bodies of getters and setters - because the bodies of these methods are the implementation of behavior, and C # does not support the inclusion of the implementation in the interface:

     interface ISomeInterface { // компилятор не создаст ни полей, ни методов int MyProperty { get; set; } }

    Such a property can be implemented by the class as you please, including in the form of a complete implementation of get and set:

     public class Class1 : ISomeInterface { int _myField; public int MyProperty { get { return _myField; } set { _myField = value; } } }
    • OK, is the property (autowelding) in the interface this state or behavior? Does auto-invisibility generate a hidden field in the interface? - Puh
    • What does the interface have to do with it? Interface object cannot be created. - Igor
    • 2
      @Puh in interfaces is not avtovozhestv. there are just properties that the class that implements the interface is free to implement as you like. - PashaPash ♦
    • @Puh and yes, the interface has neither state nor behavior :) - PashaPash ♦
    • one
      The @Puh example for your link is just a property in the interface. It means that the class implementing this interface should somehow implement this property. Whether it implements it in the form of car ownership, or the usual properties - is unknown. - PashaPash ♦

    Normal syntactic sugar. Same as лямба выражения (анонимные функции) . Same as Expression bodied functions (=>), and async/await , and Tuple . This sweet helps to cut the code very much.

    PS: no one bothers you write:

     private string _name; public string Name { //здесь тоже сахар get=> _name; set=> _name = value; }

    or so:

     private string _name; public string Name { get { return _name; } set { _name = value; } }