Below is the design, that is implemented similar to design used in
Below design provide
List interface, show here
Reason to implement
Listabstraction in this approach is to consider as a prototype inspired from
Linux/net/socket.cdesign, where any one of the multiple protocol family implementations(like
net/unix/af_unix.c/..) is available on invoking
socket(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
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.
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
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??