Monday, July 23, 2012

The evils of auto properties & object initializers in c#

I've been thinking a little bit about object orientation recently. It seems that OO was the poster child of the 1990s and has been the leading paradigm through the first decade of the new millenium. The thought behind this was that object reuse would solve all our problems but in reality they didn't. Even with languages gaining objects, C evolves to C++, and being built with objects from the ground up such as Java and C# people still seem to just not get it.

Back in OO school I learnt that objects should be polymorphic, inheritable and encapsulate discrete bits of behaviour. In OO college I learnt that we should strive for low coupling between our classes and high cohesion. In OO university I learnt about the SOLID principles and that I should favour composition over inheritance. It's been a long journey and I'm still on it but all over I'm still seeing non OO code in .NET all over the place. Is OO too hard for people? Or is just a broken paradigm?

Well my friends, OO is hard but I don't think the C# language designers have helped.  The two worst features for Object Orientation in c# are auto properties and object initializer syntax. "What?" I hear you say, "Auto Properties? But they're so useful! (and cute). Object initializers they save so much time!"

They are evil.

More and more I'm beginning to see classes like this:

and initialisation like this:

People are abandoning the general principles of object orientation. We are exposing the internals of our objects with gay abandon. This is a dark route that inevitably leads to pain. Every time you use a vanilla auto property you are introducing an opportuntity for coupling, which reduces the modularity and resue of your code. Your classes becomes mutable so lose all the goodness that immutability brings. By allowing 'Children' to be initialised in this way you break the Principle of Least Knowledge and couple your class even further. It's no wonder that we can't do OO if we take short cuts like this. Now of course there are reasons for using initializers, simple DTOs and anonymous classes spring to mind but don't be fooled by this syntactic sugar, it will rot your teeth!


Evil Andy said...

It's horrific how many people would never dream of putting a public field on their object but can't see the problem with an autoprop.

And if really is meant to be DTO then make it obvious by making it a struct with public fields so no one's tempted to hang behavior on it.

Unknown said...

Disagree. Everything has its place. These features are simply tools. The problem is not that they are there, but that they are used by many developers poorly. Is the answer to incorrect usage of a feature to take it away and inconvenience all who know better? Or to educate people on how and when a given language feature should be used most effectively?

johnnyreilly said...

It's a really interesting thought. If you've the time I'd be interested to see an example that illustrates your point - where making use of auto-properties / object initialisers causes a clear problem.

At the moment I kind of feel that theoretically yes you may have something here, but practically I'm not seeing it so much...

Maybe I'm missing something?

Unknown said...

Hi John,

It's simple design concern.
See this Gist