loading...

re: Non isomorphic C++ refactoring VIEW POST

TOP OF THREAD FULL DISCUSSION
re: I enjoyed reading through your thought process, but I'm wondering about checkAvailableRoom(). There seems to be no consequence to this check and, o...
 

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.

Code of Conduct Report abuse