21.4. Explain why an object-oriented approach to software development may not be suitable for real-time systems
Objects require instantiation, eat up memory while they’re sitting there (potentially not being used), and because they are self-contained, may internally contain duplicate code or features. All of these traits lead to bloat; bloat interferes with speed/efficiency, and speed is essential to a real-time application.
-
With a constantly-running real-time system, an object that is instanciated and not used wastes memory & energy maintaining its state. This degrades efficiency & speed; wastes energy, and could lead to failure by failing to react quickly enough.
-
Objects also are very strict in their interaction rules; this might lead to an overly limited framework which limits the theoretical reactivity of your system. Moreover, if you want concurrency with objects, you would need to instantiate multiple duplicate objects; this is a massive waste of resources.
-
Objects fill real memory space, placing additional restrictions on the hardware range capable of acceptably running this system.
-
Objects represent an additional layer of abstraction. While this may make code easier to write & understand, it also means a pontentially time-costly additional step in communication between the input, calculation, and output. Moreover, objects often follow the black-box approach; hiding interal attributes which delays the system accessing those values.
-
Finally, The more functionality placed into an object, the more features fail if the object fail. Objects might reduce the robustness of a real-time system for this very reason.
For all these reasons, object-oriented is not a good real-time approach