Why can Java attributes be publicly available?

Question

As everyone knows, Java follows the paradigms of object orientation, where data encapsulation says that the fields (attributes) of an object should be hidden to the outside world and accessible only through methods or that methods are the only class interface for the outside world. So, why can you declare a field in Java publicly available, which would be against the data encapsulation paradigm?

Answer 1

I think this is possible, because each rule has its own exception, each best practice can be redefined in certain cases.

For example, I often expose public static finite data items as public (for example, constants). I do not think this is harmful.

I will point out that this situation is also true in languages ​​other than Java: C ++, C #, etc.

Languages ​​do not always have to protect us from ourselves.

In Olya’s example, what harm do I write like this?

public class Point { public final int x; public final int y; public Point(int p, int q) { this.x = p; this.y = q; } } 

It is immutable and stream-safe. Data members may be publicly available, but you cannot harm them.

Also, it is a dirty little secret that "private" is not really private in Java. You can always use reflection to get around it.

So relax. It's not so bad.

Answer 2

For flexibility. It would be a huge pain if I could not write:

 class Point { public int x; public int y; } 

There is a huge advantage to hiding this behind getters and setters.

Answer 3

Since rigid "data encapsulation" is not the only paradigm, as well as an indispensable feature of object orientation.

And, moreover, if you have a data attribute that has a public setter method and a public getter method, and the methods do nothing but actually set / receive the attribute, then what's the point of keeping it secret?

Answer 4

Not all classes follow the encapsulation paradigm (for example, factory classes). For me, this increases flexibility. And, in any case, responsibility for the programmer, and not for the language, depends on the scope.

Answer 5

Discussing the good side of public variables ... I like this ... :)

There are many reasons to use public variables. Let them take turns checking:

Performance

Although this is rare, there will be situations in which it matters. In some cases, the overhead of invoking the method should be avoided.

Constants

We can use public variables for constants that cannot be changed after initialization in the constructor. It also helps. Sometimes these can be static constants, such as a database connection string. For example,

 public static final String ACCEPTABLE_PUBLIC = "Acceptable public variable"; 

Other cases

In some cases, when public does not matter or there is no getter and setter, there is no need. A good example with Point already written as an answer.

Answer 6

Object-oriented design does not require encapsulation. This is best practice in languages ​​like Java, which has much more in common with language design than OO.

It's best to always encapsulate in Java for one simple reason. If you do not encapsulate, you cannot subsequently encapsulate without changing the signature of the object. For example, if your employee has a name and you make it public, this is employee.name. If you later want to encapsulate it, you will get employee.getName () and employee.setName (). this, of course, will break any code using the Employee class. Thus, in Java it is best to encapsulate everything so that you do not have to change the signature of the object.

Some other OO languages ​​(ActionScript3, C #, etc.) support true properties, where adding getter / setter does not affect the signature. In this case, if you have a getter or setter, it replaces the public property with the same signature, so you can easily switch back and forth without breaking the code. In these languages, the practice of encapsulation is no longer needed.

Answer 7

Java is a branch of the C-style syntax languages. These languages ​​supported struct , which were fixed anti-aliases for a block of memory that was usually defined as a "single element". In other words, data structures were implemented using struct s.

When using a structure, the encapsulation goals of object-oriented programming are directly violated, when Java was first released, most people were much more competent in iterative (procedural) programming. By exposing members as public , you can effectively use the Java class in the same way you could use C struct , although the underlying implementations of the two applications were significantly different.

There are several scenarios in which you can do this with proper encapsulation. For example, many data structures consist of nodes of two or more pointers, one indicates "contained" data and one or more indicates "other" connections to the rest of the data structure. In this case, you can create a private class that does not have visibility outside the "data structure" class (for example, an inner class), and since all your code is contained in a single .java file to walk through the structure, you can delete methods .getNext() inner class as a performance optimization.

Answer 8

I believe that data encapsulation is offered as an additional function rather than as a mandatory requirement or rule, so the encoder is given the freedom to use his wisdom to apply functions and customize them according to their needs., Flexible!

A related example might be one of @Oli Charlesworth's assignments

Answer 9

I'm just a beginner, but if a public statement does not exist, the development of java will be very difficult to understand. Because we use public, private and other statements to simplify the understanding of the code, for example, the banks that we use and others have created. I want to say that we do not need to invent, we need to learn and continue.

I hope I apologize for my English, I am trying to improve and hope to write in the future.

Answer 10

Accessibility modifiers are an implementation of the concept of encapsulation in OO languages ​​(I consider this implementation as a way to weaken this concept and provide some flexibility). There are pure OO languages ​​that do not have accessibility modifiers, i.e. Smalltalk. In this language, all state (instance variables) is private, and all methods are publicly available, the only way you must change or query the state of an object is through its instance methods. The lack of accessibility modifiers for methods forces developers to accept certain conventions, for example, methods in a private protocol (protocols are a way to organize methods in a class) should not be used outside the class, but no language construct will force it if you want you to call these methods.

Answer 11

Use publicly or not depending on whether there is an invariant for support. For example, a pure data object does not restrict state transitions in any way, so it makes no sense to encapsulate members using a group of accessories that no longer offer functions that open a data member as public.

If you have both a getter and setter for a specific non-private data member that does not provide more functionality than getting and setting, you might want to re-evaluate your design or make it public.

Answer 12

I really can't come up with a good reason not to use getters and setters outside of laziness. Effective Java, widely regarded as one of the best java books, says it always uses getters and setters. If you don't need to hear about why you should always use getters and setters, skip this paragraph. I do not agree with the example of the answer of the 1st number of the Point as time, so as not to use getters and setters. There are several problems with this. What to do if you need to change the type of number. For example, once, when I was experimenting with graphics, I found that I often change my mind about the weather. I want to save the location in Java form or directly as an int, as it demonstrated. If I had not used getters and setters, and I changed this, I would have to change all the code that used the location. However, if I did not, I could just change the recipient and setter.

Getters and seters are a pain in Java. In Scala, you can create public data elements and then getters and / or setters later without changing the API. It gives you the best of both worlds! Maybe Java will install this for one day.