Event-Driven Programming and Loosely Coupled Software

Recently on the CFOO Google group, someone commented on a statement I made regarding MVC for web apps. They were scandalized that I verbally rolled my eyes when Brian mentioned MVC frameworks. What? Hal Helms is dissing MVC? Well, yeah.

The problem isn't MVC (Model-View-Controller), in which each piece of code is placed in one of three "buckets" depending on whether their job is display (goes in View), business logic and data persistence (goes in Model) or coordinating interactions between Model and View (goes in Controller). MVC is a time-honored pattern and, to my knowledge, I was the first person who introduced MVC to the ColdFusion community at an early CFUnited presentation. So what's with the disrespect?

It's this: MVC has become (yet another) magic buzzword that promises adherents that by following this pattern, their code will be more maintainable. That's a bit like Ferrari advertising that purchasing one of their cars will make me a racecar driver.

If MVC alone isn't the answer, what is? Well, it depends. (Sorry, inside joke.) In fact, there isn't a single answer, but there is an overriding principle that will help us produce more maintainable code. The principle is loose coupling.

Oh, great: another buzzword. Let's unpack it. Think of software as made up of separate components. For now, it's not necessary to exactly define what these components are, just that they exist. In fact, you can think of components as tiny people residing in your computer. Let's take a simple application made up of the following people: Anna, Bob, Carla, David, Ellen, and Fernand. Pretty simple software.

We learned a long time ago that things tend to work best if different people focus on different jobs. But to get large-scale work done (like a software application), the work of our cast of characters needs to be coordinated.

What to do? Well, we'll just introduce the different people to each other. Then, if Anna needs some functionality that Fernand handles, she can ask him for assistance. Perhaps we'll have a mixer in which the different components get to know each other.

Fernand: You have a large Barbie collection? My sister loves Barbie.

Ellen: Did someone say "Bobbie"? As in those English police? I went to London with my church's choir.

Bob: Let's leave religion out of this.

David: Whoa, cool down, Bob. Ellen wasn't proselytizing.

Carla: He said "Barbie". As in the dolls. I have a big collection.

We'll leave them to work things out. They're getting to know each other, which is important if they're going to coordinate their efforts. Team building: it's a beautiful thing.

Now, after a while, our team learns to work together and things are flowing nicely. There is a limited amount of interactions possible:

6 components = 15 possible interactions. That's manageable.

And then trouble starts. Our meddlesome client wants the software to do more things. Or wants the existing software to act differently depending on some conditions. Now, we need to introduce Gina and Horace. Only now, there's not much time for the new components to get to know the original ones. So communication starts to break down.

Ellen: Excuse me, Gina, but what you've asked me to do isn't my job!

Gina: Don't have a cow. I'm just trying to help.

Ellen: Well, maybe you should go to Bob for that.

Gina: He was busy.

Ellen: And I'm not?!

Horace: Who's responsible for sending messages to the user?

Gina: I think it's Anna?

Anna: Not me!

Uh oh. Our tightknit group is starting to unravel.

Introducing two more components greatly increased the complexity of interactions.

6 components = 15 interactions

but

8 components = 30 interactions

But perhaps over time, the additions will be integrated into the group. Only...

Again, this customer! Now, they need even more stuff done and, knowing the problems of introducing outsiders into the group, we decide to cheat a little.

Me: Say, Fernand, do you think you could take on this additional task?

Fernand: But I know nothing about that.

Me: I know, but it's just a little thing. I promise: it won't be that big of a deal.

Fernand: Carla never seems to have anything to do. Why don't you ask her?

Me: Fernand, it would be a shame if someone forgot to...instantiate you.

Fernand: Hold on, hold on! If you need it done, I guess I can help out.

Poor Fernand. Poor program. You know where this is heading and it's not good.

The problem isn't Fernand -- or any of our crew, but the decision I made that coordination would be handled by each component knowing about the others and calling on them directly. My software may be highly encapsulated but it's also tightly coupled. That's what happens when different components address each other directly. But let's rewind the clock and have me make a different decision...

Bob: So, Boss, I see you've assembled a team to handle various stuff. You gonna get us together to get to know each other?

Me: No, Bob. I suspect that won't work that well.

Bob: Really? At my last job, the team would get together every Friday for drinks and "decompression".

Me: How did that work out?

Bob: Oh great! It was a lot of fun.

Me: No, I mean, how did it work out as far as the software?

Bob: Yeah, well, there were some problems. [sotto voce] Between you and me, some of those orange components just don't understand how we do work.

Me: Got it. Thanks, Bob. [loudly] Team? Can we gather over here? I know you've all worked at other places and are used to working together in a certain way, but we're going to try something different.

[murmurs from the team]

Me: When you need something -- or when you've just done something -- I want you to just shout it out.

Ellen: To who?

David: To whom, do you mean?

Ellen: Whatever...

Me: Just shout it out to no one in particular. But let me know the specifics. Like, if you need a form to add a customer...

Bob: That's my job!

Me: Right. Well, if anyone needs that, just shout out "I need a form for a new customer. And I'd like it to appear right here."

Bob: I have some paper slips that will make this really easy. If you'll all just take some, then when you need a customer form, just...

Me: Hold on, Bob. That's not how we're doing it. If they need a new customer form, they're just going to shout it out.

Bob: Well...what do I do?

Me: You listen for that.

This style of architecture is called event-driven. It's based on the idea of an event (and any information relevant to that event) being announced without any sense that the person announcing the event knows who's listening for it.

Event-driven programming is one of the best techniques we've found for producing loosely-coupled software and loosely-coupled software is one of the keys to maintainability. Let me give you an example of something that happened recently...

Customer: Well, it looks like things are going great.

Me: Glad to hear it.

Customer: But you know what would be nice?

Me: Uh oh...

Customer: Is if we had context sensitive-help. Cause our users get confused when they're trying to perform some task.

Instead of going to Anna and Bob and the whole crew, asking each of them to take on the task of responding to help requests, I hired a specialist: Inez.

Inez: I do help. I do it well. I have my own way of doing things. Please do not interfere.

Me: I wouldn't dream of it, Inez! When someone needs help, they're just going to shout out "Help!"

Inez: That will be acceptable. Only I need to know what area they need help in.

Me: No problem. That information will be in the event object that you'll be given when the cry for help is announced.

Inez: And where will I deliver this help?

Me: You'll be given a "context" -- also in the event object that will specify the location.

Inez: Good. And I don't have to get to know these other "modules"?

Me: No, I know you're very focused and don't want to get "off task".

Inez: I predict a long and profitable collaboration.

I do, too. By decoupling software components, we can add or alter functionality more easily. Now, within the context of event-driven programming, does MVC make sense? Absolutely. It's not the only way, but it's a very good way. The thing to remember: buzzword compliancy does not ensure good software design.