I want to extend an existing application with a simple REST server and a dedicated UDP client for streaming data to a UDP server. The REST server should manage the UDP client based on the API requests and have access to classes in the hosting application.
I want to create a new class in the hosting application so I can have access to the data.
I saw Poco::Net::HTTPServer and it seems a good candidate. I want to start and stop HTTPServer from that class methods.
Thing is, this class should know of the API requests types so that it can react accordingly.
Is it a good practice to inherit HTTPServer and extend it with the above behavior (that way I may have simple access to the requests)?
Or should it only be a member of the main class?
I also thought of POCO events/notifications but not sure if it is a good idea or how to subscribe my new class to events from different short-living objects (of class HTTPRequestHandler), or to events from the HTTPRequestHandlerFactory object (which HTTPServer owns upon creation).
P.S.
The new REST server and UDP socket should serv a single connection. Also, the expected frequency of API requests is very low.
Any help or alternative ideas are highly appreciated!
Is it a good practice to inherit HTTPServer and extend it with the above behavior (that way I may have simple access to the requests)?
I don't recommend that. Create a standalone class, hold a reference to it in the request handler factory, pass the reference to each request handler, and do the required work at the request handling time.
As for using notifications, from the description it sounds like simply calling back your new object methods from request handlers would do the job. But perhaps having a NotificationQueue in the new class and process notifications in a separate thread would make sense.