Object-oriented programming
TwinCAT 3 supports object-oriented programming (OOP) and provides the following functionalities and objects for this purpose:
- Function blocks (Object Function block)
- Methods (Method object)
- Properties (Property object)
- Interfaces (Object Interface, Implementation of an interface)
- Inheritance
- Definition of function blocks as Extensions of other function blocks
- Definition of structures as Extensions of other structures
- Definition of interface as Extensions of other interfaces
- Method call
- ABSTRACT concept
Basic idea of object-oriented programming
In object-oriented programming, the software is divided into objects. All descriptions relating to an object are combined in one element (a function block, for example). The descriptions include the data and the procedures associated with the object. In addition, an access interface to the object can be defined via methods and properties.
As a result, this programming approach develops objects that can be reused autonomously and independent of specific conditions. The elements can be used without modification in one or many applications.
Advantages of object-oriented programming
Object-oriented programming method offers many advantages.
By dividing the software into objects, a clear, well structured application can be developed. Thus, the application and the individual elements are easily understandable and easy to expand. The reusability of programming objects saves time and costs in the development and maintenance of applications.
General notes/recommendations
- When using object-oriented programming, care must be taken to find the correct "degree of object orientation" for the respective application.
- With the help of OOP, the software is divided into objects, so that a clear, structured, reusable software can be developed.
- However, if the division into the objects is excessively detailed, the comprehensibility of the program suffers.
- Example: Using the inheritance feature, declarations and implementations can be passed on and thus reused by the subclass. In addition, division into a general and a specific class can support the understanding of the individual programming objects. This is the case with inheritance if the division into ‘basic’ and ‘extended’ is consistent. A real-world example is a basic motor and a more specific motor with additional functions. However, if a large number of inheritance levels are used and the function of the individual inheritance levels becomes unclear or imprecise, the application can become difficult to understand and maintain.
- If methods provide return values, these should be set in the method and evaluated at the point where the method is called.
- If methods, functions or properties return structured return types (e.g. a structure or a function block), these return types should be declared as "REFERENCE TO <structured type>".
- Returning structured data as a direct return type ("<structured type>") is inefficient because the data is copied multiple times.
- If "REFERENCE TO <structured type>" is used instead, on the one hand this is more efficient because the data is not copied, and on the other hand a single element of the structured data type can be accessed directly when the method/function/property is called.
- For more information and an example see the Object method description.
- Programming of object-oriented implementations should be event-based.
- Program elements should not be called cyclically without reason.
- Usually, it makes sense to call a program element when a certain event has occurred.
- A method or property call via an unassigned interface variable has the same effect as a NullPointer call. Before you can use the interface variable, you must assign a corresponding function block instance to it (instance of a function block that implements the interface).
- To ensure that the interface variable does not correspond to a NullPointer, the interface variable can be checked for unequal 0 before it is used (e.g.
IF (iSample <> 0) THEN iSample.METH (); END_IF
).
OOP and UML
Does object-oriented programming (OOP) and UML always have to be used together?
- The combined use of OOP and UML offers many benefits (see next question), although it is not compulsory. Object-oriented programming of applications is also possible without using UML. Likewise, UML can be used in PLC projects, which are not based on object-oriented programming.
What are the benefits of using OOP and UML together?
- In order to make the most of OOP, the structure of an object-oriented software should be designed and created before the implementation (e.g. What classes are available, what is their relationship, what functionalities do they offer, etc.). Before, during and after programming, documentation helps to understand, analyze and maintain the software.
- As an analysis, design and documentation tool for software, UML offers options for planning, creating and documenting the application. UML is particularly suitable for object-oriented implementations, since modular software is particularly suitable for representation with the aid of a graphical language.
- For example, the class diagram is used for analyzing and creating the program structure. The more modular the software structure, the easier and more efficient the class diagram can be used (e.g. Graphical representation of separate function blocks with individual methods for providing the functionalities etc.).
- The state diagram can be used to specify the sequence of a system with discrete events. The more consistent the object- and event-orientation of the software structure, the more transparent and effective the state machines can be designed (e.g. The behavior of modules/systems is based on a state model with states (such as startup, production, pause); within the states corresponding functionalities are called, which are encapsulated in methods (such as startup, execute, pause) etc.).
See also:
- Documentation for: TF1910 TC3 UML
- Documentation samples: Sample: Object-oriented program for controlling a sorting plant