Object Mentor Blog: Refactoring Exercise

Refactoring Exercise

Brett Schuchert — Thu, 04 Jun 2009 21:23:00 -0500

So I’ve written a somewhat ugly method with the intent of having people clean it up. Want to give it a try? Post your results and then I’ll show what I ended up doing in a few days (or after the activity dies down).

It’s in Java, but feel free to post in other languages. I’d be interested in seeing something in whatever language Michael Feathers happens to be deeply studying right now!-)

Oh, and if you feel like going “overboard” and using a few design patterns just because you can, I’d like to see that as well.

Here it is:

  public void take(int v) {
    if (currentMode == Mode.accumulating) {
      int digits = (int)Math.pow(10, (int)Math.log10(v) + 1);
      int x = stack.pop();
      x *= digits;
      x += v;
      stack.push(x);
    }

    if (currentMode == Mode.replacing) {
      stack.pop();
      stack.push(v);
      currentMode = Mode.accumulating;
    }

    if (currentMode == Mode.inserting) {
      int top = stack.peek();
      stack.push(top);
      stack.push(v);
      currentMode = Mode.accumulating;
    }
  }

"Refactoring Exercise" by alwadifa

Sat, 05 Nov 2011 18:00:53 -0500

I liked you blog so im going bookmark it with my prefered websites, you have posted an amazing posts so thank you I liked you blog so im going bookmark it with my prefered websites,

"Refactoring Exercise" by Tips For Bowling

Thu, 20 Oct 2011 13:22:48 -0500

The results of ethnic psychology constitute, at the same time, our chief source of information regarding the general psychology of the complex mental processes. Wilhelm Wundt

"Refactoring Exercise" by ysbearing

Wed, 19 Oct 2011 02:27:29 -0500

Slewing bearing called slewing ring bearings, is a comprehensive load to bear a large bearing, can bear large axial, radial load and overturning moment.

"Refactoring Exercise" by herren winterjacken

Thu, 29 Sep 2011 11:55:51 -0500

I am carrying this bag myself,Herren Winterjacken when I wear very girly stuff, mine is smaller than large,herren winter still can fit lap top and all I need…I had been looking for it for several years until I found it 3 years ago in UK.Belstaff Jacken I saw it for the first time in the movie “Interpreter”, carried by Nicole Kidmann, and then in “I, Legend” carried by Will Smith.http://www.herrenwinterjacken.com/

"Refactoring Exercise" by swarovskicry crystals

Thu, 29 Sep 2011 11:55:04 -0500

Swarovski crystal jewelry, on top of that also known as these Austrian Swarovski Crystals, is definitely the most beneficial many costly type of Crystals Swarovski uk . As a result, a majority of these Swarovski Uk items need be adopted special care involving to allow them to last perpetually.

"Refactoring Exercise" by beats by dre store

Tue, 23 Aug 2011 02:37:15 -0500

other content is so deficient that I move on without delay. That is not the case here.beats by dre sale cheap beats by dre

"Refactoring Exercise" by http://www.dunkszone.com/

Tue, 12 Jul 2011 20:13:33 -0500

Great post. It appears that most of the steps are relying on the creativeness factor&.

"Refactoring Exercise" by Cookies Gift

Sun, 19 Jun 2011 11:35:52 -0500

it needs a bokmark so i can come back to it later ,nice stuff

"Refactoring Exercise" by okey oyunu oyna

Thu, 28 Apr 2011 12:37:37 -0500

thank you very much.

internette görüntülü olarak okey oyunu oyna, gerçek kisilerle tanis, turnuva heyecanini yasa.

"Refactoring Exercise" by clothing manufacturer

Sun, 13 Mar 2011 06:44:23 -0500

website page the articles and other content is so deficient that I move on without delay. That is not the case here.

"Refactoring Exercise" by dswehfhh

Wed, 09 Mar 2011 12:39:50 -0600

We are the professional dresses manufacturer, dresses supplier, dresses factory, custom dresses.

"Refactoring Exercise" by Sell Gold for Cash

Fri, 25 Feb 2011 23:30:00 -0600

Another fantastic posting here at Object Mentor!! Thanks for sharing and keep up the great work.:)

"Refactoring Exercise" by http://www.whiteiphone4transformer.com

Thu, 23 Dec 2010 20:38:42 -0600

white iphone 4 is so charming and chic. As the icon of latest fashion, how can you miss it!

"Refactoring Exercise" by Pandora

Thu, 02 Dec 2010 01:37:07 -0600

What does this picture suggest to you or what can you draw from it, if anything?

"Refactoring Exercise" by moncler

Thu, 25 Nov 2010 02:31:10 -0600

I find it incredible that more blogs and forums are not as pleasant as this one.moncler downOften times when I land on a website page the articles and other content is so deficient that I move on without delay. That is not the case here. Thanks so much.moncler men

"Refactoring Exercise" by wholeslae shoes

Mon, 11 Oct 2010 06:59:03 -0500

think you ! http://www.yourvoguemall.com

"Refactoring Exercise" by mlb jerseys sale

Thu, 22 Jul 2010 04:42:53 -0500

http://www.superstonejerseys.com

"Refactoring Exercise" by Chris

Wed, 01 Jul 2009 17:30:10 -0500

@Brett

I think perhaps we are talking at cross-purposes. I am not objecting to the name “enter” in itself, nor to the subtle distinction between “pressing enter” and “completing an input”. I am objecting to the use of any interface-level concepts in the domain model.

In a RPN calculator, the domain interface requires three basic operations: putting in a number, putting in an operation, and reading out the current value.

Internally, of course, it maintains some sort of stack, but the state of that stack is evident only through operations that implicitly change the values at the top of the stack and through reading the current top value.

Similarly, there is some logic associated with knowing when a sequence of digits typed by the user is a new number ready to put onto the stack, but this matters only to the UI code. We can see that things like typing an individual digit or pushing an enter button are not in themselves meaningful concepts in the domain, because they make a difference only when they result in pushing a new number onto the stack.

This structure would have been immediately obvious had there been separation between the domain model (probably a class with only three public methods plus constructor) and the UI code (with whatever state machine might be appropriate to handle the individual key presses). But because in Uncle Bob’s version there is just the one huge Register class trying to do everything with many tiny methods, there isn’t even this basic separation of concerns and the levels of abstraction are all mixed up.

"Refactoring Exercise" by Andrei Vajna

Tue, 23 Jun 2009 14:02:25 -0500

I took a quick look to the current solutions, and it seems mine is veeery close to Peter Bona’s.


abstract class Mode {
  public abstract Mode void take(Stack stack, int v);

  public static final Mode accumulating = new Mode() {
    private int calculatePowerOfTen(int v) {
      return (int)Math.pow(10, (int)Math.log10(v) + 1);
    }

    Mode void take(Stack stack, int v) {        
      int top = stack.pop();  
      stack.push(top * calculatePowerOfTen(v) + v);
      // i chose to use the temp because it's more explanatory this way
      // and because pop() has side effects and i don't want to include it
      // in an expression
      // but i could have easily written
      // stack.push(stack.pop() * calculatePowerOfTen(v) + v);
      // it would be the same regarding functionality
      // but i feel it's more readable this way
      return this;
    }
  };

  public static final Mode replacing = new Mode() {
    Mode void take(Stack stack, int v) {
      stack.pop();
      stack.push(v);
      return Mode.accumulating;
    }
  };

  public static final Mode inserting = new Mode() {
    Mode void take(Stack stack, int v) {
      stack.push(stack.peek());
      stack.push(v);
      return Mode.accumulating;
    }
  };
}

The originial take method becomes:


public void take(int v) {
  currentMode = currentMode.take(stack, v);
}

Mode is an implementation of the State pattern. I preffered your initial use of constans and also, I used annonymous classes for conciseness. You could as well have used proper classes, subclassed from Mode base class.

The difference from Peter’s solution are little readability refactorings, like eliminating on of the temps in the accumulating mode with a method.

Two points I’d like to make to your problem: you didn’t specify what the purpose of the refactoring is, so I could well say that the already implemented solution is fine as it is. And second, “using a few design patterns just because you can” is bad! :)

"Refactoring Exercise" by Luca Minudel

Sun, 21 Jun 2009 12:19:41 -0500

