внешний побочный эффект в конструкторе

Question

Посмотрите на этот код:

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

Попробуйте угадать, где будет сохранен object ... да, вы уже догадались.Я думаю, что это слишком волшебно, я хотел бы написать что-то вроде object.Save(file), но это не обязательно.Очевидно, что внутри framework_i_hate.h есть глобальная переменная, которая модифицируется во время конструктора file.Что вы думаете об этом побочном эффекте внутри конструктора?

Как можно скрыть это поведение?

Бонус тому, кто угадывает структуру.

Answer 1

Очень запутанный, трудный для понимания пост, и вопрос в конце очень риторический.Глобальные переменные - зло, что еще добавить?

Answer 2

Что можно сказать по этому поводу, что еще недостаточно очевидно: это довольно неприятный побочный эффект, потому что:

• получающееся поведение является неожиданным и непредсказуемым, если тольковы хорошо знаете этот фреймворк.

• глобальное состояние программы обычно не очень хорошая идея в объектно-ориентированном программировании.(На самом деле, глобальное состояние, вероятно, никогда не является хорошей идеей, поэтому лучше избегайте его, если можете.)

• вполне вероятно, что эта среда также не является поточно-ориентированной.(Подумайте о том, что происходит, когда два одновременно работающих потока создают каждый объект XFile, и один из этих потоков затем записывает XObject ... где это будет сохранено?)

Хотя этот поток помечен как C ++, а не как .NET, я видел этот «анти-шаблон» ранее в менее серьезной и гораздо более разумной форме, а именно с областями транзакций БД.

Answer 3

Я бы предпочел, чтобы отношения между XFile и XObject были явными, я согласен, что эта «магия» слишком хорошо скрыта. Я также спрашиваю, почему объекту присваивается имя, если в API нет других частей, где имя является значимым.

Глобальные переменные презираются по многим причинам, это только один пример.