0

Below is the design, that is implemented similar to design used in Linux/net/socket.c.

Below design provide List abstraction,

enter image description here

where, list.h provides List interface, show here

Background:

Reason to implement List abstraction in this approach is to consider as a prototype inspired from Linux/net/socket.c design, where any one of the multiple protocol family implementations(like net/ipv4/af_inet.c or 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 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??

overexchange
  • 2,245
  • 2
  • 17
  • 47
  • Don't use a global variable for handler. Store hander as a list member. – Basilevs Jan 09 '17 at 04:59
  • @Basilevs OK. So, if its is non-global, then every client should pass `ImplType` ( `enum {ARRAY_IMPL, LINKD_LIST_IMPL}ImplType`) to pick their implementation, which makes code cumbersome and not good abstraction – overexchange Jan 09 '17 at 05:01
  • No, as list instance would incapsulate it's type – Basilevs Jan 09 '17 at 05:02
  • @Basilevs As you said, `List` instance can encapsulate `ImplType`. But If `List` type maintains information about `ImplType`, then how would `virtualImplLayer.c` would know the details of `List` type sitting in `arrayImpl.c`/`linkListImpl.c`? `List` type details are hidden from `virtualImplLayer.c`. If details are exposed, then it is bad abstraction – overexchange Jan 09 '17 at 05:04
  • It only needs to know about handler field. If this field is first in the structure, exact structure of other fields is irrelevant. Use first few fields of your list to carry type information. Make them mandatory for all list kinds. – Basilevs Jan 09 '17 at 05:07
  • http://stackoverflow.com/q/1114349/125562 see C inheritance – Basilevs Jan 09 '17 at 05:08

1 Answers1

2

You are trying to implement a virtual table. See how it's done in https://stackoverflow.com/q/3113583/125562

Basic idea is to store all methods required to interact with a structure as its fields.

There are other examples. Google C vtable.

Community
  • 1
Basilevs
  • 1,221
  • 9
  • 11
  • If I make `ListImplType` available in `listHandler.h` that instance is populated in every implementation(in the beginning). Do I need to invoke `findImplType()` in `virtualImplLayer.c`? But which implementation to call? `virtualImplLayer.c` has no info about it – overexchange Jan 09 '17 at 05:39
  • You are asking for implementation details here. Please see linked question for them. They are off-topic for this site. You don't need to find any type information, because it is immediately available in the object's first field. – Basilevs Jan 09 '17 at 05:42
  • Only createList() interface is receiving impltype information from the client program. How can other interface know the impltype? – overexchange Jan 09 '17 at 06:55
  • It is accessible as structure field. – Basilevs Jan 09 '17 at 07:31
  • Yes but only for on e interface – overexchange Jan 09 '17 at 14:52
  • Yes, one interface, arbitrary number of implementations. Implementation would know specifics of data structure and handle operations in a type dependent way. Client would call interface methods to invoke implementation. This way, client code would be unaware of concrete implementation, but can use the object nevertheless. Do you want another kind of type information? – Basilevs Jan 09 '17 at 14:58
  • Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/51448/discussion-between-overexchange-and-basilevs). – overexchange Jan 09 '17 at 16:08
  • Am still not clear, how the link that talks about vtable implementation in your answer solve the problem? – overexchange Jan 11 '17 at 13:16