>

Sometimes we try to take the short cut when creating our Interfaces and methods. For example, take the IWorkspaceRoot.delete method for an example.

It takes several different parameters:

delete(boolean deleteContent, boolean force, IProjressMonitor monitor);

Most of the time this is implemented in code as the following:
workspaceRoot.delete(true, false, new NullProgressMonitor());
It’s a little difficult to understand just by looking at it without looking at the javadoc what it is doing. The more parameters we add the more possibility for mistakes and more complicated the method’s code. There is a mindset that boolean parameters should be avoided. That it is better to be more descriptive and create a few more method names:
So instead of the above we could have the following specific method names.
deleteAll(IProgressMonitor monitor);
delete(IProgressMonitor monitor);
forceDeleteAll(IProgressMonitor monitor);
forceDelete(IProgressMonitor minitor);
Yes it is four methods now, but each serves only one purpose. The other method was doing at least four things depending on how the switches were set. I’m sure others could come up with even better method names than I have. It is important when we are designing API and interfaces to look at it from a user’s point of view. If it isn’t clear from just looking at the method and its parameters what it is doing, then the method is too complicated and doing too much.
Advertisements
This entry was posted in clean code, eclipse. Bookmark the permalink.

7 Responses to

  1. Mukul Gandhi says:

    >I largely agree. But for example, whether to select:forceDeleteAll(IProgressMonitor monitor);forceDelete(IProgressMonitor minitor);ORforceDelete(IProgressMonitor monitor, boolean isAll);would depend on the use-case, complexity of the logic and few of other factors probably. I usually tend to create methods, when I need to create a reusable module (which can serve various contexts, controlled by parameter values).I also feel OO design is quite a bit of art, and a design for something improves iteratively. And it's not really quite certain, if the next iteration will create a better design, since this sometimes depends on the experience of the designer and his understanding of the problem.

  2. Antoine says:

    >My cubicle-like coworker pointed my yesterday to a method that took a "greedy" argument, for which the javadoc went like this (from memory):@param greedy true if greedy is true or false otherwiseSo not only do I support your view… I also think booleans in function arguments can really suck on the long run.

  3. Mukul Gandhi says:

    >@ Antoine: a bad documentation (javadocs in the example you cited) for a good implementation is the fault of the implementer, and would confuse users of the API.I believe, any implementation (and expected to be good) whatsoever should be supported by a good documentation.I said earlier "I largely agree" (and with caveats). But IMHO we cannot generalize the concepts here. This is more of an art, and there can be different styles of OO design for various requirements.

  4. David Carver says:

    >Mukul I highly recommend reading the following article:http://www.informit.com/articles/article.aspx?p=1375308Also, it is worth taking a look at the book "Clean Code" as well.

  5. Mukul Gandhi says:

    >@ Dave: I agree with Robert Martin's viewpoints, to an extent that having lesser number of method arguments is a good programming *principle*. But this is not really possible in many practical situations given the challenges of scope and time. And as I said earlier, design usually improves with iterations (and I've been experiencing this over the years :))But I certainly agree, that this is a good design principle and should be followed as far as possible.Also thanks for the book reference 🙂

  6. Eric Rizzo says:

    >Mukul's point is one that I agree with wholeheartedly; unfortunately, most of Eclipse's core APIs are locked in a dogmatic requirement of total 100% backwards compatibility at all costs; it severely hinders their ability to evolve. It's a primary reason for the existence of the e4 project.I would rather have seen some more balance between strict backwards compatibility and evolution, but since I'm not a committer I don't really get a say, do I 🙂

  7. Mukul Gandhi says:

    >@ Dave:writing this reply a bit late to this subject 🙂 I gave the points we've discussed, a little more thought, and below are few new things from me.I really do feel, that decomposing a complex software application into various meaningful modules, does help tremendously in managing the software design complexity.While it is also true, that sharing a module for various needs (controlled by parameter values) is another abstraction, which also helps quite a bit in many cases.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s