Discussion on: Non isomorphic C++ refactoring

[Greg Bodnar]

I enjoyed reading through your thought process, but I'm wondering about checkAvailableRoom(). There seems to be no consequence to this check and, on fact, no way to use the result. I'm assuming it's just irrelevant to the point you're making, but if it resembles actual code, you might have something to look into...

[Dimitri Merejkowsky]

Short version:

In the code I had in mind, checkAvailableRoom() just threw when
the safe is full. But you are correct, it's not obvious it does anything at all. I'll update the article, thanks.

Long version:

You see, the first version of the article looked like this:

void doSomething() {
  Foo foo;
  foo.one();

  Bar bar;
  bar.two()
}

Then the code would have changed to:

void doFoo() {
  Foo foo;
  foo.one();
}

void doBar() {
  Bar bar;
  bar.two();
}
void doSomething() {
  doFoo();
  doBar();
}

and then I would explain how the two versions were different in some subtle ways, the destructor of Foo() now being called after bar.two()

But:

1/ The example was a bit abstract
2/ The mistake was a bit obvious to spot

So basically the first part of the original blog is a big smoke screen to make you forget about the fact that Door.close() is called in ~Door destructor: checkAvailableRoom() is just yet anther element of the smoke screen.

3/ I wanted to show a bit of realistic refactoring too.