An object you can depend on

Sorry for that.  I needed a catchy title ;).

Well, now that I’m a WPF Disciple I should probably blog more about WPF.  What’s interesting though, is despite the fact that I’m now working on a WPF project, most of the coding I’ve been doing lately has not been UI related.  So, not much to blog about WPF.

Well, over lunch today my mind was wandering over the stuff I have worked on lately.  Among them was the IoC container I’ve been tooling about with.  One of the things I did with the container was to extend the functionality through extension methods.  Worked great, but occasionally your extensions needed new state information that didn’t exist on the object.  Well now, this ties back to WPF after all.

See, there’s this concept in WPF that directly addresses this.  It’s called an "attached property".  An attached property is a property associated with an object instance, but the backing store isn’t the object itself.  This is accomplished through DependencyObject and DependencyProperty classes.  A DependencyObject has GetValue() and SetValue() methods that take a DependencyProperty as a parameter, and get/set values for that dependency property through some magical backing store that’s not actually part of the object (basically the storage is some giant HashMap).  An attached property is a special type of DependencyProperty that allows you to attach values to any DependencyObject, not just the object on which the DependencyProperty is defined.

So, by turning my ObjectContainer into a DependencyObject, I can allow extension methods to maintain their own state information on the container they are extending!  Such a simple concept, and yet it didn’t dawn on me to do this in my initial implementations.  I rolled all of the necessary plumbing to track associated external state information by hand, and did it every time I needed new state information in a new extension method.  What a waste of time and effort! 🙂

I think I’m starting to fall in love all over again with DependencyObjects.  I’ve avoided using them anywhere but at the UI layer.  I thought it was wrong to bring in all of this baggage at the data/domain layer.  After all, INotifyPropertyChanged gave me everything I need at that level, and Don Box agreed with me.  Well, now I think Don and I were wrong.

You see, even at the domain layer, it’s not that unusual to need an "extension mechanism".  Some way for a known domain object to be extended with more features under certain circumstances.  We’ve all rolled specialized mechanisms for allowing this in the past.  However, with a DependencyObject this functionality is baked in, using a mechanism that’s well supported by the rest of the framework.  I used to think that dependency properties were too much of a PITA to deal with unless you absolutely had to… but I think I’m changing my mind.  The flexibility and functionality you gain by deriving from DependencyObject is probably enough to outweigh the development cost, especially if you use a good set of snippets.

I’ve done a lot of programming in dynamic languages.  The ability to add functions and data to an existing object always proved invaluable in those languages.  Of course, the lack of compile time checks on all of that made maintaining those code bases a bit of a PITA.  It’s kind of exciting to realize now that I have most of the capability to do this but in a statically checked at compile time nature.

Read Full Post »

Newest WPF Disciple

You have GOT to check out the newest WPF Disciple.  I’m not sure I can count all of the contributions he’s made to the community.

Read Full Post »

OCD – Oh is that Code Disgusting!

This is a little rant.  If you don’t like those, move along.

I think coders have been slowly becoming lazier, and now it’s really started to get on my nerves.  I’ve seen SOOO much public code lately that is just frightening!  I’m not referring to the algorithms or other technical aspects of the code here, but rather to the lack of formatting.

I’m not starting a religious war here.  I don’t care if you put your opening brace on the same line or the next.  I don’t care if the braces are indented or not.  I don’t care if you use tabs or spaces.  I don’t care if indents are 3 spaces or 12.  I don’t care if you mark members with an "_", an "m_" or any other wart.  (Well, to be fair, I do have opinions on all of those, I just don’t care if your opinion differs.)

No, what I care about is consistency.  It’s the lack of consistency that I’ve been seeing lately that’s lead to this rant.  In fact, it goes beyond a lack of consistency.  Developers aren’t even TRYING to make their code readable or maintainable.  Want an example of what I’m ranting about?  Check out the published code in this article on CodeProject.  I don’t even know how hard you have to work to get code this unformatted, considering all editors today at the very least auto-indent for you.  VisualStudio will even indent pasted code that originally had a different indent properly.  And one of my bigger pet peeves is with extraneous blank lines.  A single blank line in logical places to call out sections of code is very appropriate.  I use a lot of them in my own code.  But in that first code snippet there’s no consistency in the way blank lines are used, and I count at least 8 lines that have no purpose existing.  Worse, some of those are consecutive.

Are we really becoming to lazy to bother making our code look professional, instead of looking like it was mashed out on a keyboard by a monkey with 3 missing fingers?

Disclaimer: I don’t mean to pick on the author of that CodeProject article.  I’ve not read the article yet, and it may be of high quality, ignoring this glaring issue.

Read Full Post »