🔒 Locked
about classes
Advertisement
Original Post
I have three classes that should "comunicate"(the network class should send info to the console class and the simulation class and viceversa) and I'm not sure how should I proceed(I was thinking of making another class or a function that would handle the comunication between the classes). Thanks, Fevril.
If you wanted to make the sending class so it need not know about the end class, then you could write a class called classstream. This could act like a TCP stream socket and pass information between the two. You would have to pass an instance of both ends of the connection through the constructor ofcourse so that the connection can be established.
Dave
Dave
Your question is still a little bit vague.
Are the 3 objects all run by the same thread? Or even by different processes? Do they know of each other, and if so, do they know the class and/or object? Do you have the need to abstract the communication due to any other reason?
In principal, you could
(1) invoke methods directly, of course, if the objects know of each other, and the communication is already defined, relatively small, and fixed.
(2) encapsulate the communication in Event objects, and overhanding the events to more or less general event handler methods. So the objects doesn't need to know so much about each other as in (1), but you have to take looks at the type of event objects. However, this mechanism as also advantages if events needs to be stacked until they could be handled (e.g. but not necessarily due to overhanding between threads).
(3) do something like (2) but serialize the events/messages into streams if you want to go across a network.
If you're looking for design patterns, the keywords "chain of responsibility", "forwarder-receiver", "client-dispatcher-server", and "publisher-subscriber" may help. All these use the event/messaging mechanism in principle.
Are the 3 objects all run by the same thread? Or even by different processes? Do they know of each other, and if so, do they know the class and/or object? Do you have the need to abstract the communication due to any other reason?
In principal, you could
(1) invoke methods directly, of course, if the objects know of each other, and the communication is already defined, relatively small, and fixed.
(2) encapsulate the communication in Event objects, and overhanding the events to more or less general event handler methods. So the objects doesn't need to know so much about each other as in (1), but you have to take looks at the type of event objects. However, this mechanism as also advantages if events needs to be stacked until they could be handled (e.g. but not necessarily due to overhanding between threads).
(3) do something like (2) but serialize the events/messages into streams if you want to go across a network.
If you're looking for design patterns, the keywords "chain of responsibility", "forwarder-receiver", "client-dispatcher-server", and "publisher-subscriber" may help. All these use the event/messaging mechanism in principle.
the 3 objects are run by the same thread. To make it a little clearer I want to make something like this(but I don't know how to make them aware of each other)
class Network{...void OnData(std::string &s){ switch (s[0]) case chat: Console::Print(s); break; case move: Simulation::Move(s); break; }class Console{....void OnCommand(std::string &s){ switch(s[0]) case chat: Network::Send(s); break; case restart: Simulation::Restart(); break; }
I assume I'm mentioning some things below that are already known. There seems me no "golden way" to exist for the given problem, so the following is still something vague.
So you have a Network object as a source and sink, a Concole object as another source and sink, and a Simulation object as a model in the middle. Both sources need a dispatching mechanism to assign incoming messages to their respective target.
First, it may be senseful to have another protocol used by the Network than the one used by the Console. Say, the Console obviously communicates by using strings, and the one and only communication partner is the human player in front of the monitor. The Network, on the other hand, may be connected to more clients than just 1, and the data to be send by Network may mostly be others than what the Console handles. E.g. a map, the current position and action of 10 bots, and so on. So I would suggest to let the message interpretation be done by the respective source, i.e. the Network has to interpret the network messages, and the Console has to handle text input/output. As a consequence, the respective target of the action behind a message should provide a defined interface that could be invoked. (Btw: I don't see the need of "friend" declarations here, since the interface could be public.)
The code snippet you (Fevril) have posted above overhands the message in form of a string to the target object. This is a good idea in the sense to avoid to do programming the same thing twice, namely in both message dispatchers. However, as stated above, this way needs a message format to be the same regardless from which source they came. That hides the possibility for example to have a more compact format to be passed over the network. Your choice, but if you choose to use different formats, please let the particular format be handled locally only.
Next comes the question of how many instance of each of the classes will be involved. Your (Fevril) code snippet above shows static routines, letting me assume you have a single instance of each class. However, that seems me not to be suitable for the project. You have a Network to communicate with other instances of the game. So I assume you need to track the other players state at least on a central server, or else on each client if you do a decentral handling. Similarly there may be bots to be handled. So there is a need to have several Simulation instances (or else one Simulation instance but behind it a couple of SimulationClient instances, or whatever; however, that would shift the problem only, but not avoid it). So I expect you to need to dispatch the message's action furthur to different target objects, and hence static accesses may not be suitable. Since the count of targets could not be pre-determined, I expect the targets to have an ID and a mechanism like a map to find them by ID. Well, that kind of target dispatching could be done by a Simulation instance working as a facade, of course.
Whether the Simulation object should communicate directly with the Console and Network is another question. The situation _could_ be understood as a model-view-controller thing. In such a case the Simulation would not know the both others, or at least not directly but perhaps as general listeners interested in changes.
Due to the latency of networks, you may take into account to pass messages over the network in some kind of event structure (what means that the Network message format will differ from the one of the Console). That would allow to support stuff like priorities (defer or even drop less important messages) and message queuing.
So you have a Network object as a source and sink, a Concole object as another source and sink, and a Simulation object as a model in the middle. Both sources need a dispatching mechanism to assign incoming messages to their respective target.
First, it may be senseful to have another protocol used by the Network than the one used by the Console. Say, the Console obviously communicates by using strings, and the one and only communication partner is the human player in front of the monitor. The Network, on the other hand, may be connected to more clients than just 1, and the data to be send by Network may mostly be others than what the Console handles. E.g. a map, the current position and action of 10 bots, and so on. So I would suggest to let the message interpretation be done by the respective source, i.e. the Network has to interpret the network messages, and the Console has to handle text input/output. As a consequence, the respective target of the action behind a message should provide a defined interface that could be invoked. (Btw: I don't see the need of "friend" declarations here, since the interface could be public.)
The code snippet you (Fevril) have posted above overhands the message in form of a string to the target object. This is a good idea in the sense to avoid to do programming the same thing twice, namely in both message dispatchers. However, as stated above, this way needs a message format to be the same regardless from which source they came. That hides the possibility for example to have a more compact format to be passed over the network. Your choice, but if you choose to use different formats, please let the particular format be handled locally only.
Next comes the question of how many instance of each of the classes will be involved. Your (Fevril) code snippet above shows static routines, letting me assume you have a single instance of each class. However, that seems me not to be suitable for the project. You have a Network to communicate with other instances of the game. So I assume you need to track the other players state at least on a central server, or else on each client if you do a decentral handling. Similarly there may be bots to be handled. So there is a need to have several Simulation instances (or else one Simulation instance but behind it a couple of SimulationClient instances, or whatever; however, that would shift the problem only, but not avoid it). So I expect you to need to dispatch the message's action furthur to different target objects, and hence static accesses may not be suitable. Since the count of targets could not be pre-determined, I expect the targets to have an ID and a mechanism like a map to find them by ID. Well, that kind of target dispatching could be done by a Simulation instance working as a facade, of course.
Whether the Simulation object should communicate directly with the Console and Network is another question. The situation _could_ be understood as a model-view-controller thing. In such a case the Simulation would not know the both others, or at least not directly but perhaps as general listeners interested in changes.
Due to the latency of networks, you may take into account to pass messages over the network in some kind of event structure (what means that the Network message format will differ from the one of the Console). That would allow to support stuff like priorities (defer or even drop less important messages) and message queuing.
Topic Locked
This topic has been locked by a moderator. New replies are not allowed.
Sign in to reply to this topic.
Advertisement