Databases
StackOverflow2013
Postsdbo
POInheritance hierarchy vs. multiple inheritance (C++)
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POInheritance hierarchy vs. multiple inheritance (C++)
    primarykey
    data
    text
    <p>Well, I was thinking about a design decision for the past few days and since I still cannot favor one over the other I thought maybe someone else has an idea.</p> <p>The situation is the following: I have a couple of different interface classes abstracting several communication devices. Since those devices differ in their nature they also differ in the interface and thus are not really related. Lets call them <strong>IFooDevice</strong> and <strong>IBarDevice</strong>. More device types may be added over time. The language is C++.</p> <p>Since other components (called clients from now on) might want to use one or more of those devices, I decided to provide a <strong>DeviceManager</strong> class to handle access to all available devices at runtime. Since the number of device types might increase, I would like to treat all devices equally (from the managers point of view). However, clients will request a certain device type (or devices based on some properties).</p> <p>I thought of two possible solutions:</p> <p>The first would be some kind of interitance hierarchy. All devices would subclass a common interface <strong>IDevice</strong> which would provide the (virtual) methods necessary for management and device query (like <em>getProperties()</em>, <em>hasProperties()</em>, ...). The <strong>DeviceManager</strong> then has a collection of pointers to <strong>IDevice</strong> and at some point a cast from <em>Base</em> to <em>Derived</em> would be necessary - either with a template method in the manager or after the request on the client's side. </p> <p>From a design point of view, I think it would be more elegant to seperate the concerns of managing a device and the interface of the specific device itself. Thus it would lead to two unrelated interfaces: <strong>IManagedDevice</strong> and e.g. <strong>IFooDevice</strong>. A real device would need to inherit from both in order to "be" of a specific device type and to be managaeble. The manager would only manage pointers to <strong>IManagedDevice</strong>. However, at some point there will be the need to cast between now unrelated classes (e.g. from <strong>IManagedDevice</strong> to <strong>IFooDevice</strong>) if a client wants to use a device provided by the manager.</p> <p>Do I have to choose the lesser of two evils here? And if so which one would it be? Or do I miss something? </p> <p><strong>Edit:</strong></p> <p>About the "managing" part. The idea is to have library providing a variety of communication devices different (client) applications can use and share. Managing merely comes down to the storage of instances, methods for registering a new device and looking up a certain device. The responsibility for choosing the "right" device for the task is up to the client side because it knows best which requirements it puts on the communication. In order to reuse and thus share available devices (and by that I mean real instances and not just classes) I need a central access point to all available devices. I'm not too fond of the manager itself but it's the only thing I could come up to in that case.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PTQuestion
    1. USBenjamin
    1. USrocktale
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    3. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POInheritance hierarchy vs. multiple inheritance (C++)
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POInheritance hierarchy vs. multiple inheritance (C++)
      1. USfouronnes
      1. VTFavorite
    3. VO
      singulars
      1. POInheritance hierarchy vs. multiple inheritance (C++)
      1. This table or related slice is empty.
      1. VTUpMod
    1. COWhy do you need to "manage" your devices in the first place? If they have nothing in common, why is there a class whose responsibility it is to "manage" them all? For that matter, what managing needs to be done? You're playing architecture astronaut ( http://www.joelonsoftware.com/articles/fog0000000018.html ). What does it mean to "manage" a device? What devices do you actually have, and what, if anything, do they have in common? If I need a DeviceX, and DeviceX has a different interface from DeviceY, then why would I go talk to a AllSortsOfDevicesManager?
      singulars
      1. POInheritance hierarchy vs. multiple inheritance (C++)
      1. USjalf
    2. COWhy can't I just be given the DeviceX that I'm supposed to work with?
      singulars
      1. POInheritance hierarchy vs. multiple inheritance (C++)
      1. USjalf
    3. COThanks for the article on architecture astronauts. There's a good deal of thruth in there. However, I added a little explanation about what managing needs to be done and why I chose a manager in the first place.
      singulars
      1. POInheritance hierarchy vs. multiple inheritance (C++)
      1. USrocktale
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload