Chris Holmes Online

Lately it seems like I’ve been asked this question a lot when I’m doling out advice on using CAB: How come I don’t use [ComponentDependency] or [State] to pass model state to the Presenters/Controllers via Dependency Injection?

In answering this question I learned something about the way I think about architecture, classes, dependencies and data. And since the question gets asked frequently enough, I figured it deserved a blog post.

There Is A Difference Between A Dependency And The Model

I’ll start by saying that I think there is a big difference between a dependency on another class and model state (data). In my opinion, the calling class should not be able to exist without its dependencies – it’s like a car without wheels or a an iPod without memory – it’s fairly useless. (This is, incidentally, why I prefer constructor injection over property injection; I don’t like the idea of being able to create an object without all the necessary parts.) But a calling class could (and should) be able to exist without the model – the data. The calling class should be able to accept input at any time, not just at construction.

Dependencies, to me, are classes that the calling class must have in order to do its job. Dependencies perform a critical task in the overall use case, and as such they have to be there when the object is created. And hopefully these dependent objects exist as such because we’ve separated out individual responsibilities of the larger use case into small classes that do just one job and do it well. Our calling class should be relying on only interfaces to these dependencies – a contract and nothing more. They key point is that the calling class can’t do its job without its dependencies. It’s like a crock pot without a chord to plug it in; it’s useless if you want to cook anything. If a user tries to operate the calling class without its dependencies it should fail miserably.

Model state, on the other hand, is something the calling class should be able to live without and accept at any time. It’s data that should be passed in whenever. It’s like the food for a crock pot. The crock pot (calling class) can exist just fine without any food in it. You can plug it in, turn it on, and turned the knobs. When you use a crock pot, you put one type of food into it (uncooked data) and you expect to get another type of food out of it (cooked data). The crock pot processes the input and gives an output, and this is the way most classes operate. And like a good class, a crock pot can accept input at any time, be it 9AM or 5PM (you, as the user, just have to be prepared to wait for the expected result, but I’m not going to get into background threads here )

This is the main reason why I don’t find it acceptable to use Dependency Injection to get the model into a Presenter. A model isn’t a dependency – it’s data. It is input that should be acceptable to pass to the class at any time. Dependency Injection is for creating types that the calling class needs to operate, not for passing data.

So How Do We Pass The Model Around In A Multi-View, Shared-State Scenario?

In CAB, I find the EventBroker to be the best way to pass model state to child views in a large, multi-view scenario where each view needs to rely on a shared model state. I leave it up to the Controlling class (typically a WorkItem) to handle the fetching of the model (from a service, repository or factory). When it is ready to load the child views, it fires a Load event and passes the model state as an event argument. Since objects are pass by reference in .NET, every listening class gets the same instance of the model. An update to some portion of the model on one view can be immediately reflected in the other views (if they’re looking at the relevant portion of the model).

I like the EventBroker in this case because it keeps a clear separation between dependencies and data.

With the EventBroker, the Controller has the flexibility to determine when to give the child views the model. This ends up being useful later on, because now a View can receive updated data at times other than object instantiation, and we get to use the same input mechanism (namely, an event argument). With the EventBroker I don’t have to worry about when a Presenter receives its data, just that when it does, it knows what to do with it.

The other thing I really like about using the EventBroker is that it becomes super-easy to test the Presenter. The EventBroker uses attributes to decorate methods, and that makes testing a Presenter nothing more than simple method calls to invoke the logic. This frees me from having to utilize a TestableRootWorkItem, for instance, to test a Presenter. I don’t like having to rely on big, bloated test stubs just to test simple method calls.

…is bad disks.

For about the 3rd time in as many months I’m saddled with another scratched and damaged DVD that won’t play. This time it’s “Michael Clayton.”

I’m sick of this. Are you listening Netflix? You must not be, because there’s easily accessible way for me to contact you on your website and tell you THIS SUCKS!

Netflix and other online movie rental companies want you to think that having movies mailed to you is the greatest thing since sliced bread. But the basic problem is that the media is too fragile; DVD’s are too easily damaged. It’s far too easy for the average person to incidentally scratch a DVD to the point where it is unplayable. Never mind the careless folks who just don’t give a shit and scratch them up because they’re clumsy oafs.

This would be manageable if Netflix would comp you a free movie when this happens, but they don’t. Instead, they ship you out another movie on the next business day. Meanwhile, you have to eat the lost time in shipping since you got a bad disk you can’t watch.

What’s really disappointing in all of this is that no one apparently considered the fragile nature of the DVD when they were attempting to create the next great removable media. Every time I see a science fiction film or television show where the actors utilize some snazzy, futuristic removable media (think “Serenity”), the media is always a well-protected one, encased in a shell that prevents it from getting scratched (or destroyed by martial arts fighting villains).

A disappointing end to the weekend.

Savvy moviegoers know that very few films reporting to be “based on a true story” are actually real or accurate. Hollywood likes to dramatize whatever nonfiction it gets its hands on. It’s tradition. And here, with “21“, we have Hollywood doing its very best dress-up job, complete with all the standard plot devices and dramatic accessories.

The film is loosely based on the best-selling novel “Bringing Down The House” by Ben Mezrich, which itself is loosely based on real events of the MIT Blackjack Team. After a couple degrees of separation one wonders how much the film resembles the source material.

If there’s a flaw with “21″ it comes in the form of a fairly generic script that follows the standard plot points required of such films. This is not necessarily a bad thing. For instance, in the film, the main character, Ben Campbell (Jim Sturgess) joins the Blackjack team because he needs to come up with $300,000 to pay for Harvard Medical School. In reality, Jeff Ma, the player whom Ben is based on, got involved because he thought it would be “fun”. There is no denying that the Hollywood version provides a bit more drama.

But while the film is pedestrian in terms of plot, it still works, for two reasons in particular. The first reason is because of all the smaller moments that ring true given a person in that situation. As Jeff Ma explained in an interview on Ain’t It Cool News:

…the transformation that Jim goes through from being a nerdy MIT guy to all of a sudden being able to land Kate Bosworth as his girlfriend… That was something that definitely happened to me through the blackjack experience, where I became much more confident in what I was doing. The first scene where they fly into Vegas and he looks out the window and sees the lights and everything like that, that was a feeling I certainly remember. That one scene where he is lying in bed and he calls and tries to get room service and he’s in his dorm room, not a hotel… Those kinds of things just happened all of the time, because of the craziness and sort of duality of our lives.

The other reason the film works is because of the strategy used by the MIT team.

Counting cards is not illegal. It is, however, frowned upon by casinos, for obvious reasons. And because casinos are private property in Las Vegas, gamblers can be asked to leave, and must do so or face trespassing charges. We learn from the film that the really difficult part of card counting is not the actual mathematics; anyone with reasonable math skills can practice it and get good. The real difficulty of the system lies in avoiding detection. For this reason “teams” are employed, which consist of various members, mainly “spotters” and big bettors. The team members work together to detect when a table is “hot”; that is, when the odds are in the players’ favor. The spotter’s job is to bet the minimum at all times and look inconspicuous while keeping track of “the count”, then signal the big bettor when the table’s count is in their favor. The bettors job is to come in and bet huge sums of money. Together, a successful team remaining undetected can rake in thousands of dollars in a weekend.

Kevin Spacey and Laurence Fishburne do an admirable job with roles that are pretty thin. Overall the film is shot well and the acting is fair. It’s not a great movie by any stretch, but it does manage to be entertaining throughout.

Every now and then when I’m sitting in front of my IDE I run into a problem I can’t solve. Strangely enough, these problems are almost always related to the User Interface.

The problem I’m currently faced with is: How to draw a semi-transparent overlay on top of an existing Windows Form in .NET?

We have certain views in our application that see heavy re-use. They appear frequently in many different contexts. This is good for code re-use, but it confuses the users. Because all of the instances of the particular view look the same, the users aren’t immediately aware of the specific context.

The way I’d like to handle this is by overlaying a semi-transparent color on top of the view. This sounds simple enough; it seems like it should be easy. Perhaps just specifying a brush with a transparent color and draw on the client rectangle.

Oh, but it isn’t that easy…

There are a lot of obstacles in the way of doing something that sounds so simple. The first obstacle is that the view (Form/UserControl) draws itself first, and then all of its controls. There’s no option to come back after all the controls have been drawn and draw an additional thing on top of the main view. The child controls don’t get painted.

Ah, but with a little recursive magic, maybe it will work eh? Tell all the child controls to draw the transparent color as well, right? I tried that too; turns out only a few controls will obey and you end up with this:

The DataGridView obeyed the painting (which is great) but the ListView and TextBox did not. I could possibly live with that, but the DataGridView flickers quite a bit whenever a cell is edited, and that’s a bummer.

It is times like this, when I run up against the limitations of the Windows Forms API, that drive me nuts. I don’t suppose anyone has a working suggestion?

I love this post.

The funny part, to me, comes from one of the comments. Bruno writes:

I believe the better way is to do it INLINE, instead of 4 lines of code
.
.
I don´t like to scroll my screen to read small, very simple portions of logic…

I laughed when I read that comment.

“Simple portions of logic”….

Made more complicated by inline statements…

I laughed because I had just done a cursory review of two of Kent Beck’s Extreme Programming books today, and in one of those books he talks about simplicity and intent. He talks about how some programmers have a difficult time writing simple code; they think complexity is some sort of measurement for how good a programmer they are. They find job security in complexity. They find self-worth in complexity.

Personally, I think the opposite: the simpler the code, the better programmer you are. If you can solve a complex problem with simple code, you have real skill. Plus, simple code reveals its intent faster and with less effort.

I’ve got more important problems to solve than deciphering cryptic code.