For embedded systems, the consensus seems to indicate that there are no clear advantages of Object-Oriented Programming (OOP) over procedural programming; especially, if we consider concrete embedded applications. OOP is well equipped for applications that require high levels of abstraction and have high variability. GUIs and desktop applications like the one I’m using now are of that kind. Nonetheless, many embedded systems are very concrete, complex but concrete–complex on the nature of the algorithms that are implemented, but concrete on the application itself. The levels of abstraction are lower in most embedded systems. For example, a hard disk drive needs three very specific control systems: spindle, seek and track following. Is it worth abstracting these three controllers into one just because they are controllers? Now, think about a SCADA or DCS systems. In these systems, there is a high level of variability because these systems must control and monitor a vast number of different physical processes; in this case, there are no specific control systems, but many types of them. To design for many types requires higher levels of abstractions.
We are convinced OOP and procedural programming are equivalent methodologies. One should lead to the other one; after all, function and data are inseparable. A good OOP design should lead to a clear functional structure; conversely, a good procedural programming design should lead to a clear object structure.
In this presentation, we highlighted the intertwined nature between data and procedures. We tried to convey the point that object-oriented analysis and procedural analysis are not at odds with each other, although it has been presented like that through the years. Even for those heavy concepts of object-oriented analysis, we have found that they fit perfectly in a procedural context. Software engineering best practices should be the framework for embedded software design, functions and objects will follow naturally.
For more information visit: