C++ – How to Resolve Class Interdependence

cclassclass-design

In my C++ project, I have two classes, Particle and Contact. In the Particle class, I have a member variable std::vector<Contact> contacts which contains all contacts of a Particle object, and corresponding member functions getContacts() and addContact(Contact cont). Thus, in "Particle.h", I include "Contact.h".

In the Contact class, I would like to add code to the constructor for Contact that will call Particle::addContact(Contact cont), so that contacts is updated for both the Particle objects between which the Contact object is being added. Thus, I would have to include "Particle.h" in "Contact.cpp".

My question is whether or not this is acceptable/good coding practice and, if not, what would be a better way to implement what I am trying to achieve (simply put, automatically updating the list of contacts for a specific particle whenever a new contact is created).

These classes will be tied together by a Network class that will have N particles (std::vector<Particle> particles) and Nc contacts (std::vector<Contact> contacts). But I wanted to be able to have functions like particles[0].getContacts() – is it okay to have such functions in the Particle class in this case, or is there a better association "structure" in C++ for this purpose (of two related classes being used in another class).

I may need a perspective shift here in how I am approaching this. Since the two classes are connected by a Network class object, is it typical code/class organization to have connectivity information entirely controlled by the Network object (in that a Particle object should not be aware of its contacts and, consequently, it should not have a getContacts() member function). Then, in order to know what contacts a specific particle has, I would need to obtain that information through the Network object (e.g., using network.getContacts(Particle particle)).

Would it be less typical (perhaps even discouraged) C++ class design for a Particle object to have that knowledge, as well (i.e., have multiple ways to access that information — through either the Network object or the Particle object, whichever seems more convenient)?

Best Answer

There are two parts in your question.

The first part is the organization of C++ header files and source files. This is solved by using forward declaration and the separation of the class declaration (putting them in the header file) and method body (putting them in the source file). Furthermore, in some cases one can apply the Pimpl idiom ("pointer to implementation") to solve harder cases. Use shared-ownership pointers (shared_ptr), single-ownership pointers (unique_ptr), and non-owning pointers (raw pointer, i.e. the "asterisk") according to best practices.

The second part is how to model objects that are inter-related in the form of a graph. General graphs that are not DAGs (directed acyclic graphs) don't have a natural way of expressing tree-like ownership. Instead, the nodes and connections are all metadata that belong to a single graph object. In this case, it is not possible to model the node-connection relationship as aggregations. Nodes don't "own" connections; connections don't "own" nodes. Instead, they are associations, and both nodes and connections are "owned by" the graph. The graph provides query and manipulation methods that operate on the nodes and connections.

Related Solutions

C++ Data Structures – Modeling a Network of Nodes and Edges

Graphs can be implemented in many ways, and the one you've outlined is certainly not wrong.

For C++ I think you should take a gander into the Boost C++ libraries (BGL) that also has a library specifically for implementing graphs. If you use that then you can also use algorithms implemented in BGL (searches and traversals) or even use the _edge and _vertex visitors directly.

C++ – How to store various sized values in a vector

Firstly, command classes are decoupled from the medium and protocol. That means you can design the command classes for your own programming convenience, rather than having to design it to match exactly to the specifics of each protocol (which would be impossible, since different protocols may have different bit widths for the same command and field).

When I mention convenience, what I mean is that you can use the maximum bit width you'll ever need for each command's fields.

However, you may still need to have device- or protocol-specific validation code, since each device or protocol imposes its own limits to what values can be in those fields. Unless you don't plan to implement any validation at all.

When it comes to validation, there are several choices:

Not doing it at all, if you will be doing all of the programming yourself, and if it is a hobby project such that mistakes do not result in damages.
Validating it eagerly, i.e. in the command class. This may be difficult, since a command class might not know which device or protocol it will be sent to.
Validating it late, i.e. in the protocol class where the command values are being converted into bytes.

For example, even if a validation rule says that a particular field can only have a value in the range 0 - 100, it doesn't stop you from using a uint32_t or int32_t for that field in the command class.

To the second question of having an overloaded method that takes in various built-in number types and append the bytes to an internal byte vector, do notice the caveats.

In my opinion, if you only needs to work with the fundamental integer types, you don't need templates. Instead, you simply provide function overloads for each of the types, and you call the functions with a value of the appropriate type.

void CPacket::addData(uint32_t data) { ... }
void CPacket::addData(int32_t data) { ... }
void CPacket::addData(uint16_t data) { ... }
void CPacket::addData(int16_t data) { ... }
...

Regarding the code inside, there are several choices:

Type punning with union. This assumes that your code will work exclusively with one byte-endianness, thus not needing to consider the possibility of porting to a different byte-endianness.

union
{
    uint32_t value;
    uint8_t bytes[4];
} pun = { data };
// after that, add the bytes to the vector one-by-one, according to the byte endianness of the communication.

Explicitly extracting the bytes with endian-agnostic bitwise arithmetic: (see note on casting)

// only if value is unsigned. For signed value, it must first be cast to unsigned
uint8_t byte0 = (uint8_t)value;
uint8_t byte1 = (uint8_t)(value >> 8ul);
uint8_t byte2 = (uint8_t)(value >> 16ul);
uint8_t byte3 = (uint8_t)(value >> 24ul);

Best Answer

Related Solutions

C++ Data Structures – Modeling a Network of Nodes and Edges

C++ – How to store various sized values in a vector

Related Topic