Getters, Setters, XFAs and YAGNI

It occurred to me about the time I decided to post this blog that this is somewhat similar to a post from Adam Haskell's blog earlier yesterday. In Adam's blog he's talking about "getters and setters" in our CFCs (also known as "accessors" and "mutators" respectively).

Rant in this case is an appropriate description. That's not necessarily a bad thing. Sometimes it seems like we need a bit of a shake or maybe a shock to make us examine our habits. Habits are value neutral, they're neither good nor bad -- but once we've developed them they are awfully hard to break. And sometimes we really need to take a second look at our habits to see if they're really serving us.

Adam's premise is simple. Ninety-plus percent of the getter and setter methods we write in our CFCs don't actually do anything that's necessary. And so the YAGNI principal (Ya ain't gonna need it) would say, you shouldn't write them. The idea behind YAGNI is pretty simple and it's actually a fairly astute observation about human nature. As we're looking at a task we can see all sorts of problems that may crop up... but that doesn't mean they will. And humans aren't very good at predicting the future, so we say "don't prepare for problem x until you have problem x because otherwise You Ain't Gonna Need It". It's precisely the same as "don't put the cart before the horse" and "we'll cross that bridge when we come to it".

Personally I think in the real world we need a balance of both although balancing those kinds of things is particularly challenging for humans because we're such creatures of habit. We're much more inclined to develop either a YAGNI habit or a Big Design Up Front (BDUF) habit and stick with that.

In my case I agree with Adam that we shouldn't be writing "useless" getters and setters. And at the same time I also agree with others that we need that encapsulation (and so I tend to shy away from "this" although I have made some exceptions). That's the reason why I use dynamic setters and getters, which solves both problems at once. Yes you can have the best of both worlds -- it's not a black and white problem and your choices for solving it are not black and white either.

Which brings me to my own pseudo-rant. I say pseudo because I'm not really going to be ranting about this, just pointing out the similarity to Adam's rant. It's kind of funny and appropriate that I'm comparing this to one of Adam's rants since he's the new project lead for the Fusebox framework and the XFAs I wanted to talk about are a concept that originally came from Fusebox and has since spread to all the popular framework communities. And I'm going to say something very similar to Adam here.

You Ain't Gonna Need It. So why are you spending all that time writing XFAs?

Now XFAs have their place. When you have a view template with links and those links are context-sensitive, then yes, absolutely, you should have some standardized way of swapping out the default target page for another page.

The problem is not that we have XFAs. The idea of XFAs by itself is a good idea. The problem is that a long time ago it was decreed that all navigation must go through XFAs. And hence we developed a habit of doing it and of thinking about it as being a good thing all the time. But the reality is that well over ninety percent of the time, it's busy work. That's because the vast majority of view templates are NOT reused in a manner that makes those links context-sensitive. So we really should only be creating XFAs in those unusual cases in which we're actually using them. If a particular view is included in one page in your application, there's no need for XFAs. Even if it's included in two or three pages, there may still be no need for XFAs if the links don't change. Only create XFAs when you have an actual need for them.

All that being said, the onTap framework offers a few different methods by which XFA-style navigation can be injected into views. They're parts of the framework's templating engine which I've described before as an "HTML abstraction" and they're pretty easy to use.

This is a pretty simple example. The tap:url tag allows you to designate whatever variable you want to inject into the href attribute. If the href attribute already has a parameter by that name, the tap:url tag will replace the original value. There are several other ways that links like this can be altered including XSLT which is a pretty powerful method that allows the link tag and surrounding HTML to be modified in other ways as well.