Re: fields or properties

glenn,

While I agree with you, and I never use public fields myself, do recall
that your advice applies only for programmers who are releasing DLLs to
the public, and so are bound by the contract that they create at the
outset.

If you release DLLs outside your organization (or work group), it _is_
difficult to change a public field to a public property, because it
requires that all client code be recompiled.

However, if you are doing in-house development and all code is under
control of your IS department, then it is _dead easy_ to change a
public field into a property later if the design requires it. All you
have to do is recompile all client code, which is a minor annoyance at
worst.

I'm not advocating using public fields... I don't, as a matter of O-O
purity, as Jon Skeet pointed out.. I just wanted to point out that for
some of us it's not as bad as you make it out to be. It really depends
upon what kind of development you're doing and who is going to be
calling your DLLs.

.

Relevant Pages

  • Re: fields or properties
    ... If you release DLLs outside your organization, ... requires that all client code be recompiled. ... if you are doing in-house development and all code is under ... public field into a property later if the design requires it. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: fields or properties
    ... > that your advice applies only for programmers who are releasing DLLs to ... > requires that all client code be recompiled. ... > public field into a property later if the design requires it. ... reply to glenn. ...
    (microsoft.public.dotnet.languages.csharp)
Loading