One thing that seems often to come up in discussion of OO development is the size and number of your methods. I’m a fan of having small methods with matter-of-fact names, even if it means my class may seem to have “too many” of them.
Of course, “too many” is a fluffy concept. How many methods are enough? How many are too many? Abe Lincoln was once asked how long a man’s legs should be; “Long enough to reach the ground” was his answer. I’d argue that the right number of methods for your class is that amount needed for the class to get its job done.
That’s still not a satisfactory answer; one can inline code and drop methods, and the class will still work. But that comes at a cost; methods then tend to get larger, harder to read, and less cohesive.
A plausible approach is that if you think your class has too many methods, maybe your class is doing too much, and you need to refactor to more classes. Seems, though, that people resistant to a plethora of methods also abhor “too many” classes, and the reasoning in each case is roughly parallel.
In looking around for some opinions on this, I came across this remarkable ruby-talk thread from 2002: Small Methods – a ramble
(Side note: such threads are now extremely few and far between on ruby-talk. Reasons and consequences of that are a topic for another day.)
What’s interesting is that much of the argument for or against having many small methods is based on tools. Smalltalkers, using their code browser, found it easy to navigate among method implementation; those against the many-methods approach seem to find themselves manually scrolling through text files, and argue this is disruptive and tedious. This is fairly specious, given what any decent code editor can do, (Vim users: go check out rtags if you are not already using it. I imagine TextMate can do the same thing.)
In reading through the thread I found myself nodding along with Mike Thomas (msg #31114 ; “In my opinion, the editor is no ‘excuse’ for not factoring code properly.”) and Albert Wagner (#31115, “it is an attempt to reduce the visual complexity, so as to be able to grasp quickly what is going on in a method; i.e. , condense a snippet that is not duplicated anywhere else into a sort of language shorthand.”) And I like the “Watership Down” syndrome idea.
Naturally, one could argue that having large numbers of methods and classes just gives you more, not less, to track . Except you aren’t going to be storing all those methods in your head; a big win for OO design is that you don’t have to keep everything in your brain, you need to track a limited scope at some particular level of abstraction or detail. One should be able to get a clear, reliable high-level view of an app by looking at the high-level code; when you need detail, you jump to where this or that is implemented.
It isn’t until message #31214 that testing is mentioned. This is from 2002, before TDD and BDD really took hold in Rubyland. Smaller methods seem naturally to come from TDD. Or, conversely, if you have large, busy, methods they are almost certainly hard to test, or test correctly.
Interestingly, Brian Marick, who knows better than most about testing, comes out in favor of (somewhat) larger methods (#31170). His reasons are quite interesting, following earlier observations on communication, expressing intent, and how different tools influence thought. (And now I really want to know more about Stanley Fish’s “affective stylistics”.)
David A. Black follows with this observation:
Clarity is such a vexed thing. I believe people who say that they find Perl code clear. (I used to find it reasonably clear – I’m a little out of the loop right now :-) I also believe people who say they find it opaque, and I believe those people when they say they find code in some other language clear. (Which is to say, if a non-programmer said Perl was opaque, that wouldn’t “count” in the same way.) Clarity is annoyingly relative; it seems that what you find clear is what you’ve learned to find clear, and/or perhaps are cognitively predisposed to find clear.
I’m curious as to what others do, what heuristics Rubyists (or not) have for determining method size, number of methods, size and number of classes, and so on. What are some good resources for this?
What’s the method for clarity?
Read: Method madness? Too much class?
Previous Topic
