- Forum
- General C++ Programming
- Error Code Design
Error Code Design
I have been over-thinking and going in circles for a design aspect of a system, so I figured some forum advice will get me back on track!
I have many objects that are being simulated in a system. For simplicity, let's just say they are Valves, Pumps, and Motors. Originally, each class stored its own set of specific errors and error logic (failure to open/close, command mismatch, loss of pressure/voltage).
However I'm now beginning to see a growing trend. All of my errors for every object can be "acknowledged" by the operator. Also, for modularity, I would hate to keep all of my errors locked down without an easy way to add new ones except by extending the class.
I considered the Decorator pattern for all of my errors, but the problem is that each error will now need a concrete class of its own and that seems monumental, though it certainly is very modular. Also, each error will need to be evaluated using the current state of the attached object (valve errors will need to know about the valve), but since the object will merely store the attached list of associated errors, it will have to consistently evaluate it's entire list. This sounds computationally expensive compared to when the object controlled the logic and could evaluate the errors only when necessary (only check pressure error when the pressure changes).
Is there another design pattern I could use, or is this an example of when you must suffer through the disadvantages of a design decision? I seem to either be duplicating the logic of how errors and acknowledgements work, or having to instantiate an exceedingly large number of concrete classes that will be slower and cumbersome to work with. Is there a middle ground?
I have many objects that are being simulated in a system. For simplicity, let's just say they are Valves, Pumps, and Motors. Originally, each class stored its own set of specific errors and error logic (failure to open/close, command mismatch, loss of pressure/voltage).
However I'm now beginning to see a growing trend. All of my errors for every object can be "acknowledged" by the operator. Also, for modularity, I would hate to keep all of my errors locked down without an easy way to add new ones except by extending the class.
I considered the Decorator pattern for all of my errors, but the problem is that each error will now need a concrete class of its own and that seems monumental, though it certainly is very modular. Also, each error will need to be evaluated using the current state of the attached object (valve errors will need to know about the valve), but since the object will merely store the attached list of associated errors, it will have to consistently evaluate it's entire list. This sounds computationally expensive compared to when the object controlled the logic and could evaluate the errors only when necessary (only check pressure error when the pressure changes).
Is there another design pattern I could use, or is this an example of when you must suffer through the disadvantages of a design decision? I seem to either be duplicating the logic of how errors and acknowledgements work, or having to instantiate an exceedingly large number of concrete classes that will be slower and cumbersome to work with. Is there a middle ground?
Ideally, your design should be such that errors cannot occur in the first place. How are you expecting to encounter errors in a simulation?
Don't try to find the best way to to part 2 if you haven't found the best way to do part 1 yet.
Don't try to find the best way to to part 2 if you haven't found the best way to do part 1 yet.
Ha, I wasn't expecting that. I was not being specific enough and I apologize.
These are simulated errors. An instructor purposefully simulates a fault in a system to test the student and grade their response performance. This is why all errors can be acknowledged. An acknowledgement means that the student pushed the "Acknowledge Errors" button, and then began trying to perform the proper response.
A simplified example is the Bilge pump. An error is enunciated when the bilge tank level switch detects high water levels. The student should acknowledge this alarm and open the correct valves in order to properly bilge to the overboard discharge line and then turn on the bilge pump.
These are simulated errors. An instructor purposefully simulates a fault in a system to test the student and grade their response performance. This is why all errors can be acknowledged. An acknowledgement means that the student pushed the "Acknowledge Errors" button, and then began trying to perform the proper response.
A simplified example is the Bilge pump. An error is enunciated when the bilge tank level switch detects high water levels. The student should acknowledge this alarm and open the correct valves in order to properly bilge to the overboard discharge line and then turn on the bilge pump.
I have, but an event system would also be monumental because I would now need to create an event for EVERY possible variable in my simulated system. The types of object failures being simulated can certainly be driven off of any data set within the object. This is no small task either with very little payoff for now (but a good deal of payoff in modular OO design, which can sometimes be worth it).
Topic archived. No new replies allowed.