This is definitely subjective, but I'd like to try to avoid it becoming argumentative. I think it could be an interesting question if people treat it appropriately.
В нескольких своих недавних проектах я реализовывал архитектуры, в которых длинные цепочки делегирования являются обычным явлением.
Цепочки двойного делегирования встречаются очень часто :
bool Exists = Env->FileSystem->FileExists( "foo.txt" );
. И тройное делегирование вовсе не редкость :
Env->Renderer->GetCanvas()->TextStr(... );
. Цепочки делегирования высшего порядка существуют, но их очень мало.
В приведенных выше примерах проверки времени выполнения NULL -не выполняются, поскольку используемые объекты всегда присутствуют и жизненно важны для функционирования программы и явно создается при запуске выполнения. Обычно в таких случаях я разделял цепочку делегирования :
. 1)Я повторно использую объект, полученный через цепочку делегирования:
{ // make C invisible to the parent scope
clCanvas* C = Env->Renderer->GetCanvas();
C->TextStr(... );
C->TextStr(... );
C->TextStr(... );
}
2)Промежуточный объект где-то в середине цепочки делегирования должен быть проверен на NULL перед использованием. Например.
clCanvas* C = Env->Renderer->GetCanvas();
if ( C ) C->TextStr(... );
Я имел обыкновение бороться со случаем (2 ), предоставляя прокси-объекты, чтобы метод мог быть вызван для объекта, отличного от -NULL, что приводило к результату empty
.
Мои вопросы:
Вот некоторые плюсы и минусы, которые я учитывал при выборе:
Плюсы:
Минусы:
. Я хотел бы знать другие плюсы и минусы длинных цепочек делегирования. Пожалуйста, излагайте свои доводы и голосуйте, основываясь на том, насколько хорошо -аргументировано мнение, а не на том, насколько хорошо вы с ним согласны.