public void take(int v) {

currentMode.take(stack, v);
  currentMode = new CurrentModeAccumulating();

...

class CurrentModeAccumulating : ICurrentMode {...}

class CurrentModeReplacing : ICurrentMode {...}

class CurrentModeInserting : ICurrentMode {...}

"Refactoring Exercise" by Brett L. Schuchert

Tue, 16 Jun 2009 22:25:01 -0500

Chris wrote:

On the contrary, it is describing not what the function does but when it should be called in terms of specific user actions.

I think you are a bit off the mark. Ultimately, the underling facade supporting some user interface needs to have the ability to represent logical operations from the perspective of the user.

Sure, this is not always a 1-to-1 mapping (and in fact it should not be so most of the time). However, there is a difference between “entering the digits of the number” and “starting the next number”.

So some questions I might ask:

What are the logical interactions?
How many steps do I want to make explicit in the design of my facade layer?
How will one design impact multiple potential user interfaces?
Can that one facade server all, or is it easy enough to adapt to make it a reasonable abstraction?
Does the facade as designed preclude some kind of interaction?
...

Here is an example I came across on a project in 1997…

The project allowed flight rebookings on Palm 7’s, the web, WAP enabled phones and smart two-way pagers. It worked well, it was ready for use and it was in production (well it was in a beta sense).

Then along came a new 2-way pager that used SMTP as its communication between the pager and the base. The average response time was 1 minute. The minimum was 30 seconds and the max was 3+ minutes.

We had designed several logical steps to change a flight (end to end):

Go to a URL/bookmark
Log in
Review itineraries
Select itinerary to change
Indicate desired change (earlier/later)
Select one from a list of options
Accept change fees
Log out

Ignoring logout, that’s 7 steps. On this new device, that would, on average, require 7 minutes.

We had a conflicting requirement to make a system that was faster than making a phone call. 7 minutes was off the mark by several minutes.

So we had to adapt the underlying interaction. We left the underlying service as is but we developed an application for the two-way pager. This application maintained a cache of itineraries and credentials.

The new interaction was:

Start application (no time, no hit)
Select itinerary and indicate earlier or later booking (hit one)
Select from option
Accept change fees

This was considered too long (three minutes), so we made it even simpler:

Select itinerary and provide a window (2 – 4 hours earlier)
Auto select change fees if < $250

So this made it fast enough, but it took away too much from the experience and was rejected. We actually had to bring the manufacturer on site to tell them there really were no other options.

Why do I bring all of this up at all?

When you are building a system, a part of its design is user interaction. Part of that is designing a system that accommodates all of the points of interaction that make the best possible user experience, removing was is not necessary (or relegating it to an alternative).

In this case, enter() is the name given for the logical idea of completing input on one number.

Can this be removed? Yes. Can a calculator designed without this interaction work with many different user interfaces? Yes (I’ve done it). Does it map well to the domain? YES.

The HP calculators have been around since the late 60’s (see http://www.hpmuseum.org/

So to take it away in fact could make the underlying solution less close to the domain and in fact result in a worse solution.

One person’s intention is another person’s “specific user actions”.

Discussing the “enter” function is taking a phenomenological perspective, removing it and discussing “indication completion” is moving towards the ontological.

Context dictates one approach as “better” than another – at least for now.

"Refactoring Exercise" by Chris

Sun, 14 Jun 2009 17:46:43 -0500

@Philip Schwarz

The thing is, calling a function “enter” like that isn’t intention revealing. On the contrary, it is describing not what the function does but when it should be called in terms of specific user actions. There is a place for event handlers like that, but it’s in your user interface modules. Why is any code in an internal class like this even aware of what the nature of the user interface is, never mind referring to specific user actions?

Again, there is a not-seeing-wood-for-trees problem here. If we were to expand the scope of the problem to include the user interactions - which is far beyond what the original function covered and not a mere refactoring, of course - then we should be creating an internal class to model the stack behaviour with interface methods representing domain concepts such as pushing a number onto the stack, applying an operator and showing the current top of the stack, and we should also have separate code to handle UI quirks like parsing single keystrokes and evaluating when they become triggers for certain meaningful actions in the problem domain.

"Refactoring Exercise" by Philip Schwarz

Sun, 14 Jun 2009 17:10:09 -0500

@Chris

You said:

I could immediately guess what isEmpty would mean from the calling code, and while it is only a single line long, it does represent a useful abstraction. On the other hand, despite knowing the general problem area we’re discussing, I still don’t see why the names take, dup, enter and accumulate are particularly helpful here. take seems rather arbitrary: neither it nor the name Register provide enough context for it to be a meaningful concept without further information.

OK..so while you find ‘isEmpty’ to be intention-revealing, the same is not true for Uncle Bob’s one-line methods.

If you look back 11 posts from Uncle Bob’s, you’ll see Brett’s firts follow-up post, in which he says:

By the way, this is the beginnings of a method to handle input for an RPN calculator. Input is more complex than I first imagined:

Initially digits are accumulating.
After pressing enter, the next digit will replace the top of the stack (the x register) because pressing enter duplicated the current top.
After executing an operator, e.g., + – / * !, typing a digit duplicates the top of the stack (while another operator uses what’s there).

Based on that, the following is possible:

The accumulate method is called that way because it tells the Calculator to go into a state in which it accumulates digits.
The take method is called that way because it takes the user’s input to the calculator.
The Register class is called that way because the Calculator has a number of register, e.g. x.
The dup method maps to the problem domain (or system metaphor) concept of duplicating the top of a stack
The enter method maps to the problem domain concept of pressing the calculator’s enter button.

So Uncle Bob has created methods that map to problem-domain abstractions and are therefore intention-revealing to anyone who knows enough about the problem domain. To make the code readable, he has hidden code that tells us HOW the problem solution is implemented, behind code that models WHAT happens in the problem domain.

You seem (to me) to be saying that Uncle Bob’s one-line methods make the code harder to read because they are not intention-revealing (to you because you don’t know enough about the problem domain), so the code would be better off (more readable) if instead of telling you about WHAT happens in the problem domain, it just told you HOW the solution to the problem is implemented e.g. using stack operations.

I disagree. Uncle Bob has chunked implementation details and hid them behind intention-revealing method names, so that people who know enough about the problem domain (e.g. anyone intending to maintain the code) can read his code more quickly and accurately.

"Refactoring Exercise" by Chris

Sun, 14 Jun 2009 00:56:15 -0500

@Philip Schwarz

I think the code you cited is an excellent example of taking a good rule of thumb to such an absurd extreme that it breaks.

I am amused by the fact that the one function in the proposed rewrite that does do something actually does two things; the name even describes (with no useful abstraction whatsoever) what those two things are. If iteration and alternation violate the Sacred Principle of Oneness enough to justify separating everything inside any pair of {} then surely sequencing does as well? I’m mildly surprised that the person who wrote that originally hasn’t yet died of old age waiting for an infinite recursion to finish! :-/

The tragic thing is that while messing around with dogmatic changes to achieve small functions for no particular benefit, the author has missed the wood for the trees. The first question I would ask about the original function is why this code is messing around so much with the details of another object. Tell, don’t ask:

public void pay()
{
  for (Employee e : employees)
  {
    e.pay();
  }
}

and on the Employee class:

public void pay()
{
  if (isPayDay())
  {
    deliverPay(payDue());
  }
}

Then we might consider further improving the function names, but cleaning those up requires knowledge of the context that hasn’t been provided in this example, so there’s not much we can do beyond renaming the calculation function to something more appropriate given that its purpose is defined by the value it returns.

Of course, this whole example is very artificial, as it’s unlikely that in a real system an Employee object would know how to make a payment without depending on other parts of the system anyway…

"Refactoring Exercise" by Chris

Sat, 13 Jun 2009 22:59:14 -0500

@Philip Schwarz

We seem to be overlapping here because of some funny delays in posting, so I don’t know if you’d seen my earlier posts that already addressed some of your points when you wrote your latest contribution. I’ll just briefly comment on a couple of your other points for now.

On the subject of Composed Method:

Divide your program into methods that perform one identifiable task. Keep all of the operations in a method at the same level of abstraction. This will naturally result in programs with many small methods, each a few lines long.

The first two principles I completely agree with. This is basic functional decomposition advice that has been around since the programming stone age (though alas many professional developers seem to have forgotten it shortly afterwards in their quest to objectify this and higher level language that).

But I can’t agree with the conclusion. I’ve worked on code in several fields, from mathematical modelling to instrument control, where it would be perfectly possible to have a function dozens, perhaps even hundreds, of lines long that did represent a single task with the implementation at the same level of abstraction throughout. Usually the control flow would be quite linear, but subdividing the logic further would just be an artificial break.

In any case, as I mentioned before, my objection is not to small functions as such, just to small functions that don’t really gain us any useful abstraction. To wit, I see a marked contrast between your comments on the Intention Revealing Message pattern with the isEmpty example and Uncle Bob’s take function that you quoted. In particular, I could immediately guess what isEmpty would mean from the calling code, and while it is only a single line long, it does represent a useful abstraction.

On the other hand, despite knowing the general problem area we’re discussing, I still don’t see why the names take, dup, enter and accumulate are particularly helpful here. take seems rather arbitrary: neither it nor the name Register provide enough context for it to be a meaningful concept without further information. dup betrays the underlying implementation, while enter randomly obscures the implementation despite operating at the same level of abstraction. The worst is accumulate, which doesn’t accumulate anything at all, despite having a common meaning along those lines when applied to a sequence in computer science literature; it actually changes the mode (and apparently in a way that only code related to the Register class is permitted to do, though the analogous functions for setting other modes are public). In fact, looking over the entirety of Uncle Bob’s code again, it is littered with one-liners that are never actually used, yet betray implementation details or at best rename something without providing any additional abstraction.

In short, reading Uncle Bob’s take function, I would have had to look up every single function it called anyway, to drop to a useful level of abstraction and work out what the underlying logic was, completely defeating the point of factoring out the individual routines. However, to work out what other code interacted with the take function, I would also have to analyse all code with access to the same instance of Register because the numerous small, public functions effectively expose the implementation anyway. Whatever happened to “Tell, don’t ask”?

As for the small methods vs. increased interactions issue, I don’t have much to add there. A few consultants can repeat the mantra as often as they like, but the evidence simply doesn’t support their conclusion. Increasing complexity is definitely a causal factor in making code harder to understand; this much is well supported by research. Moreover, it seems likely that there is a positive correlation between function length and function complexity, but it doesn’t follow that small functions automatically help readability. It does follow, however, that if the functions get so small that the complexity starts to increase because of all the added interactions, this harms readability.