TwinCAT – Stefan Henneken

IEC 61131-3: SOLID – Das Open/Closed Principle

Vererbung ist eine beliebte Methode, um bestehende Funktionsblöcke wiederzuverwenden. Dadurch lassen sich Methoden und Eigenschaften hinzufügen oder bestehende Methoden überschreiben. Hierbei ist es nicht notwendig, den Quellcode des Basis-FB zur Verfügung zu haben. Software so zu designen, dass Erweiterungen möglich sind, ohne die vorhandene Software zu verändern, ist die Grundidee des Open/Closed Principle (OCP). Doch die Anwendung von Vererbung hat hierbei auch Nachteile. Der Einsatz von Schnittstellen minimiert diese Nachteile und bietet zusätzliche Vorteile.

IEC 61131-3: SOLID – The Interface Segregation Principle

The basic idea of the Interface Segregation Principle (ISP) has strong similarities with the Single Responsibility Principle (SRP): Modules with too many responsibilities can negatively influence the maintenance and maintainability of a software system. The Interface Segregation Principle (ISP) focuses on the module’s interface. A module should implement only those interfaces that are needed for its task. The following shows how this design principle can be implemented.

IEC 61131-3: SOLID – Das Interface Segregation Principle

Der Grundgedanke des Interface Segregation Principle (ISP) hat starke Ähnlichkeit mit dem Single Responsibility Principle (SRP): Module mit zu vielen Zuständigkeiten können die Pflege und Wartbarkeit eines Softwaresystem negativ beeinflussen. Das Interface Segregation Principle (ISP) legt den Schwerpunkt hierbei auf die Schnittstelle des Moduls. Ein Modul sollte nur die Schnittstellen implementieren, die für seine Aufgabe benötigt werden. Im Folgenden wird gezeigt, wie dieses Designprinzip umgesetzt werden kann.

IEC 61131-3: SOLID – The Liskov Substitution Principle

„The Liskov Substitution Principle (LSP) requires that derived function blocks (FBs) are always compatible to their base FB. Derived FBs must behave like their respective base FB. A derived FB may extend the base FB, but not restrict it.” This is the core statement of the Liskov Substitution Principle (LSP), which Barbara Liskov formulated already in the late 1980s. Although the Liskov Substitution Principle (LSP) is one of the simpler SOLID principles, its violation is very common. The following example shows why the Liskov Substitution Principle (LSP) is important.

IEC 61131-3: SOLID – Das Liskov Substitution Principle

„Das Liskov Substitution Principle (LSP) fordert, dass abgeleitete FBs immer zu ihren Basis-FB kompatibel sind. Abgeleitete FBs müssen sich so verhalten wie ihr jeweiliger Basis-FB. Ein abgeleiteter FB darf den Basis-FB erweitern, aber nicht einschränken.“ Dieses ist die Kernaussage des Liskov Substitution Principle (LSP), welches Barbara Liskov schon Ende der 1980iger Jahre formulierte. Obwohl das Liskov Substitution Principle (LSP) eines der einfacheren SOLID-Prinzipien ist, tritt deren Verletzung doch sehr häufig auf. Warum das Liskov Substitution Principle (LSP) wichtig ist, zeigt das folgende Beispiel.

IEC 61131-3: SOLID – The Single Responsibility Principle

The Single Responsibility Principle (SRP) is one of the more important of the SOLID principles. It is responsible for decomposition of modules and encapsulates the idea that each unit of code should be responsible for just a single, clearly defined role. This ensures that software remains extensible long term and makes it easier to maintain.

IEC 61131-3: SOLID – Das Single Responsibility Principle

Das Single Responsibility Principle (SRP) ist eines der wichtigsten unter den SOLID-Prinzipien. Es ist für die Zerlegung von Modulen zuständig und verdeutlicht, warum eine Codeeinheit nur für eine einzig klar definierte Aufgabe verantwortlich sein sollte: Software bleibt langfristig erweiterbar und kann deutlich einfacher gepflegt werden.

IEC 61131-3: SOLID – The Dependency Inversion Principle

Fixed dependencies are one of the main causes of poorly maintainable software. Certainly, not all function blocks can exist completely independently of other function blocks. After all, these interact with each other and are thus interrelated. However, by applying the Dependency Inversion Principle, these dependencies can be minimized. Changes can therefore be implemented more quickly.

IEC 61131-3: SOLID – Das Dependency Inversion Principle

Feste Abhängigkeiten sind einer der Hauptursache für schlecht wartbare Software. Natürlich können nicht alle Funktionsblöcke völlig unabhängig von anderen Funktionsblöcken existieren. Schließlich agieren diese miteinander und stehen somit untereinander in Beziehungen. Durch das Anwenden des Dependency Inversion Principle können diese Abhängigkeiten aber minimiert werden. Änderungen lassen sich somit schneller umsetzen.

IEC 61131-3: SOLID – Five principles for better software

In addition to the syntax of a programming language and the understanding of the most important libraries and frameworks, other methodologies – such as design patterns – belong to the fundamentals of software development. Aside from a design pattern, design principles are also a helpful tool in the development of software. SOLID is an acronym for five such design principles, which help developers to design software more understandable, more flexible and more maintainable.