Naked Objects in WPF?

There is a rather niche architectural pattern called naked objects. In this pattern, you build your entire application as an abstract domain model. If you do MVC, this is like building the application using only the M. Your users will then interact with this model directly.

I call this a niche pattern because none of the major frameworks support it. What I want to explore though is how we can fake it in WPF.

If you use strict naked objects, you won't build a user interface. The framework will take care of it for you. Frankly, this kind of scares me. I only imagine the monstrous forms that will come out of this thing.

In WPF, you can define a template for arbitrary classes. What I'd like to try is to define a UI form by dropping domain objects and importing a resource that will act like a skin. That resource will have the templates that define how the properties of my objects will map to UI controls.

This is just a thought I've been kicking around though. One problem I haven't worked out is how to map events on the controls to method calls on my objects without making every single method a routed event handler. I'll have to see if there is a generically capture the events on some controller class and automatically re-map them to method calls.

Why would I want to do this? Well... I've got a couple 2000 line code-behind file's I've inherited that prove, yet again, that you can write spaghetti FORTRAN in any language.

A Crazy Idea about Dependency Injection

At the end of my post yesterday, I mentioned the term Dependency Injection. I can't go into too much detail because it's not a concept I've really been able to work with much... yet. My only real exposure is the Google Guice book.

That's not gonna stop me from diving right in though.

Basically, when you use DI, you never use the new operator which means you never explicitly allocate objects. In a modern programming language (where modern implies garbage collection), this give you quite a bit of flexibility to reconfigure your app without changing your business logic. You just configure which concrete classes are mapped to which interface. For instance, you can remap ICurrency from Dollar to Euro in one place.

What's struck me though is the implications this might have for C++. By taking 'new' out of the program logic, we should be able to abstract away most, if not all, of the manual memory management that is so painful.

Instead of allocating an instance object in the constructor and freeing it in the destructor, we inject an already allocated object into the constructor. It is now the DI container's job to allocate and deallocate that object. Finally, assuming that you have a good enough DI framework (is this like a smart enough compiler?), it should take care of that task for you. You just map types.

Am I crazy?

What's in your object?

In the ThoughtWorks Anthology, there's an essay by Jeff Bay called Object Calisthenics. Briefly, the essay lays out a set of rules for designing classes that are rather strict and quite different from what you'd normally use to guide your programming. If you do a quick Google, you'll see that this essay has received quite a bit of criticism in the blogosphere. Most people seem to say that the rules are too strict and just get in the way.

If you haven't read the essay, there's an overview here.

I'm applying these rules as much as I can in my day to day development, and I've noticed a few things. First, it's not kind toward legacy code bases. It is especially unkind toward WPF applications. WPF is built almost entirely on .NET properties and practically begs you to break encapsulation. Yuck... but I blame WPF rather than these rules.

Next, it's turned my code inside out. I'm used to grabbing a few objects, getting some data out of them, doing something to that data, and then passing that data to some other method. Usually this is so I can then return a new value. Since I'm not doing gets anymore, I have to send commands to those objects and then let them do some computation on behalf of the caller. It kinda reminds me of the message passing style you do in Erlang.

So what's this gotten me? For one, unit testing is easier. If you use get, you end up with an object that you then have to verify. This object will have state of its own which will likely have to be verified. This isn't a unit test anymore. It's an integration test. Instead, by sending messages, especially with mocks as parameters, you only have one layer of code to test.

Also, Dependency Injection become much more natural. But that's a topic for another post.

When is it time to move on?

No one stays with a company forever anymore. Especially in technology, it's normal to keep a job for a couple years and then move on to the next opportunity. Alex's article on IT turnover is the only answer I've seen to this question, but it's a good one.

Alex, though, addresses the question from management's perspective. What about the developer? All we know (again, from Alex) is that we eventually get the feeling that the job is just no longer for us. That's not real specific though, and probably leaves a lot of room for false positives. This frustration could have another source and a different way of dealing with it.

Personal Conflict

The actions of people working around you can be frustrating to the point of wanting to just walk out. Obviously, this is not the same thing as knowing that your time is up, and by walking out early you could miss out on big opportunities.

Solution: Identify the people that frustrate you the most. How are they impeding your contributions and your ability to learn? What can you do to ease the tensions or, failing that, side-step them?

Boredom

If you're bored, you're probably not learning, and you're not producing at your best.

Solution: Is there anything there that does interest you? Maybe a lateral move inside the company is in order. If not, it's time to go.

Don't get it

Maybe there's a problem with the system. Maybe it really is advanced and necessarily complex. Either way this leads to daily frustration.

Solution: If the system is broken, are your co-workers willing to help fix it, or would they rather simply live with it? If it's necessarily complex, this is a great opportunity. Find someone who can teach you the fundamentals of how and why it works. If no one can teach you, research it yourself. This will do more than just pad your resume, you'll be smarter for it.

Don't fit in

Sometimes your just meant for a different culture. The corporate man's probably not cut out for the startup life and vice versa.

Solution: If you can't or don't want to adapt, go find someplace that's a better fit.

Irrelevance

No matter how hard you work, or how persuasive your arguments, management and your co-workers just aren't receptive.

Solution: You need to find out why, so that if there really is a problem with your work, you can fix it. Otherwise, a new job won't fix anything. On the other hand, if you can't get a good answer out of them, there's nothing you can do to fix it.

Conclusion

It's true that eventually we'll need to move on and find another job. Just make sure it's for the right reasons. This is not a decision to be taken lightly. If you consider all of the points above (and come up with some of your own) and you still can't make the job work, then it's probably time to update the old resume.

CodeIgniter

I'm playing around with CodeIgniter, and I have to say that I like it. My web development experience is limited (I've done mostly SymbianOS), but so far it's been a lot easier to get into than Rails and Django. It doesn't seem to have the semantic overhead that I found in the other two frameworks.

The April fools jokes circulating the blogosphere seem kind of lame. We have CouchDb being rewritten in Java, and Google's Virgle. Neither of those are particularly entertaining. Tim's was pretty good though.

Don't demo development code

Apparently one of my coworkers is doing a big demo today. That's news to me. He's demoing the development version of the app. That's also news. I just committed some big changes. Oops....