DoNotDeclareVisibleInstanceFields
Hello,
I'm using FxCop 1.35 and I have a question to the above-named rule:
FxCop suggests using a private or internal declaration for a member variable and providing a public or protected property to access ist value from the outside world.
I don't understand why internal is more encouraged as protected because in my understanding internal is "weaker" because it it accessable from the whole assembly whereas protected is only accessable by the same class or derived types. Or do I miss something here?
[513 byte] By [
Zoidberg] at [2007-12-20]
Maybe the message should only occur when a member varaible is really public.
In an environment, where a piece of software is created by a team of developers where every member has access to the source code and hence could derive types into a new assembly or in the original assembly, i still would prefer protected because somebody might alter internal values of a class unintentionally when access to internals is possible from within the whole assembly.
I understand your point, but the guidelines have to regard protected items as public. They are consumable by 3rd-parties, and, as such, need to conform to certain standards in order to maximize usability, etc.
FxCop takes the stance that fields are implementation details of a class. It's good object-oriented design to abstract implementation detail from external classes to decouple them from one another as much as possible. Relying on implementation details of another class also reduces the cohesiveness of a class. Protected fields don't follow this axiom and tightly couple the two classes in question.
Ideally fields should only be private; but sometimes this is not possible for non-technical reasons. Internal at least allows you to open up access to the fields only to classes within your control.
An externally visible field is "publishing" an interface that cannot change one published. If you need to change how your class implements that field, you're stuck. FxCop is trying to help you avoid getting stuck.
Last time this was talked about, the AccessedThroughPropertyAttribute was mentioned. This allows you to have the control be private and have a protected property that still allows the controls to be modified in the derived form in the Visual Studio IDE. The attribute is in System.Runtime.CompilerServices so I always have trouble remembering where it's at.
