Public and private

This is a question discussed in the "Beijing design patterns Learning Group". Can attribute fields of classes be directly disclosed? The problem arises from the discussion of the singleton mode. The article is fluent and necessary to understand it.

[Note: due to concerns about privacy, the nickname and QQ number of speakers are not disclosed here. I have not asked the speakers whether to agree to the request for reference. If you think there is something wrong with the post, please leave a comment. I will contact you in time and handle it accordingly. Thank you !]

Y: It is very painful to roll back a non-singleton concept into a singleton design. In turn, it is better to deal with it. A singleton is indeed a global variable and a well-named global variable.

HW: Generally, I directly use static fields.

Y: It is extremely bad to expose fields directly. This does not need to be explained for any reason.

W: There is no difference between getter writing and setter writing and direct exposure. The same is true for exposing fields and using reflection.

Y: the simple data structure you are talking about. The class that does not contain the behavior is an exception.

W: therefore, whether the field is exposed depends not on security, but on readability.

Y: the code is not used for destruction, but for maintenance.

W: I mean this to illustrate whether the members of a class are made public depends on readability rather than security. For example, I prefer to make public a person. Age and person. getage ().

Y: person. Age and person. getage (). If you think the former is more readable than the latter, I have no objection.

E5max:

Yes!

I suppose you mean that if a class has no other methods except setter and getter, it is better to expose the member variables directly.

W: That means
Y: person. Age and person. getage () are more maintainable than the former. If your person has a birthday attribute, you may redesign the age in the future. With the former, you don't have to design it.

W: You can refer to playframework.org's open-source project Orm, which has long abandoned hibernate's getter/setter but used all attribute variables.

Y:

Do not expose fields. Try...

HW: do not expose methods or attributes in the class.

W: code readability greatly improves the age method by removing the age field and changing it to age () after adding a birthday.
HW: You can create a struct or static tool class.

W: instead of get
E5max: There is an example in "C ++ meditation" to show when members can be made public. This is the author's idea of C ++ pragmatism!

HW:

Sometimes the mode changes to the reverse mode.
Reconstruction to solve Design Problems
Use static variables first
Incorrect attribute

Then you can refactor it later.
Avoid excessive design to the maximum extent

......

Y:

Is there such an example? Can you give me a brief introduction? I forgot. It's been too long.

E5max:

@ Huaihua- er-C

The C ++ meditation book does have many Sample Code defining the member attribute as public.
This issue is also specifically mentioned in the book. Of course it is not specifically discussed. Let me look for it and see if I can send it.

E5max:

That's right! But it does not mean no! Some exceptions are acceptable and necessary.

The following is an electronic version of "C ++ meditation:

Y: That's good. My opinion is that after you confirm what you want to do, you just need to do it. You don't have to be subject to any other constraints, provided that you do.

E5max: Yes! We know that the benefits of doing so are greater than the benefits, and at least will not bring any damage!

Therefore, we can draw the following conclusions:

I,Do not expose attribute fields of the class directly.This is extremely bad and does not even need to be explained for reasons.

2. Try your best, but it does not mean you never want!

In which cases can attribute fields of the class be directly exposed?

1) A simple data structure that does not contain behavior classes. For example, there are no other methods except setter and getter. In this case, it is acceptable to directly expose attribute fields of the class.

2) The nested type of C ++ class. For the nested type of the class, we allow direct exposure of its attribute fields without affecting readability, because its customers only have classes, there is no access security.

[Pimpl idioms: pimpl idioms place private data and functions into a separate type defined in the implementation file, in the header file, the type is pre-declared and a pointer pointing to the type is saved to hide the relevant details. Class constructor is assigned the pimpl type, while the destructor releases it. This eliminates the relevance between implementation details and header files .]

3) Is there a third case? I think so.

In short, as the British colleagues said, If you are very clear about what you want to do, do it without being subject to other constraints, on the premise that you are indeed clear. We need to be clear that the benefits of doing so are greater than the benefits, at least without causing any damage!