declaration public - private

[Nicole]

Something I saw that often, but never understood:
What are the reason / advantages to declare something public or private?

[Handoko]

It is considered good programming practice to make the scope of variables as narrow as feasible so that different parts of a program do not accidentally interact with each other by modifying each other's variables. Doing so also prevents action at a distance.

Source: https://en.wikipedia.org/wiki/Variable_%28computer_science%29#Scope_and_extent

If you only write programs that have hundred lines of code, you may not know the difference. But if you have a project of thousand lines of of code, using multiple files, you will know the difference.

I believe you meant public and private declaration in class. Basically they are similar to global/local variable. You can try to write a large project that has thousand lines of code and using only global variables. Do it and you'll know the code is extremely hard to maintain and debug. Same happens on class too. Make the visibility as low as possible, that will prevent you to make silly bugs, the code is more readable, easier to maintain and debug.

[SymbolicFrank]

I tend to only make things private if I really don't want them to be used, like an inherited constructor. Everything else that shouldn't be used directly is protected, and if it is a method, most often virtual. So classes that inherit them can change them if needed.

Most often this is used to add extra functionality.

[marcov]

Make the visibility as low as possible, that will prevent you to make silly bugs, the code is more readable, easier to maintain and debug.

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.

[MarkMLl]

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.

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. In addition, since a one-person team doesn't have the option of coopting a colleague for even a cursory code review, the more he can get the development environment to help the better.

Quite frankly, and speaking with the experience of having done x86 protected-mode bare-metal work, I'd prefer to see more checks rather than fewer. For example, "this is a public function, but should only be called by members of this list of units (or threads etc.)".

MarkMLl

[Handoko]

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.

[MarkMLl]

I believe we all agree there is a huge advantage of avoiding global variables.

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.

MarkMLl

[marcov]

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.

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.

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

[Martin_fr]

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.

[MarkMLl]

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

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.

MarkMLl

[Martin_fr]

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

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

As for "at least as" => should have said "equally as" => since I don't thing that (within the grand average) it will be more useful to an individual than to a team.

I had some rather interesting use cases of my own. One example...
A field, that even within it's class must always and only be set via a dedicated setter procedure (except of course from within that setter)....

Even strict private would not enforce that...

Code: Pascal  [Select][+][-]

1. type
2.   TFoo = class
3.  
4.   strict private type
5.     TPrivMyData = record
6.     strict private
7.        FMyData: TMyData;  // only accessible within TFooBar
8.     private
9.        procedure SetMyData(AData: TMyData);
10.     public
11.        property MyData: TMyDate read FMyData write SetMyData;
12.     end;
13.  
14.   private
15.      FMyData: TPrivMyData;
16.   ....      
17.      property MyData: TMyData read ... write ...
18.  
19.  

[skalogryz]

Something I saw that often, but never understood:
What are the reason / advantages to declare something public or private?

Just declare everything public.
When (and if) the time comes you will encounter the need in private. Until then public only.

[440bx]

What are the reason / advantages to declare something public or private?

You've gotten some good answers (particularly from those who favor the use of private over public in all circumstances.)

By controlling the visibility of a field, you are controlling what code can read and, more importantly write/modify, the field.  If a piece of code cannot even "see" the field then it cannot accidentally or mistakenly change it.

Controlling visibility is the best way of avoiding creating dependencies that should not exist.  For instance, when two pieces of code use a global variable (instead of a parameter) then those two pieces of code are no longer independent of each other because whatever change one makes to the global variable it will affect the behavior of the other.  Public fields, in many ways, create the same problem.  That also makes it more difficult to re-use (copy/paste into another program) either one of the functions (because, among other things, which one is responsible for setting the initial value of that global variable ?)

Generally speaking, Public is something to be avoided whenever possible.  Private is definitely better than Public (less chance of creating the problem mentioned above) and Strict private is the ideal because it minimizes the number of functions/procedures that have access to the field.

In addition to that, I encourage the use of "const" "constref" and "var" (in parameters) as ways of declaring in the procedure/function header what the code can and cannot change.  That prevents mistakes and serves as documentation too.

HTH.

[SymbolicFrank]

Well, if less things in the FPC source would be private but protected instead, I wouldn't be forced to modify the sources and go through a long and frustrating process to get my changes merged. Instead, I could just inherit a new class and fix or add it.

Classes have a bad rep at the moment, because it's easy to break things if you change a base class to do what you want, without taking all the ones into account that inherit from it. And it's even more frustrating if you cannot explain to the programmer who did it why that was very wrong.

Class hierarchies can be very big and complex. That's what they were designed to cope with. If you only look at a small piece and ignore the rest, you will break it. That's why things like anonymous functions are so popular: KISS and easy to understand. Because the scope is small and there are no dependencies.

Big and complex software is big and complex and you shouldn't have junior programmers meddle in it.

So. The important thing is that your source code is readable. Scope is a big part of that.

[Martin_fr]

Something I saw that often, but never understood:
What are the reason / advantages to declare something public or private?

Just declare everything public.
When (and if) the time comes you will encounter the need in private. Until then public only.

Well the first advantage is a rather practical one.

If you use your class from another unit (or in case of "strict private" from any code outside that class), the code-completion will not show (strict) private entries in the list.
If you have a lot of private fields, then that reduces the list and makes it faster to use.

Code: Pascal  [Select][+][-]

1. type
2.   TFoo = class
3.   {strict} private
4.     FChecksum: Integer;
5.     FChecksumNeedsUpdate: Boolean;
6.     FData: TFooDataList;
7.    
8.     function GetChecksum: Integer;
9.   public
10.     procedure Add(ADate: TFooData);
11.     property Checksum: Integer read GetChecksum;
12.   end;

Now lets assume calculating the checksum is rather slow. So when data is added, the code sets the flag instead.
When the checksum is needed, the flag is checked and if needed the checksum is (re-)calculated.

If outside code could read FChecksum, it risks getting the wrong value.

If outside code could write those values, it probably would mess up things.
Even if the code would do it correctly as of today, if you change your class, you  would need to change that outside code too.
=> But with the fields being "  {strict} private" outside code can not access them. => if you change the class, you know for sure that all is well, and that there is no other code to be changed (other code dealing directly with FChecksum).

And that is why you use private sections.