Access Modifiers in Object Oriented Programming

I do not understand access modifiers in OOP. Why do we do, for example, Java instance variables private, and then use the public getter and setter methods to access them? I mean, what is this reasoning / logic?

You still get the instance variable, but why use the setter and getter methods when you can just post your variables?

please excuse my ignorance as i'm just trying to understand why?

Thanks in advance.; -)

+7
java c ++ computer-science oop programming-languages
source share
9 answers

This is called data or information hiding .

Basically, you don’t want the user (read: another programmer or himself) to break into the interior of his class, because it is very difficult to change.

On the other hand, the pure separation between interface and implementation (theoretically) makes it easy to change something internally without affecting users of your class.

For example, suppose I have a Button control with a public String text field. Now everyone is starting to use my Button , but I understand that every time the text is changed, the button must be repainted on the screen. I was unlucky because my object cannot determine when text is assigned. If I made it private and provided setText() instead, I could just add a redraw call to this setter method.

As another example, suppose I have some class that opens a file in its constructor and assigns it a public FileStream file . The constructor throws an exception if the file cannot be opened. Therefore, other methods in the class may assume that this field is always true. However, if someone walks in my class and sets file to null , all methods in my class will suddenly crash.

+11
source share

A very important point that is often overlooked: you do not need to provide a getter and setter for each field! In fact, most fields should not have any, not just getters (which makes them read-only).

Having classes that consist of nothing but private properties and public getters and setters is just as bad as using public fields. This is an anti-pattern called anemic domain model . The fact is that getters and setters allow you to add behavior and logic to the model beyond the scope of simple data storage - and in many cases this means that you do not have a getter or setter (or both).

+6
source share

The difference is that with getters and seters you control access to instance fields. You can provide security copies, constant views, or even field conversions of your instance. You have hidden your real implementation details from others. This is a good thing!

The more you hide, making your interface friendly and helpful, the better. Others should not know how everything works (because they may be tempted to do what they should not do); they just need to know that everything works somehow.

+1
source share

Another point is encapsulation - if you decide to change the way this variable is processed, for example. to always return / store a copy, you can do it in one place (getter / setter) without breaking anything.

+1
source share

If your class is immutable, there is nothing wrong with exposing variables as public variables. (everyone will be public finals) and there is no rule that getter should always return a variable as is. or setter should set the variable as is .. You can wrap around three rules / modifiers, etc. Around your access to a private variable (data encapsulation)

+1
source share

First, not all data members must have getters and setters, and I suppose you can see the dignity of storing these variables.

Secondly, most classes are larger than random data collections. They represent things that you should be able to reason on your own. Typically, this means that they have certain properties that the developer can depend on (often called "class invariants"). For example, the Rectangle class must have the property that drawing lines between corners gives lines at right angles to each other. If the points are open data elements, then any random application can change the point, and then you will have a rectangle that was not a rectangle. If you have a setter function, you can handle it correctly.

Third, consider the service. At some point, you may need to change the implementation of the class, and you may wonder how many things you will have to change. If the data members are publicly available, changing any implementation detail may violate any of the programs that use this class. You are stuck. If there are receivers and setters, you can compensate for this, so setting the value can do something more or less complicated in the internal details to get the same effect as before. If you have more abstract member functions, you will have very few problems making changes.

+1
source share

You make class class variables private to control how other code that you cannot control can access and manipulate them.

If you just write code for toys, it can be difficult to understand the point, but when you write code that other people will use and depend on you, you will understand.

As a simple example, we note that it is important that a member variable of a class is never equal to zero - let's say it breaks your class. If you make the field public, any other code can set this variable to null, you can do nothing.

If you make it private and propose the setter method instead, you can protect the member from null, whether you can control whether you have thrown an exception or thrown an exception, or simply ignore the attempt.

0
source share

This is the main advantage of using OOP, polymorphism, inheritance, and encapsulation.

Encapsulation allows you to hide the implementation or data on your object using a private access modifier.

On the other hand, you want to mutate the data, thus creating the setter method. Hope this helps.

0
source share

You are talking about the basics of OOP. This topic is worth reading a good book. Various blogs and forums (one of which is SO) are not a suitable place for gaining fundamental knowledge.

If you really want to deeply understand the basics that are necessary for a good developer, then read related books. "Code Complete" or "Object Oriented Analysis" deserves to be read.

0
source share

All Articles