Use observer mode to design the simulator kernel interface

In JDF circuit simulation software, the simulator kernel is the core module of the simulation software, and the functions of other modules are built on this basis, that is, they all rely on the analysis of the simulator. These modules include circuit diagram editing environment, command processor, event logging, and automated testing framework. This is a typical "many-to-one" dependency. When the simulator runs in the corresponding state, it must update other modules dependent on it to maintain the consistency of the entire system status. The observer pattern in the gof23 design pattern is a good way to process this relationship. The design of the external interface of the simulator is completed in the Observer mode. The advantage of using the observer mode is that it increases the flexibility and scalability of the system. In the future, even if a new functional module needs to use the functions of the simulator, the core of the simulator can be kept unchanged.ProgramAdd the new module to the system dynamically. The relationship between the simulator object and other functional module objects.

Here, the simulator is used as the main object (subject), and all peripheral modules that need to use the simulation analysis results are used as different observer objects (observer ), the simulator implementation class simulator implements the three methods in the subject interface (notify, attach, detach), and all the observer module objects implement the update method of the observer interface. All observer objects are registered on the simulator object through the data connection mechanism. After the simulator analyzes the circuit, it records event-related information in an eventrecord message structure and calls the update method of the registered observer object in sequence, eventrecord is passed as a parameter to each peripheral module. After receiving an update message from the simulator, the peripheral module processes the message based on the message content and its own functions, the user interface module changes the display interface of the circuit diagram to intuitively display the current status of the circuit. The command operation module records the relevant information for Undo/Redo operations, the event logging module records the event content in the log file. The automated verification framework compares the event content with the expected results to determine whether the circuit design meets the requirements.
PS. When I looked at the ObjectARX framework today, I found that the API design of AutoCAD also uses a similar mechanism for processing ~~