“private” versus “ public”: what's the advantage?

Should the default mode for objects, methods, properties, variables be “private” or “public”?
In other words, if I let all objects, methods, properties as “public” does this impose a higher demand of RAM/CPU for the built application? And which would be the advantage of being “private” versus “ public”?
I understand the differences in there use when “private” or “public”, but I don’t fully understand the advantage …
Thanks !

You are talking about the Scope of the Objects, Methods, Properties…

This helps to encapsulate and protect the internal implementation details of the class, promoting better code organization and reducing the risk of unintended modifications or dependencies. On the other hand, a public access modifier allows unrestricted access to the member or variable from any part of the object, which can be useful for sharing data or functionality across different classes or modules.

1 Like

I typically start with Private for everything and adjust only if absolutely required.

For controls on a layout, I always use Private and then write specific methods for changing their values because later, if I need to debug what’s changing its value, I can set a breakpoint.

Public, Protected and Private have specific meanings when dealing with top-level classes and their contents as do Global, Public and Private for classes within modules. The use of which will be dependent on the needs of your app.

3 Likes

Not really.

2 Likes

It does however put a higher demand on your brain for debugging when things are getting changed that shouldn’t. :stuck_out_tongue:

9 Likes

The advantage is design simplicity. Starting with private can prevent you from inadvertently designing things that become highly dependent on one another. You may need to switch some things to protected or public later, but it ought to at least let you consider whether that is the best approach for your overall design.

OOP Design Concepts

4 Likes

Keep things private until you need to set it as public is a good practice

Protected is more confusing for me… I never find when to use it

3 Likes

Protected is for subclassing. When you have a method in a parent class that should only be accessible from within a subclass but not to the outside world.

For instance, let’s say you have a base class called Pet which has a Name property and two subclasses named Cat, Dog, Turtle, Rabbit and Parrot. Now you don’t want anyone to create a Pet, but you don’t want to have to add the functionality to each of the specific subclasses. You could add a Protected Constructor(name as string). That would prevent you from being able to do something like:

Dim p as New Pet("Harry")

Now lets say that the Dog subclass has a constructor like this:

Public Sub Constructor(name as string, type as string)
    Super.Constructor(name)
    self.type = type
End Sub

Super.Constructor can be called within the subclasses to run the code in the super:

Dim d as new Dog("Harry") // Can't do this
Dim d2 as New Dog("Harry", "German Shepherd") // This does work
1 Like

Private vs Public is a compile-time consideration. It makes no difference in the built app.

4 Likes

Well…

It does if you’re using Introspection.

2 Likes