Forum > Beginners

declaration public - private

<< < (2/4) > >>

I believe we all agree there is a huge advantage of avoiding global variables. Thing is similar for public/private visibility in class, but the advantages are much less compare to global/local variable.

I can understand SymbolicFrank's reason that inherited class can change them. There were times, when I wrote an inherited class that needs to modify a private field of its ancestor class. I had to move it to the less narrow visibility section. I might thought maybe I should make all fields public, that should save my time in the future for moving them to a higher visibility section.

But I thought more deeply. The problem was not caused by not making them public. But because I hadn't properly plan the class before I wrote them.

For the codes I wrote for others, I usually use only public and private members. But for the codes I maintain personally, I will try to put them at the lowest visibility section if possible, strict private. By doing so, I force me to think and plan carefully before I write the code, should I put it in strict private, protected or public section? I make it a habit, to plan it before writing it.

Novices write codes without planning it. I prefer and force myself planning before writing it, the professional way.

Also, not making all fields/methods public means self-documenting. So, if I inherit the class in the future, I only need to check the public or protected section, which has less members because I already moved them to the lower visibility sections. Each section has different meaning to me, this serves as self-documentation for me in the future.

But, I think how much one can benefit from putting class members at the as lowest visibility as possible depends on the programmer's convenience. Same program can be written using different ways, just pick the way you feel most convenient.


--- Quote from: Handoko on July 26, 2022, 06:49:32 pm ---I believe we all agree there is a huge advantage of avoiding global variables.

--- End quote ---

I believe that we don't all agree that.

If we did, then Lazarus forms would be presented as read-only unit properties, rather than as global variables.



--- Quote from: MarkMLl on July 26, 2022, 05:28:51 pm ---
--- Quote from: marcov on July 26, 2022, 03:55:31 pm ---I think it is less (though not zero) useful for one programmer projects, and more that it conveys a certain intentions for code written by teams.

--- End quote ---

I'm afraid I disagree. Even a single-programmer project can benefit from being forced to explore /why/ something needs to be made public, and from being forced to check whether it was originally private due to e.g. the possibility of a race condition.

--- End quote ---

So what do you don't understand about "not zero" ?   ;)

Well, imho (and of course that is included by none zero), the use in a "one man project" can - and should - and probably with increasing experience of that one man also will be - as big as for a team project.

The use in a team project is usually to document (or as you said "communicate") a chosen design decision (and protecting it against accidentally being broken).
If source is not distributed, then it has the additional use of enforcing what is allowed. But if source is not avail, then it could be a one man project as well as a team project. One person does not become a team by using 3rd party addons. (Nor by supplying such as add on).

But such design decisions are equally valuable to an individual as to a team. With the exception that a team is unlikely to write a software with less than (maybe) 50 lines, where an argument can be made that design is not that important (a decision that can hurt a lot, if that project keeps growing).

So imho the individual benefits as much as the team.


--- Quote from: marcov on July 26, 2022, 08:34:18 pm ---So what do you don't understand about "not zero" ?   ;)

--- End quote ---

Martin puts it well: it's at least as useful for a single-person team as for a larger one.

There are things that can benefit larger teams: the definition part of a unit being read-only to junior members, unsafe language features only being available to senior members and so on.



[0] Message Index

[#] Next page

[*] Previous page

Go to full version