Kernel Development - Private or Protected in Header File?

[ghost]

Hello, I'm developing the FlowConvection I've shared in some previous discussion posts to be AD. Currently, I'm looking at the header file and I see that there are two sections: protected and private with some variables, parameters, etc thrown under each. How does one decided where to put things?

I've looked through some of the kernels currently on Zapdos and I see a mixed bag. I've seen Real _r_units in protected and in private for example, and I've seen kernels without a private section at all. I looked through the GEC 2018 workshop slides but I didn't see anything that made it clear.

Any help would be greatly appreciated! I've finally set up a Zapdos fork, and I can enter the work-in-progress .h and .C files there if someone would like to view them.

[cticenhour]

Within a given object, Private vs Protected doesn't really matter and is up to the developer - this is why you see the mixed usage in Zapdos. These are important, though, when it comes to objects that inherit from FlowConvection in the future. Private means that those variables or methods cannot be accessed outside of the class in any circumstance. Protected means that variables or methods can be accessed by classes that inherit from the class, but cannot be accessed by other classes.

[ghost]

Under this thinking, when would it be useful to make something inaccessible ie under private? It sounds like having everything under protected would make things easier later in further development.

[cticenhour]

Let's say you have a physical constant, or a boolean variable used as a trigger to change object behavior - in short, something that really only makes sense in the context of the object itself. Alternatively, let's say you have a function/method that makes a modification to some other variable (perhaps even in another class itself) that you only want one object to have access to, otherwise you might have less control over how that method is used.

I tend to agree with you regarding protected....it's often easier later and doesn't require a modification. But then again, moving from private to protected is often a one line change for a developer to make when it's actually needed.

[ghost]

Okay, I think that makes sense. Thank you!

[cticenhour]

No problem! One more thing to add since I think it's useful context. Outside of Zapdos, in general C++ land, you could even think of these as a security feature. You might not want just any user to have access to all code features in all contexts. Some developers consider it good practice to keep everything as private as you can. This access control idea is covered in more detail if you search for the idea of "Encapsulation" in C++. A good article about that is here: https://www.w3schools.com/cpp/cpp_encapsulation.asp