What happens in real life in a developer environment if the programmer does not encapsulate an attribute?

Asked

Viewed 302 times

5

The programmer João went there and created a class Cliente and the attribute public double saldo and the method Sacar() public also.

What’s wrong with leaving the attribute double saldo, after all what the problem could occur if John does not deprive the balance attribute?

I can only imagine that someone could pick some random client and increase a person’s balance and you?

class Cliente 
{    
    public decimal saldo;
    public void Sacar()
    {

    }
}
  • If "someone" is another application class, that’s right.

  • Already have an answer on the site about encapsulations! I just could not find

  • https://answall.com/questions/15467/m%C3%A9todos-e-propriedades-em-c-vantagens-e-desvantagens @bfavaretto ou essa, imagine you already have some !!! ;)

  • 1

    Did the answer solve your question? Do you think you can accept it? See [tour] if you don’t know how you do it. This would help a lot to indicate that the solution was useful for you. You can also vote on any question or answer you find useful on the entire site (when you have 15 points).

1 answer

6


There’s an earthquake in Canada :)

If it’s necessary and you know what you’re doing, it’s okay. Of course, this example can be a problem because a balance should not be manipulated directly. I don’t even know if a client should have a balance and a method Sacar(). I know it may be just an example, but it induces something wrong.

But don’t think it gives any security. If a programmer wants to change a value he will change. Encapsulation only protects the well-meaning programmer who does not want to risk making a mistake by accessing the field directly. It is something that the compiler "prevents" access, but from then on anything can happen.

It’s more a matter of code organization, something that helps manage the complexity of objects and pass the right intention. It has to do with encapsulation.

In this way it helps achieve cohesion and avoid coupling unintentional.

Actually there’s a worse problem in this code that is storing monetary value in a double.

I’m not a fan of the term attribute for this, I prefer field.

See more:

  • In the case of a team of developers working on the same project Private is to ensure that no other developer tampers with its code so the use of Private understood right ?

  • It is not exactly the opposite of this, it is so that another part of the code cannot access this attribute directly. Nothing else. The programmer does what he wants in the code. Even those who are not the programmer of the application do what they want if they have access to the executable. As I said in the reply is not a security mechanism, it’s just organization.

  • I understood, thanks to your explanation I was able to understand that encapsulation goes hand in hand with the Principle of Sole Responsibility.

  • @user3671786 no, this does not happen, at least not directly.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.