I've been absent for a few months now. The thing is, I'm spending my little free time writing a non-trivial Android app. Of course, I'm also taking thousands of notes on software design, ready for a comeback :-).
Anyway, staying away from my blog so long is kinda painful :-), so here I am with a short post, inspired by a very simple design choice I had to make.
When you start my little app for the first time, you get an EULA screen. If you accept the agreement, I'll initialize an internal database with some data and bring you the main screen. Ouch, did I say "if"?
Object-oriented programming was supposed to save us from switch/cases (replaced by polymorphism), and an if/else is a switch/case by another name. However, things like "if you accept the agreement" don't fit so well with polymorphism. You can make them fit, but it's not their natural shape. So we end up with just another (fat) controller.
On the other hand, perhaps I'm just saying it wrong. What if I change it into "When you accept the agreement..."? I don't know about you, but that instantly speaks "event" to me. Now, once we stop thinking about "conditions" and we think about "events", a few things happen:
- We can actually implement the concept on top of events if our language/library is event-based.
- We can fall back to the inner interface idiom, if we're in Java-land.
- We may even think aspect if we're bold enough.
Indeed, back in 2008, I wrote a post about reasoning in aspects and then implementing in objects (Can AOP inform OOP (toward SOA, too? :-) [part 1]). The idea was exactly that in some cases (cross-cutting business rules) an event-based implementation could be a poor man's alternative to an aspect-based interception (the subsequent post delved a bit more into some obliviousness issues and into the concept of cross-cutting business rules as candidate aspects).
Of course, we have to recognize the opportunity for an aspect (or event) based design. Sometimes, changing the words we use to describe [ourselves] the problem makes that easier. Next time you're facing an if, try changing it into a when. It won't always work, but it's worth trying :-).
That's it for now. Time to hit the road (snow actually :-). Places to go, clients to meet. Next time, I'm probably going to start a new series here, "life without a controller", because yeah, controllers ain't OO.
If you liked this post, you should follow me on twitter!
7 comments:
Safely :-) back in my hotel, I can add something. Yet another way to change that "if" is with an "after": "after you accept..."
"After" brings "workflow" to my mind, and indeed, a workflow is an excellent way to get rid of complex controllers full of conditionals. Actually, elsewhere inside that app I use a little (custom) workflow engine to deal with a relatively complex communication protocol, and it works like a charm.
As you should know, I'm especially interested about "events", right now :-) So I'm looking forward to learn how to get rid of "controllers" in my applications.
This post reminds me of a comment of yours in the blog about a "GUI rules library". Is it the same idea?
Daniele
My first example will be taken from a simple automation problem, not from the UI layer. It's mostly about being #braindriven :-)).
In a sense, people have been sold so much on MVC, MVP, MVVM, etc that we might be stuck with that style forever. However, I'll try to say something about the UI layer too, sooner or later.
While the controller / viewmodel often becomes a hodge-podge of responsibilities, the GUI Rules approach was aimed at removing only one portion of logic - UI interaction logic. Also, my desire was to make it as declarative as possible. It was a long time ago though, so it was based on Windows Forms. I never moved it to more recent technologies, but would make a lot of sense to target javascript now (where people are mostly replicating old stuff based on static class-based, where the nature of javascript is dynamic and prototype based :-). Or in Android, where coding the UI feels like going back 15 years :-).
Wow, it's a pity you're not going to discuss UI more in depth. It's really an hot argument, due to the fact that every toolkit in every language is based on some form of MVC :S
Just a little comment about going extra linguistic: XAML, for instance; is it good to have external UI declaration or is better a DSL-like library inside your language?
Fulvio: I didn't say no :-), I just said "later".
The markup vs. embedded DSL question is tough :-), and is better answered by decomposition. Here are a few sub-questions:
- is the target language DSL-friendly? Some are, some are not.
- is the library intended to be multi-language (like "all .net languages")? How does that compose with the former question?
- is having a wysiwyg editor or design-time viewer perceived as important?
- if so, can we make one for the DSL? How do we "extract" the GUI-related code? Do we have partial classes or a similar concept?
- do we aim for a "separation of labor" between designers and programmers? Do we aim for different tools?
- etc.
Those sub-questions have sort-of natural answers pushing toward separate UI-definition artifacts and a separate UI-definition language.
The real issue, at that point, is how good that language is, how good the "bridge" between the UI definition and the UI manipulation (our own code) is, and how good the integration with the entire toolchain is. Android, for instance, provides a very primitive form of bridge. Other technologies make the creation of stand-alone, distributable components a pain (that would be trivial with a DSL approach). Doing things "right" in this area is certainly possible, but requires a damn lot of work.
1) The new blog theme is somewhat horrible :) compared to the previous one!!!
2) How would you define the bridge between xaml and c# in WPF (and the new Windows 8 Metro apps)?
3) Is it possible to have good results in language without reflection like C++11??
I'm gonna buck the long-ass comment trend and just state that I love your ideas and how they are conveyed. Very inspiring, please keep it up!
Post a Comment