Is there a good reason to use public property / field?

Question

One of the important parts of object-oriented programming is encapsulation, but publicly accessible properties / fields tend to break this encapsulation. Under what circumstances does public ownership or the field really make sense?

Note. I use only the term “property” or “field” because the terminology varies between languages. In general, I mean a variable that belongs to an object, which can be accessed and set outside the object.

Answer 1

Yes, sometimes there are good reasons. It is usually advisable to hide information. But there are some random exceptions.

For example, public fields are reasonable and useful for:

• C ++ pimpl is a structure / class containing a private implementation of another class. Its fields can be declared publicly syntactically, but are usually available in only one source file by a class containing pimpl.
• Permanent fields. For example, Joshua Bloch writes in Effective Java: "Classes are allowed to expose constants through public static final fields."
• Structures used for communication between C and C ++.
• Types that represent only data whose presentation is unlikely to change. For example, javax.vecmath.Point3d, which represents the coordinate {x, y, z}.

Answer 2

Short answer: never.

In fact, if you use an object to simply store data, but the object itself does not do any logic, and you never want to receive from this object, then it is normal for public fields. Sometimes I do similar things in C ++:

struct A { int a; float b; string c; A():a(0),b(0.0) {} A(int a_, float b_, string c_):a(a_),b(b_),c(c_) {} }; 

But besides initializing the constructors, it is nothing but a C-structure. If your class does something more than this, you should never use public (or even protected) fields.

As for the properties, it depends on what language you use. For example, in Delphi, the main purpose of properties is to provide public interfaces for fields and can provide them with getters / seters, while still working syntactically as a variable.

Answer 3

Is there a good reason to use a public property / field?

Not.

Public members are always dangerous. Now, you may not need any control, but as soon as you expose them, you will lose any control opportunity later. If you have gettes / seters right away, you have the option to add control later.

<sub> Ps: Depending on the language you use, properties and fields can mean different things. C # properties are actually a way to both encapsulate, and at the same time not very verbose. Sub>

Answer 4

There is a bad reason: by directly accessing the data, you avoid pushing the method call onto the stack, for what it's worth.

In many languages, this is also achieved by embedding the / s access method.

Answer 5

If the object's goal is to store data in its fields, then yes. It would also be advisable to have methods for the object that (a) are purely functional (in the sense that they do not change the state of the object or something else); or (b) that manipulate the state of the object, and the fact is that they manipulate the state in a certain way.

What you should avoid is (c) methods that do things to other objects based on the state of the object (and, of course, if there is speculation about what is a “true” state).