Object-Oriented Programming (OOP)
- Goal
- Maintainability:
\(\checkmark\)
- Reliability:
\(\checkmark\)
- Portability:
- Performance:
- Security:
\(\checkmark\)
- Description
Have a plan for selecting the OOP facilities of the language to use.
- Rules
OOP01, OOP02, OOP03, OOP04, OOP05, OOP06, OOP07
There are many issues to consider when planning the use of Object Oriented features in a high-integrity application. Choices should be made based on the desired expressive power of the OO features and the required level of certification or safety case.
For example, the use of inheritance can provide abstraction and separation of concerns. However, the extensive use of inheritance, particularly in deep hierarchies, can lead to fragile code bases.
Similarly, when new types of entities are added, dynamic dispatching provides separation of the code that must change from the code that manipulates those types and need not be changed to handle new types. However, analysis of dynamic dispatching must consider every candidate object type and analyze the associated subprogram for appropriate behavior.
Therefore, the system architect has available a range of possibilities for the use of OOP constructs, with tool enforcement available for the selections. Note that full use of OOP, including dynamic dispatching, may not be unreasonable.
The following rules assume use of tagged types, a requirement for full OOP in Ada.
- No Class-wide Constructs Policy (OOP01)
- Static Dispatching Only Policy (OOP02)
- Limit Inheritance Hierarchy Depth (OOP03)
- Limit Statically-Dispatched Calls To Primitive Operations (OOP04)
- Use Explicit Overriding Annotations (OOP05)
- Use Class-wide Pre/Post Contracts (OOP06)
- Ensure Local Type Consistency (OOP07)