Комментарии 1
Немного мозговыносяще, потому что traits не являются шаблонным параметром CallData.
Самое первое и простое, что приходит в голову, это явное указание всех зависимостей в шаблонных параметрах класса:
Но их можно свернуть в один параметр:
Предложенный подход не нравится по двум причинам:
1. Очень сложно понимать код класса, если он зависит не только от шаблонных параметров, но и невесть где размещённых других объявлений.
2. А что если нужно будет протестировать код не с TestRequest, TestResponse, а с какими-нибудь реальными классами (NotTestRequest, NotTestResponse), но с необходимостью перегрузить зависимости (ServerCompletionQueue, ServerContext). А если при этом кто-то не понял, что трейты нужны только для unit-тестов и специализировал их для своих целей? То есть, где-то написал специализацию
Самое первое и простое, что приходит в голову, это явное указание всех зависимостей в шаблонных параметрах класса:
template <class Request, class Response, typename ServerCompletionQueue=grpc::ServerCompletionQueue, ServerContext=grpc:ServerContext>
class CallData {Но их можно свернуть в один параметр:
template <class Request, class Response, class CallDataTraits=DefaultCallDataTraits>
class CallData {Предложенный подход не нравится по двум причинам:
1. Очень сложно понимать код класса, если он зависит не только от шаблонных параметров, но и невесть где размещённых других объявлений.
2. А что если нужно будет протестировать код не с TestRequest, TestResponse, а с какими-нибудь реальными классами (NotTestRequest, NotTestResponse), но с необходимостью перегрузить зависимости (ServerCompletionQueue, ServerContext). А если при этом кто-то не понял, что трейты нужны только для unit-тестов и специализировал их для своих целей? То есть, где-то написал специализацию
CallDataTraits<CallData<NotTestRequest, NotTestResponse>>Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Юнит-тестирование шаблонов C++ и Mock Injection с помощью трейтов (Traits)