Dry parameter names

How often do you see code like this, especially when using dependency injection, single-responsibility principle, and other “good practices”?

1
2
3
4
5
class FriendsTimelineReader(userFinder: UserFinder,
   userStatusReader: UserStatusReader,
   statusSecurityFilter: StatusSecurityFilter) {
   ...
}

Note that the parameter names are exact copies of the class name. That’s certainly not DRY!

In Java writing such code is a bit easier than in Scala, since you write the type first, and then the variable name can be auto-completed (the fact that there’s an auto-complete in IDEs indicates that it’s a common pattern). In Scala there’s more typing, but then, less boilerplate around declaring fields/defining a constructor/assigning to fields.

How to avoid that? We can always use cryptic variable names, like “ssf” instead of “statusSecurityFilter“. But then the whole effort of having nicely named classes to make the code readable, which is quite a hard task, goes to waste.

Of course, variable names are very useful, for example when we have to distinguish between the 10 String parameters that our method takes, create an Int counter, etc. But the more we use specialised wrapper-types (and now possibly even more, with Scala 2.10 introducing value classes) to make our code more type-safe, the more fine-grained our services – the more often the variable/parameter names will mirror the class name.

Even when there are a couple of instances of a class, often the parameter name contains some qualifier + the class name (e.g. given a Person class, personAssociator.createFriends(firstPerson, secondPerson)). It would be interesting to see some statistics on how often variable name is a mirror of the class name or a suffix – I suspect it can be a large percentage.

Maybe the next step then in type safety is limiting the complete freedom when naming parameters? Or even, getting rid of the parameter names at all in some cases.

For example. In the snippet from the beginning, we just want to get “an instance” of a UserFinder. Most probably there will ever be only one instance of this class in the system, and certainly one will be used at a time by other classes. So why not let the class express that it wants an instance of a class, without having to name it? Let’s use the indefinite article “a” as a keyword (we don’t really care which instance is passed):

1
2
3
class FriendsTimelineReader(a UserFinder,
  a UserStatusReader,
  a StatusSecurityFilter)

Now, how would you use such a variable inside a class? Let’s use the definite article “the” – the instance that was given to the class, for example:

1
val user10 = (the UserFinder).findById(10)

Maybe this looks a bit like science-fiction, but wouldn’t it be convenient? Or maybe this problem is already solved by some mechanisms in other languages?

Adam

EDIT 27/01/2013: Extending the above to handle qualifiers:

1
2
3
4
5
class Friends(a 'first Person, a 'second Person) {
   ...
   (the 'first Person).getName()
   ...
}
  • http://gravatar.com/lukaszlenart Lukasz

    But this isn’t DRY anyhow, you must repeat class name to know what you’re referencing to ;-)

  • http://www.warski.org Adam Warski

    Well, eliminating that would lead us to (the class I’m thinking about).doWork() ;)
    Anyway, it’s drier, one repetition less.

  • http://twitter.com/ktosopl Konrad Malawski (@ktosopl)

    Well… this CAN already be done even with scala 2.9.x, though I’m not convinced it this isn’t too crazy… Would have to think about it, and about the compile time (?) implications.

    Here’s a quick demo to show how this can be implemented: https://gist.github.com/4645350

  • http://twitter.com/ktosopl Konrad Malawski (@ktosopl)

    A good comment here would be: “I’m excited… yet at the same time, terrified by this creature I have written”. ;-)

  • http://www.warski.org Adam Warski

    Ah implicits – works of course, though not exactly what I meant ;-).
    The syntax is a “bit” verbose. Though you could define the to work as implicitly (getting the[UserFinder]), implicit is a keyword and would be rather hard to get shortened.

  • http://www.warski.org Adam Warski

    See my edit (bottom of the post) on how to support qualifiers. Doesn’t it read nicely? ;)

  • http://twitter.com/ktosopl Konrad Malawski (@ktosopl)

    If you’d end up using qualifiers it’s just as repeating as using a well-names variable but carries less meaning with it IMHO. The case without qualifiers seems “easier to swallow”.

    This calls for an entirely different paradigm – separate functions from classes entirely? (Thinking golang again, but haven’t implemented “bigger” things in it yet).

    Other ideas… simply Traits? The “Reader” in this example would implement all dependencies (auth config etc), mix in the *finder etc and be done with it hm.

  • http://www.warski.org Adam Warski

    Well, I think the version with qualifiers carries more meaning.
    Compare (the difference would be bigger of course if the class name is longer):
    (a "first" Person) with firstPerson: Person
    The former is more structured:

    • a – we want any instance
    • “first” – arbitrary description
    • Person – of class Person

    I don’t understand the traits comment, can you give an example?

    Adam

  • http://twitter.com/ktosopl Konrad Malawski (@ktosopl)

    @Traits – since the goal is to repeat less of the “blablaFinder.“, the easiest way out is “just traits”, like bellow:

    class A(/*common dependencies*/) extends B with C { // implements dependencies of B and C
    //calls stuffFromC(), no prefix

    Although this raises questions about SRP etc.

    Coming back to the idea of abandoning classes (like go), here’s a paper I’ve read some time ago about “Organizing Programs Without Classes” http://cs.au.dk/~hosc/local/LaSC-4-3-pp223-242.pdf Although the focus of the paper is slightly different it – it’s pretty interesting in itself and gets you thinking :-) Examples are in the self language (imagine like-js). Anyways, there’s a lot of room for experimentation here :-)

    Disclaimer: I have not yet written much in self or go, to feel if it’s a good idea or not – just thinking out loud :-)

  • http://www.warski.org Adam Warski

    @Konrad, but then you end up with all methods in one big namespace, which makes it either hard to read, or makes you have to prefix the method names with some context – which essentialy boils down to removing the dot from the invocation ;)

    I’ll take a look at the paper, thanks.

  • http://www.johannesbrodwall.com/ Johannes Brodwall

    Insane and intriguing.

  • Caesar Ralf Franz Hoppen

    It’s a cool idea. This would help in refactoring, where you find a better name for the class you created.

    Another cool stuff is that this kind of naming helps you see if your class doesn’t have more responsabilities than it should, because reading something like ‘the UserDao.doSomeCalculation’ feels strange.

  • Pingback: Don’t repeat yourself | Frank Börncke's <Weblog/>