I should have been more specific in my statement sorry..
In most cases that I have worked with, the set/get features have been left for people who use a object. For subclassing, Allow direct access to the classes key member vars. It made code "prettier"
Given the way you currently designed it.. a sub-class does have access via property members. so technically no change is needed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I thought of it a bit longer and decided against your suggestion.
The reason is simple: making a variable protected makes it part of the contract of the class. This restricts the possibilities for changing the internal structure of the class afterwards. By using accessor methods (or properties in .NET) this restriction is avoided.
I agree that sometimes it can be necessary to make internal variables protected, especially if there is no property for accessing it. If you name such a special case, I will look after it.
Regards,
Olaf
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I just started playing with this layout tool and one observation is that many internal variables are private.
It would be nice to make them protected to support inheritance of controls nicer to do..
- Jason
Hi Jason,
most of the internal variables are made public as properties, so can be used in inherited classes.
Do you have an example, where informationen needed in an inherited class can't be accessed?
Olaf
I should have been more specific in my statement sorry..
In most cases that I have worked with, the set/get features have been left for people who use a object. For subclassing, Allow direct access to the classes key member vars. It made code "prettier"
Given the way you currently designed it.. a sub-class does have access via property members. so technically no change is needed.
Hi Jason,
I thought of it a bit longer and decided against your suggestion.
The reason is simple: making a variable protected makes it part of the contract of the class. This restricts the possibilities for changing the internal structure of the class afterwards. By using accessor methods (or properties in .NET) this restriction is avoided.
I agree that sometimes it can be necessary to make internal variables protected, especially if there is no property for accessing it. If you name such a special case, I will look after it.
Regards,
Olaf