Question

Look at this code:

#include <framework_i_hate.h>
int main() {
  XFile file("./my_file.xxxx", "create");
  XObject object("my_object");
  // modify the object
  object.Write();
}

Try to guess where object will be saved... yes, you guessed it. I think this is too magic, I d like to write something like object.Save(file), but it s not necessary. Obviously there is global variable inside framework_i_hate.h that it is modified during the file constructor. What do you think about this side effect inside constructor?

How can this behavior be hidden?

A bonus to who guess the framework.

Answer 1

Very muddled hard to understand post and the question in the end is very rhetorical. Global variables are evil, what else to add?

Answer 2

What can be said about this that isn t already obvious enough: It s a fairly nasty side effect, because:

the resulting behaviour is unexpected and not predictable at all, unless you know that framework well.
global program state usually isn t a good idea in object-oriented programming. (In fact, global state is probably never a good idea, so best avoid it if you can.)
it s fairly likely that this framework isn t thread-safe, either. (Think about what happens when two concurrent threads both create an XFile object each, and one of these threads then writes an XObject... where will it end up being saved?)

While this thread is tagged C++ and not about .NET, I have seen this "anti-pattern" before in a less severe and much more sane form, namely with DB transaction scopes.

Answer 3

I d prefer to see the relationship between XFile and XObject be explicit, I agree that this "magic" is too well hidden. I also question why the object is given a name, unless there are other parts of the API where the name is significant.

Global variables are despised for many reasons, this is just one example.

友情链接