Below is the design, that is implemented similar to design used in Linux/net/socket.c.
Below design provide List abstraction,
where, list.h provides List interface, show here
Background:
Reason to implement
Listabstraction in this approach is to consider as a prototype inspired fromLinux/net/socket.cdesign, where any one of the multiple protocol family implementations(likenet/ipv4/af_inet.cornet/unix/af_unix.c/..) is available on invokingsocket(AF_INET | AF_UNIX | AF_XYZ,,)api.This prototype would help understand implementing snmp library that talks to multiple network elements(Router/Switch/Server) using snmp protocol.
Above design(shown in above image) is an analogy to Linux/net/socket.cas shown in this code here with a slight difference in linking time(linker phase) unlike linking implementations in Linux/net/socket.c happens at loading phase by overriding _init() run-time code in implementation(say af_inet.c) and invoking sock_register()
To further improve this analogy,
Am thinking on improving design(shown in above image), that can allow createList(ARRAY_IMPL) get called from fileIO/fileReading.c(for its own purpose) and createList(LINKED_LIST_IMPL) get called from ST/implUsingList.c(for its own purpose).
With current design(shown in above image), it breaks the purpose, as it works with any one implementation(say arrayImpl.c) linked at linker phase.
Reason: ListHandler *handler = NULL; is global variable defined in virtualImplLayer.cand gets over-ridden on every call to createList(ImplType), as shown in this code here
My question:
How to enhance this prototype design to pick multiple implementations for client scenario(shown in image)? Does it require multi-threading at virtual implementation layer??
