I used to wonder about public fields vs. properties.
But it doesn't seem like much of an issue now that you can just write it as
a one liner
string Name { get; set; }
(or by typing *prop* and hitting tab twice)
Since that new auto backed properties are so easy, I just use them as my
default because you can then easily change the functionality at a later
stage (like adding logging, property changed events, etc).
-David Burela
On 25 August 2010 13:09, mike smith <meski...@gmail.com> wrote:
> About the only time fields might be preferable is where you want to read a
> file (a bitmap, say) and then cast it to a class. A lot of the lower-level
> classes in MFC did that. CRect, CPoint, etc.
>
> On 25 August 2010 12:07, Mark Ryall <mark.ry...@gmail.com> wrote:
>
>> If you create some library that expose anemic DTO classes that have public
>> and mutable fields and no behaviour then you'll have great difficulty ever
>> taking that away. That applies even if you're the only consumer.
>>
>> There are certainly some occasions where this is justifiable (for
>> serialising objects or transfer or persistance or whatever - ORMs usually
>> require these unfortunate sort of classes) but seems to mostly defeat the
>> purpose of OO.
>>
>> I prefer languages (like ruby or smalltalk for instance) that don't give
>> you the option of exposing the internal state of classes (without some
>> degree of violence) unless you create methods (which is all properties
>> really are).
>>
>> That's not because i'm a purist - there are just fewer things to worry
>> about when your classes are mostly immutable except via behaviours you
>> choose to add to them.
>>
>> On Wed, Aug 25, 2010 at 11:54 AM, Jeff Sinclair <
>> jeff.sinclair.em...@gmail.com> wrote:
>>
>>> True, with properties, changes can be completed maintaining binary
>>> compatibility.
>>> But really how often do you have an assembly where binary compatibility
>>> is
>>> actually an issue?
>>> Sometime sure, but I'm thinking it's more often the exception than the
>>> rule.
>>>
>>> Adding properties in later maintains source compatibility, and generally
>>> I've found that's more than enough.
>>>
>>> Jeff
>>>
>>> -----Original Message-----
>>> From: ozdotnet-boun...@ozdotnet.com [mailto:
>>> ozdotnet-boun...@ozdotnet.com]
>>> On Behalf Of Mark Hurd
>>> Sent: Wednesday, 25 August 2010 9:28 AM
>>> To: ozDotNet
>>> Subject: Re: Properties
>>>
>>> The thing with properties is that once you have them, changes can be
>>> completed without changing the interface, including the binary
>>> compatibility
>>> of public interfaces.
>>>
>>> Nevertheless, if your class of variables is not public I too would
>>> consider
>>> just using fields.
>>> --
>>> Regards,
>>> Mark Hurd, B.Sc.(Ma.)(Hons.)
>>>
>>> On Wed, Aug 25, 2010 at 10:43 AM, Jeff Sinclair
>>> <jeff.sinclair.em...@gmail.com> wrote:
>>> > Can some one tell me why people get so worked up about all fields
>>> > being private and accessed only via properties.
>>> >
>>> > If you have a class which is only used essentially as group of
>>> > variables, eg to put into a data structure like a tree or something
>>> > then why not public fields?
>>> >
>>> > Do all those properties really add any value?
>>> >
>>> > Jeff
>>>
>>>
>>
>
>
> --
> Meski
>
> "Going to Starbucks for coffee is like going to prison for sex. Sure,
> you'll get it, but it's going to be rough" - Adam Hills
>
