Update Parent Class

[wiebe@CARYA]

It all depends on your specific problem.

You don't always need accessors.

You do need them if the children want to read or write directly to the values, but this can often be avoided.

The values are private to the class. An accessor makes the values public, protected or even community scope.

But let's say the 20 values are set on initialization, and then used by methods. Better then accessors would be to require the child initialization to call the parent method. Let the parent set it's values.

Same for the methods that use the values. The children probably don't need the values, they need the behavior of the parent that has the values. So, children should call the parent method.

Ideally, values in a class should stay in the class.  Any accessor is a violation of the encapsulation. It will be impossible (or very impractical) to never expose parent (or child) values. It's all a balancing act, really.

Another thing to consider is that the 20 patent values are probably related, or groups are related. Maybe these groups should be clusters? If they are, should they be classes?  (Spoiler: yes!)

This realization can completely change the game.

You now have a parent that has an object it can use. With an accessor, the children can use the object too. All methods are 'outsourced' to the object.

For example, let's say the 20 values are filter options. All children have these filter options. You want this filter to be part of the DAQ, transparently applied to this device hierarchy. The filter could (should) be a class of it's own. Now each child in the hierarchy gets the filter.

As a bonus, the filter can have children of it's own. One child can be a compound Child, containing an array of it's parent. The DAQ class doesn't (and shouldn't) need to know anything about this. It all just magically works.

A 2nd bonus is you can reuse the filter.