Note: The use of this wrapper in particular is especially discouraged.
Most code should not need to access the request directly. Doing so
means it will only function when handling an HTTP request, and will
require special modification or wrapping when run from a command line
tool, from certain queue processors, or from automated tests.

If code must access the request, it is considerably better to register
an object with the Service Container and give it a setRequest() method
that is configured to run when the service is created. That way, the
correct request object can always be provided by the container and the
service can still be unit tested.

If this method must be used, never save the request object that is
returned. Doing so may lead to inconsistencies as the request object
is volatile and may change at various times, such as during a
subrequest.

I have a custom module and I have a service, is it possible to implement it in a service?

My question is according to the comment and recommendation of the API, how is it that it should be implemented?

The ViewExecutable class follows that pattern. The factory service (ViewExecutableFactory) instantiates a View object based on the current HTTP request (from the injected request_stack service), and passes it through to the View. I would go with that approach
– Clive♦Oct 17 '18 at 15:19