C# Discussion Boards - CodeProject

26-Nov-05 7:04

i learned in school that we should always encapsulate private instances with getters and setters. but in practice, it tends to be an annoyance because i have lots of classes like this, which is much faster to type than the latter.

class Memory {<br />
   object Value1, Value2, Value3;<br />
}<br />

how is that worse than the encapsulated version?

class Memory {<br />
   object value1, value2, value3;<br />
   public object Value1 { get { return value1; } set { value1 = value; } }<br />
   /// etc.<br />
}

all i could find is that the property version is slower because it has to invoke a method (albeit it'll probably never matter)...is there any reason i should encapsulate this, given i will very frequently be assigning new references?

Colin Angus Mackay26-Nov-05 7:23

26-Nov-05 7:23

hypermegachi wrote:
all i could find is that the property version is slower because it has to invoke a method (albeit it'll probably never matter)...is there any reason i should encapsulate this, given i will very frequently be assigning new references?

The encapsulation means that you don't have to re-write lots of code, if at some point in the future you discover that you need to do some extra work in a getter or setter.

Getter example: You might decide later that it would be better to leave the field uninitialised and then have your property initialise it when it is first used. This is called a lazy-lookup. The value can be constructed, but it is an expensive operation to do so, and the usage patterns show that the value is not often needed - so why create it needlessly. So, essentially your property checks the field, if the field is null it creates the value and stores it in the field and returns the new value. If the field already contains a value then that is returned.

Setter example: You discover some time in the future that when you set the property that you need to carry out some other action (an analogy would be like a trigger in the database). So, since you have a property already, you can now put the extra functionality in without having to completely break your application.

Another Setter example: You could throw an exception if a value that was being set is out of range. Thus keeping the object in a consistent state. If you just exposed the field you would never know if some other object set the field to an invalid value and this is a potential source of bugs, especially the nasty sort that rear their head further on past the point that the bug was actually introduced. These are a real pain to track down and anyone having to maintain your code will not thank you for it.

In general, anything outside the class should not need to know anything about the internals of the class. If your class is exposing field members then you are exposing the internals of the class.

Finally, as to the view that using a property will incure the penalty of a method call then you should know that the compiler is smarter than you think. It will often inline properties and small methods for you so there is no penalty at all. If you are using VS2005 you can see this for yourself as there is support for debugging release assemblies and you can see optimisations.

Does this help?

My: Blog | Photos

"Man who stand on hill with mouth open will wait long time for roast duck to drop in." -- Confucious

-- modified at 13:24 Saturday 26th November, 2005

hypermegachi26-Nov-05 12:13

26-Nov-05 12:13

yep, makes perfect sense.

i have no experience looking through the IL code, and probably too lazy to do it. but i'm pretty sure anything other than the simplest of getter/setters, singleton null checks, etc. in properties will not be inlined.

what you speak of is true, in that properties allow for all of that extra work when needed. but if you know with 90% confidence that you won't need to do any checks or extra operations, why not just make them public fields as default?

and then, with the 10% of the time, if you need the extra operations, you can convert the fields into properties, without needing to change libraries that use it, since the syntax would be the exact same.

Colin Angus Mackay26-Nov-05 13:53

26-Nov-05 13:53

hypermegachi wrote:
but if you know with 90% confidence that you won't need to do any checks or extra operations, why not just make them public fields as default?

Two reasons.

1. That last ten percent.

2. Because you screw the encapsulation of the object. You are allowing external entities know about the internals of the object. If at some future date you need to change that, you have a hell of a lot of code to fix that expects the internals of your object to look a certain way. Never ever underestimate the amount of work it will take to fix a problem like that. All it takes is 30 seconds (less if you are using VS2005 because it can automatically encapuslate fields for you if you want) work, that can save days or even weeks worth of work down the line. (If the project is large enough it might event save months of work)

hypermegachi wrote:
with the 10% of the time, if you need the extra operations, you can convert the fields into properties, without needing to change libraries that use it, since the syntax would be the exact same

Not if you follow the guidelines they won't. Properties are always Pascal cased. That means that each word in the property name starts with a capital letter. Fields should be camel cased, which means that the first word is lower cased, each subsequent word is upper cased. So they won't have the same names. Also, some development shops have their own standards like prefixing fields with an underscore, or "m_" (harking back to MFC standards) and so on.

The bottom line is that if you want to be employable you must write code that is easy to understand and maintain. Maintenance costs can skyrocket on a badly written project. Making fields public, innocent as it might sound, is a step that will quickly make a project a maintenance nightmare. I certainly wouldn't want to have to clean up the mess, and neither would you - it is an almost soul destroying part of software development.

My: Blog | Photos

"Man who stand on hill with mouth open will wait long time for roast duck to drop in." -- Confucious

hypermegachi27-Nov-05 6:43

27-Nov-05 6:43

you're making the assumption that i'm accidentically exposing internal things. but i know for sure that i want everything to see...just like the Point struct.

btw, msdn doesn't say anything about fields in general, but it is very specific about the visibility.

private fields have nothing mentioned about them. this allows programmers to use hungarion, _prefix, or whatever they want. protected fields are camel cased (so derived classes don't get all confused with hungarion crap). and public fields are pascal cased to following everything else in the framework.

since i am following the guidelines, all my public fields are pascal cased, so converting to a property won't require you to refactor/rename every project that uses it.

btw, if you turn on xml, the compiler will warn you about all undocumented public fields as well.

Colin Angus Mackay27-Nov-05 13:24

27-Nov-05 13:24

hypermegachi wrote:
just like the Point struct

This is incorrect. It is exposing the private fields x and y through properties called X and Y respectively. Check the IL yourself if you don't believe me.

I'd be very surprised if anything in the .NET Framework exposed its fields publicly.

My: Blog | Photos

"Man who stand on hill with mouth open will wait long time for roast duck to drop in." -- Confucious

hypermegachi27-Nov-05 16:53

27-Nov-05 16:53

sorry, i shoulda been more clear. i meant for my version of the Point struct i woulda been lazy and have public fields. nothing in the .NET framework exposes fields publicly, and so far that seems to be the only reason i can find in using properties over public fields.

Colin Angus Mackay27-Nov-05 20:26

27-Nov-05 20:26

hypermegachi wrote:
i meant for my version of the Point struct i woulda been lazy and have public fields. nothing in the .NET framework exposes fields publicly, and so far that seems to be the only reason i can find in using properties over public fields.

No, there are lots of reasons for using properties over public fields. You just need to (re)read the replies I gave above to find some of them.

My: Blog | Photos

A stitch in time saves nine

hypermegachi28-Nov-05 3:58