Re: fields or properties

Actually I fail to see your point. There seem to be a couple things you
might be forgetting.

1) Its impossible to know today what might come up next week or even next
year that causes a design to change. Starting out with public fields allows
decendents of a class to directly access those fields, even if later you
decide that exposing the customer name field was a huge mistake. Having it
use properties up front might take a little extra work on your part, but
your class is much more adaptable to future needs.

2) Your argument that exposing a field allows your class to be much more
powerful seems rediculous. What it seems you are actually doing is making
your class much less capable of changing with future needs that may arrise
because trying to go back and change a public field to a private field might
be an impossible task 2 years later.

If you choose to have public fields in your class designs then that is your
business and perhaps it works for you, however, telling someone that doesn't
understand the ramifications of doing that, that you "Should" do it, seems a
little rediculous. I think that exposing fields like that should be given
extreme care and in the end, I just don't see the advantage. You saved
yourself a very few keystrokes up front, but what have you potentially done
to yourself and those using your components later on?

Sorry if my wording sounds like I'm attacking you as I'm not. Just
expressing my opinion...

just my 2 cents,

glenn


"Michael S" <a@xxx> wrote in message
news:OcDEmyOQFHA.4028@xxxxxxxxxxxxxxxxxxxxxxx
> One of the most long-lived dogma in the OO-purists camp is to never expose
> fields as public.
>
> However, I think there can be benefits in having public fields.
>
> Consider a class Person with a public int property of Age and a public
> string field called Name.
>
> What the class Person tells you is that the Age property is somewhat
> managed, perhaps the property validates that an age isn't a negative
number
> and so forth. The property protects you in some manner.
>
> But the class also tells you that the Name field is not handled at all.
The
> Person class won't mind if you serialize an mp3-file to a hexstring and
use
> that as a name, hence it is your responsebility to check that input is
> meaningful.
>
> By going by the idiom of sporting all fields private and have public
getters
> and setters for all those fields, is extra work and bloats your code. But
> what I think is worse is having Name as a property, which implies that it
> validates input, while in fact it doesn't.
>
> However, in some situations, like building user controls in asp.net; you
> must sport all your fields as properties.
>
> Hope this helps
> - Michael S
>
>


.

Loading