I have read from literature that a variable shouldn’t be declared protected just so it could remain visible in the inheritance tree.
Why is so?
I have read from literature that a variable shouldn’t be declared protected just so
Share
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
I have read from literature that a variable shouldn’t be declared protected just so it could remain visible in the inheritance tree.
Why is so?
Fields are implementation details – they should not generally be regarded as part of the API – that way you get to change exactly how things are stored later on. If you make a field protected, it will be available to subclasses, rather than the subclass only getting to see an API which they can rely on.
What if you want to restrict which values are valid on that field at a later date? When it’s protected, you don’t get any validation or anything similar. Subclasses could put any old rubbish in there. If you keep it private and give a protected setter method, you can apply appropriate validation.
In short: regard your clients-through-subclassing as clients in much the same way as your clients-through-calling. Give them an API to work with, and keep your implementation details private.