Home / Questions / 279810
Accepted
Aritzbn
Asked: 2020-07-18 23:55:27 +0800 CST 2020-07-18 23:55:27 +0800 CST

Is OOP used correctly in C# according to its conventions?

  • 772

I have raised this issue a few times on the site chat but I feel there is a lot of diversity of opinion and it seemed appropriate to post a question on the site.

Starting from the base of the four pillars of OOP

  • Abstraction
  • encapsulation
  • Inheritance
  • Polymorphism

I believe that what is called OOP in C# does not have attribute encapsulation.

Encapsulating an attribute, from what I've studied, means leaving the attributes in question as private.

This leads me to think that something that is not is usually called object-oriented programming.

From what I've always seen, to define a class attribute in c# is done as

public int number { get; set; };

By doing this you are ignoring one of the fundamental pillars of OOP, which is variable encapsulation.

Wouldn't it be more correct to call it property-oriented programming, or something like that? Since the attributes are not privatized and they are accessible from any class, even if they are modifiable or not.

c#

2 Answers

  1. Best Answer

    Encapsulating an attribute, from what I've studied, means leaving the attributes in question as private.

    No, encapsulation means having control over how an object looks to the user of the object. This is achieved by separating data that " needs to be known " externally from data that "needs to be hidden ". Wikipedia explains it pretty well (emphasis mine):

    In modular programming, and more specifically in object-oriented programming, encapsulation is the hiding of the state , that is, of the member data of an object so that it can only be changed by the operations defined for that object .

    Each object is isolated from the outside, it is a natural module, and the entire application is reduced to an aggregate or puzzle of objects. Isolation protects an object's associated data from being modified by anyone who has no right to access it , eliminating side effects and interactions.

    In this way the user of the class can ignore the implementation of the methods and properties to concentrate only on how to use them . On the other hand, it prevents the user from changing their status in unforeseen and uncontrolled ways.

    Therefore, posting internal data of an object does not break the encapsulation, what breaks the encapsulation is doing it uncontrollably or posting internal data that the user does not need to know.

    It may be easier to understand with an analogy :

    Imagine a car: the body hides the internal elements such as the engine, the battery, the gearbox, the axles, etc...

    Hmm...wonder what will happen if I lick the trowel joint.

    You don't need to know that those items are there to use the car (you don't even need to see them) all you need to know is where the pedals, gear lever and ignition are.

    In fact, it is likely that you or anyone who uses the car will be tempted to tamper with the elements that are accessible to you, with the possibility of misusing them, the more things that can be tampered with, the more likely they are to be tampered with incorrectly.

    • 10

  2. I think there is some kind of confusion in this.

    It is possible that you have seen C# code generated in Visual Studio where public int number { get; set; }; it is autogenerated by using the prop + TAB snippet that generates the code that you have put in getpublic and setprivate

    If you use the propfull + TAB snippet TAB generates this.

    private int mivariable;

public int miProp
{
    get { return mivariable;}
    set { mivariable= value;}
}

    So I think that you have simply seen autogenerated code and that normally it is still used private int miVariable. I don't know if this is what you were asking. All the best

    EDIT:

    Using this wrapper at the end public int number { get; set; };Visual Studio internally creates a private int number

    • 3