The google cache is slowly being replaced by the contents of a parking page that has replaced the original site. So, this archive of my old posts is going to get a little sporadic.
The wayback machine does have some record of pages from 2004 to January 2006 so hopefully it will only be a few months of missing information.
A recent question came up on forum about encapsulation. I guess it is something that I don’t really think about any more as it comes naturally but it reminded me of how some of these concepts took a while to take hold when I was first taught them in university.
Encapsulation is sometimes also known as information hiding. The idea is that an object hides the details of how it works from the outside world. However, some definitions of encapsulation suggest that it is just putting the data and the methods that operate on that data together in one class (the capsule).
The question asked was why make fields in a class private, why not just make them public?
I now find very idea of making a field public incredulous. However, if I stretch my mind back about 10+ years or so I can vaguely remember asking similar questions and thinking how crazy it was making member variables private and having to access them through special functions. It isn’t crazy at all.
So, what do you get from hiding fields behind the private or protected accessor?
The primary advantage is that it hides the internals of the class and shifts the dependency onto a well defined interface. By interface I mean a public method or property on the class rather than having the class inherit from an interface. Code that accesses the class will call on the public methods and properties and need know nothing about what is happening inside the class. This leaves great scope for future implementations of the class to vary what happens internally while maintaining the same external interface. Code that uses the class will then continue to operate without being modified. Put simply – It is a form of protection from future unknowns.
For example, say that a class represents an alarm clock which allows two separate alarms to be set. Internally, those alarms are represented as two separate fields. When the client code accesses the alarm clock class it uses a set of public methods and properties. This allows at at some point in the future the internal storage of the alarm times to be changed to use an array rather than two separate field instances. If the fields were public a lot of code outside the class may have to be updated also to accommodate the new structure of the class.
Even if there is not going to be any internal change to the class, the use of methods and properties to access the fields can provide other advantages.
For 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. If the field value can be constructed from the information the class already holds, but it is an expensive operation to do so, and the usage patterns show that the value is not often needed then why create it needlessly? So, the 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 it is the cached value that is returned.
Alternatively, 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 example being that validation could be taken before the field is updated with the new value. This keeps 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 allowing that into the system.
An interesting advantage to using public properties backing private fields is that the developer can set breakpoints on the properties but not on the fields. That is very useful for debugging the application. Debugging trace statements can also be placed there
Finally, if a property is a simple field backer it can also be used to provide a read- or write- only access to the fields. This is particularly useful if the object is to be immutable, that is, it doesn’t change once created.
NOTE: This post was rescued from the Google Cache. The original date was Monday, 28th November 2005.
Tags: 
c# software design public field private field
Some of the original comments:
I had this very debate at my place of work several times myself – obviously, as a hopefully good developer, I always argued *for* encapsulation of fields (I’ve taken to making that a key point on any code reviews I do now) – in particular things like access to ViewState and Session objects in ASP.NET.
OK, so I’ve done it myself occasionally too, but nobody is perfect 😀
The nice thing about using C# is you can make use of properties to retro-fit in such an interface later on if you really have to without *too* much pain.
(Yeah, I’ll just go into the cowboy developer corner now….)
Another important reason is DataBinding. DataBinding relies on events name xxxChanged, where xxx is the property name. If you access the field directly, you won’t be able to take advantage of events firing on value changes, and this in turn means DataBinding will break.
To clarify Marc’s point, data binding will not actually break without xxxChanged events, it will just be one way (control–>object).
I have a lot of OO experience, and I can say without doubt that encapsulation is a good thing, but I can still argue against using simple wrapping properties, in theory at least….
The fact that public fields are not absolutely identical to public properties from the interface perspective is a flaw in the implementation of the programming language. I should be able to change a public field to a property (or vice-versa) whenever I feel like it, without it affecting the interface of my class. That is what encapsulation means.
As far as I can tell, the fact that I cannot is because of the implementation of the compiler/clr/language.
>>As far as I can tell, the fact that I cannot is because of the implementation of the compiler/clr/languag
yes , properties is just syntactic sugar, they are implemented as methods : get_Property set_Property in the ilcode
and methods and fields are not interchangable for obvious reasons.
Back in November last year I wrote about why you should make fields in a class private and not make them public. A recent post in Code Project shows that some people still make fields public. I did concede on one argument though – If you have a struct with nothing but public fields then there was no need to make them private and create public properties to back them. But, I added….
As soon as you put any form of functionality in there (or even if you think that at some point in the future there will be some form of functionality in there) then make them private and create properties.
While accessing public fields and properties may look the same to a C# developer, a property is just syntactic sugar over the get_ and set_ methods. So if you make the transition to properties later on (for to add additional functionality – e.g. implementing a lazy look up on a getter, or setting a dirty flag on a setter) any assemblies that relied on public fields will fail because, to them, the public interface of the class is now different.
Therefore if you get in to the habit of creating properties backing your private fields always you’ll never have to worry about how you are going to add in additional functionality later on when you realise the public interface changes.
NOTE: This was rescued from the Google Cache. The original date was Saturday 17th June 2006.
Tags: c# syntactic sugar public field properties
Original Comments:
There is nothing wrong with using public fields in an non-public accessable class.
I dont think its wrong to have public fields in a lib as long as you dont plan on beeing binary compatible, since binary compatabillity breaks the day you change one of those fields to a property..
leppie – I’ll accept that is also another place where it might be okay to use public fields.
Okay – so my blog got hit 30,000 times in the last two days. Specifically this post got hit 30,000 times. It seems to have generated a lot of noise out there. Many people thanking me for the tip (how to stop that annoying dialog asking if you want to reboot when security updates are installed) and some annoyed that I published it. (Can’t win ’em all I suppose).
The original post was published without comment, so I guess it is time to do that. I thought it was a good tip to delay the repetition of the dialog for a couple of hours until I got some work done. The idea being that I’d reboot when I went for lunch or at the end of the day, but right this very minute I want to work.
It seems that many people are using it to stop windows update totally. In my opinion this is a bad idea. Windows Update exists for a reason – that is to help deliver security updates in a reasonably non-intrusive way. Well, that is until the dialog box pops up asking you to reboot.
I offered the tip as a short delaying tactic only – and I have now added a big bold header on the top of the post to remind people of that and that security updates really are a good idea, regardless of which operating system you use.
NOTE: This was rescued from the Google Cache. The original was dated Thursday 29th June 2006.
For auditing purposes some database system run without deleting rows from the database – they just flag the row as being deleted and ensure that queries that run on the table add a line to the WHERE clause to filter out the “deleted” rows.
However, as Daniel Turini points out on Code Project, this can hurt the database performance.
Specifically he says:
Bear in mind that having a flag leads to bad index performance. In my (rather old) SQL Server DO’s and DONT’s[^], I suggest you not to index on the “sex” or “gender” field:
First, let’s understand how indexes speed up table access. You can see indexes as a way of quickly partitioning a table based on a criteria. If you create an index with a column like “Sex”, you’ll have only two partitions: Male and Female. What optimization will you have on a table with 1,000,000 rows? Remember, mantaining an index is slow. Always design your indexes with the most sparse columns first and the least sparse columns last, e.g, Name + Province + Sex.
Creating a “deleted” flag will lead to bad performance, on several common cases. What I’d suggest is to move those rows to a “Deleted” table, and have a view using UNION ALL so you can easily access all the data for auditing purposes.
Not to mention that it’s easy to forget an “AND NOT IsDeleted” in some of your queries.
However, others recon the performance hit is negligable. Or that moving the data to a new table could damage the data. It is an interesting debate and you can read it here, from the start.
NOTE: This was rescued from the Google Cache. The original date was Thursday, 29th June 2006.
Tags: database delete flag audit row performance data integrity
Today, I seem to be having a mental block while writing some unit tests. I keep writing Assert.AreSame() instead of Assert.AreEqual() and then wondering why tests are failing with bizarre message like “Expected 2, Actual 2”
Just in case anyone else has a day like this I’m going to explain the difference (although mainly as a bit of therapy for myself)
The AreSame() method checks that the expected and the actual reference the exact same “physical” object.
The AreEqual() method checks that the expected and the actual are equal to one another, even if they are not “physically” the same object.
NOTE: This was rescued from the Google Cache. The original was dated Friday, 21st July, 2006.
Tags: unit test assert mental block
If you ever move a database from one SQL Server to another you may come across the situation where the logins no longer map to the users in your database (and that’s assuming that the SQL Server you’ve moved the database to has the same logins).
If the new SQL Server does have the same logins then you can fix the mapping by using sp_change_users_login. The neat thing is that if the user and login names already match then there is an “Auto Fix” setting. And if you just don’t know what is mismatched there is a “Report” option too.
NOTE: This was rescued from the Google Cache. The original was dated Saturday 1st July, 2006.
Tags: database sql server backup restore detach attach microsoft
I don’t really think I can say what I think of the TV Licencing people at the moment. I’ve just moved into my new flat. I got my TV Licence transferred over the day before I moved in. And now, three weeks later, they are sending me threatening letters. I knew people that had been harrassed by TV Licencing but it doesn’t really hit you how much a bunch of complete &^*!$%@ they are until they threaten you. Anyway, I’ve got the evidence that I am, and always have been, in possesion of a valid TV Licence and the emails of the hassels that it took to transfer it over so if they do go nuts and report me to the Procurator Fiscal (and I hope I can convince them otherwise – but from what I hear that is very difficult) I can just turn up with all the documentation and say “Here is the evidence. I do have, and always have had, a valid TV Licence.”
In fact, I’m posting this from my parents house – I don’t have broadband yet, and I only just got a phone line put in today. The reason I am here is so that I can access my email and print out the relevant emails. So, not only have TV Licencing caused me stress (my stress reaction is to panic for 5 minutes then over-eat), but I’ve had to complete a 100 mile round trip to get the evidence in case they decide to send the “Enforcement Officers” round to search my flat! And, according to the letter I received today, they now have the authority to do that.
NOTE: This was rescued from the Google Cache. The original date was Tuesday, 26th September, 2006.
Tags: tv licencing threats harrassment procurator fiscal tv licence enforcement officer
Original comments:
The world is full of stupid &^*!$%@ like these. I had a similar incident some while ago when I decided TV was so crap we could do without it. So I did not renew the licence and told the licencing authority the reasons why. Despite this, they hounded me for months.
You should allow them to do their worst then sue them for emotional distress and the recovery of the costs involved in proving them don’t have a case. Bring a small claims court action against them!
I’ve already sent them a letter telling them of my anxiety of receiving their threatening letter and asking for compensation for gathering the evidence quickly in case they break down my door looking for my TV. I also reminded them that, unless things have changed since I was at school, that I was taught that in this country one was innocent until proven guilty.
Hopefully that will be the end of the matter, but having spoken to other people about TV Licensing, it seems unlikely. As a result, I am expecting that by the time a judge gets to see this I’ll have a folder as thick as a set of Harry Potter books of threats and evidence proving the threat to be unfounded.
I had a similar experience in the halls at Uni. I didn’t have a TV, but every week or so I’d have a letter from them saying I owed them money, and every 2 weeks or so I’d have a letter saying that they’d called round for an inspection to make sure I didn’t have a TV, though I was at lectures. It was the janitor who did all this, apparently, and I doubt he’d have spotted a TV card in a computer if I had one. It annoyed me until I emailed them and told them to sod off, which they did. I’ve never had to prove that I did have a licence though.
I had a problem with TV Licensing recently, after I bought a new TV but used a slightly different address to have it sent to than on my TV licence (which was wrong, as the website wouldn’t accept the correct address). See http://mikedimmick.blogspot.com/2006/08/tv-licensing-has-serious-issues.html for the details.
I didn’t post the end result; eventually one of my emails got through, and I now have a letter from them accepting the new address on the TV licence.
I was attempting to install some software recently (a few hours ago, actually) and I kept getting a message saying “The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2755.” while installing the software. So I searched the internet for an answer and came up with all sorts of links:
Anyway, most seemed to suggest that the problem lay with incorrect permissions being set on the file system. So, I went through the file system and checked the permissions as per the Microsoft knowledge base article detailing the problem with the Office 2000 installation. Everything set correctly, I tried again. No luck.
I burned the MSI file to a CD and it worked (CDs don’t use NTFS and its permission system). So, it was something definitely to do with the permission sets.
I downloaded FileMon from the SysInternals website so have a look further at what it was doing. I discovered that it was getting an Access Denied on a file in the Temp directory. (The setup program dumped an MSI file in the temp directory during installation) The problem was, it appeared to be attempting to open the file as NT_AUTHORITYSYSTEM. That account has more rights than the Administrator account, it basically is an Access All Areas account… And it was being denied access!
After some further experimentation, including restoring a system checkpoint back a couple of days, it still wasn’t working. Then I noticed that the temp folder was green which indicates that the contents were encrypted. (I experimented with file encryption a few months ago and had since forgotten about it).
To cut a long story short, I removed the encryption flag on the Temp directory (and spent a couple of minutes waiting for it to decrypt everything) and tried the installer again. It worked!
I don’t know why the fact the folder was encrypted had anything to do with it, but it worked once decrypted. Weird….
NOTE: This entry was rescued from the Google Cache. The original date was Sunday, 15th October, 2006.
Tags: install software unexpected error microsoft knowledge base permission msi ntfs filemon sysinternals access denied encryption
Original comments:
Windows Installer works in two phases – an ‘immediate’ phase in which it generates a script for what to do, and a ‘deferred’ phase in which it actually does the installation. The immediate phase runs under the launching user’s credentials, but the deferred phase is run by the Windows Installer service, which runs as LocalSystem.
If the script is written into an encrypted folder, it will be encrypted using your encryption key. The service, running as LocalSystem, will not have this key, or the recovery key (which is owned by the administrator) and will be unable to read the script.
I just read this article by Joel spolsky on 12 steps to better code. I particularly like item 7: Do you have a spec? Don’t make me laugh – Do I have a spec? Ha, ha, haa!
Item 9 also contains a very amusing story:
At my last job, the system administrator kept sending me automated spam complaining that I was using more than … get this … 220 megabytes of hard drive space on the server. I pointed out that given the price of hard drives these days, the cost of this space was significantly less than the cost of the toilet paper I used. Spending even 10 minutes cleaning up my directory would be a fabulous waste of productivity.
NOTE: This was rescued from the Google Cache. The original date was Sunday 26th November 2006.
The Blog of Colin Mackay 