What is the advantage of using private variables in C #

Question

Sample code (alternative code below),

// person.cs using System; class Person { private string myName ="N/A"; // Declare a Name property of type string: public string Name { get { return myName; } set { myName = value; } } public override string ToString() { return "Name = " + Name; } public static void Main() { Person person = new Person(); Console.WriteLine("Person details - {0}", person); person.Name = "Joe"; Console.WriteLine("Person details - {0}", person); } } 

Is it impossible to write directly, changing myName from private to public, do not need to declare another public variable Name and do not need to use get and set?

alternative code

  // person.cs using System; class Person { public string myName ="N/A"; public override string ToString() { return "Name = " + myName; } public static void Main() { Person person = new Person(); Console.WriteLine("Person details - {0}", person); person.myName = "Joe"; Console.WriteLine("Person details - {0}", person); } } 

Answer 1

Externally visible properties are better than fields because:

• Properties allow for better encapsulation . Fields are a fixed implementation and provide direct access from consumers. Properties:

  • loosely coupled (since the base field can change from variable to database at any time)

  • enable user logic (validation, event notification, lazy loading, etc.)

  • access control (since logic can be built in get / set, even declared read-only or write-only).

• Fields cannot be used in interfaces . This is an obstacle to testing Driven Development (interface first).

• Automatic or automatically implemented properties are also easily declared as fields, and are also optimized for working with parameters with fields. See here .

• Declaring an external visible field (open, protected, protected internal) is an FxCop Violation . See rule CA1051 .

• Changing a field for a property is a violation of the change because the call code needs to be recompiled (also applies to binary serialization).

• Properties are recognized by many .NET libraries for tasks such as XML serialization, WPF bindings, ASP.NET two-way bindings, etc., as well as the Visual Studio designer.

Answer 2

You hack one of the foundations of OOP -> hiding / encapsulating information

Defining your properties as public, you provide EVERY access to them, and they can be changed (damaged) at will. Thus, you cannot promise that your objects will be constantly in a consistent state.

From Wikipedia

In programming languages, encapsulation is used to indicate one of two related but different concepts, and sometimes a combination [1] [2]:
- a language mechanism to restrict access to some components of an object. [3] [4]
- A language construct that facilitates combining data using methods (or other functions) that work with this data. [5] [6]

Some researchers of the programming language and scientists use the first meaning alone or in combination with the second as a distinctive feature of object-oriented programming, while other programming languages ​​that provide lexical closures consider encapsulation as a property of the language, orthogonal to the orientation of the object.

The second definition is motivated by the fact that in many OOP languages ​​hiding components is not automatic or can be canceled; Thus, information hiding is defined as a separate concept by those who prefer the second definition.

Answer 3

In your example, there is virtually no difference between the two approaches. As a rule, properties give you the opportunity to make them read only for other classes (using a private setter) - you cannot do this with a field. Public fields / property configuration devices violated the OOP encapsulation rule.

Answer 4

In OOP, the convention is to hide all of your variables from users and instead use Getters and Setters to manage them. There are times when you need to change the value of a variable before saving it. For example, you suggest the user to enter some value that will have speed, and users enter the value in MPH, but you want to convert them and save them as Km / h or m / s. Now in this case, the setter makes sense. There are also cases where you want setter or getter to be private to a variable that should be read-only or write-only. But to summarize, the PLO Convention should use setters and getters in place of public variables. This is part of the Encapsulation Concept.

Answer 5

You can do it, but it's not a good pratcie. Encapusal private varaible as a property means that you have more control in limiting what customers can and cannot do

If this seems a bit verbose, you can also use the following

 public string Name { get; set; } 

Answer 6

As bash.d wrote, this is the foundation of OOP.

In this case, I would recommend putting the name in the constructor:

  class Person { public Person(string name) { this.myName = name; } private string myName ="N/A"; public string Name { get { return myName; } private set { myName = value; } } public override string ToString() { return "Name = " + Name; } public static void Main() { Person person = new Person("Joe"); Console.WriteLine("Person details - {0}", person); Console.WriteLine("Person details - {0}", person); } } 

Other ways to use the method to set whether you could check the processed object.