Python – Pattern for subclass overload with different arguments

asyncdesign-patternsliskov-substitutionpythonpython-3.x

I'm in the process of writing an bidirectional, asynchronous socket server and server handler. The base handler class I'm working off of is as follows:

class BaseAsyncSocketHandler:
    async def send(self, data: bytes) -> int

However, I want to write a subclass that sends two arguments, an event and arbitrary corresponding data, which suggests the signature:

   async def send(self, event: str, data: object) -> int:
       return await super().send(event_data_magic_to_bytes(event, data))

Unfortunately, this violates the Liskov substitution principle, and I don't think writing it as a mixin will makes the situation any better, so I'm hoping somebody has either seen this before or can think of a better design pattern (or tell me this is an unnecessary abstraction in the first place).

Best Answer

In the end, I settled on providing the following:

class BaseAsyncSocketHandler:

    async def _send(self, data: bytes) -> int:
        ...

    @abc.abstractmethod
    async def send(self, *args, **kwargs) -> int:
        pass

This way the user can implement subsets of the send method while using the base send method provided by the socket wrapper. As to why I wanted to use send instead of just creating another class method like send_event, I think I mostly just wanted the interface to the class to remain compact and usable while allowing for different socket methodologies.

Related Solutions

C++ – Mailbox Pattern with Variable Arguments in C++

Instead of using an array, you could use a vector<EventClass> (where EventClass is whatever type your current array is). Then you could just iterate through the vector and process each event until it's empty, assuming the GUI thread won't be adding events while the simulation thread is processing them (this could be achieved with mutexes of some kind)... You'd then only have to process active events, since the vector would only contain events that have happened. It could work like so:

class EventClass {
    EventClass(int _o, string _d) : opcode(_o), data(_d) {}
    int opcode;
    string data;
}
//somewhere available to both threads, declare the vector:
vector<EventClass> ActiveEvents;

void GUI_Process_Events(){
    //...
    ActiveEvents.push_back(The_Event_That_Just_Happened);
}

void Simulation_Process_Events(){
    //this will iterate through all the active events and
    //act on each of them
    for(int i = 0; i < ActiveEvents.size(); i++){
        //this gets the item at the back of the vector
        EventClass Current_Event = ActiveEvents.back();

        //assuming Process(EventClass e) will process the event
        Process(Current_Event);

        //this will then remove the event from the vector
        ActiveEvents.pop_back();
    }
}

If necessary, you could use a vector of pointers to EventClass objects (but then of course you must destroy them as well):

class EventClass {
    EventClass(int _o, string _d) : opcode(_o), data(_d) {}
    int opcode;
    string data;
}
//somewhere available to both threads, declare the vector:
vector<EventClass*> ActiveEvents;

void GUI_Process_Events(){
    //...
    ActiveEvents.push_back(PointerTo_The_Event_That_Just_Happened);
}

void Simulation_Process_Events(){
    //this will iterate through all the active events and
    //act on each of them
    for(int i = 0; i < ActiveEvents.size(); i++){
        //this gets the item at the back of the vector
        EventClass* Current_Event = ActiveEvents.back();

        //assuming Process(EventClass e) will process the event
        Process(Current_Event);

        //delete the object pointed to by the element in the vector
        delete Current_Event;

        //this will then remove the event from the vector
        ActiveEvents.pop_back();
    }
}

ASP.NET MVC – Real Advantages of Async Controllers

ASP.Net that does not use the Task Parallel Library (TPL) is limited in the number of requests it can handle concurrently by the number of threads in a thread pool. ASP.Net that uses the TPL is limited by the CPU/memory/IO of the machine handling requests.

The Task Parallel Library (TPL) does not consume threads in the way you seem to think it does. Tasks are not threads, they are a wrapper around some unit of computation. The task scheduler is responsible for executing each task on any thread that is not busy. At runtime, awaiting a task does not block the thread, it merely parks the execution state so that it may proceed at a later time.

Normally, a single HTTP request would be handled by a single thread, completely removing that thread from the pool until a response is returned. With the TPL, you are not bound by this constraint. Any request that come in starts a continuation with each unit of computation required to calculate a response able to execute on any thread in the pool. With this model, you can handle many more concurrent requests than with standard ASP.Net.

Best Answer

Related Solutions

C++ – Mailbox Pattern with Variable Arguments in C++

ASP.NET MVC – Real Advantages of Async Controllers

Related Topic