Inhalte

• Home
  • License Agreement
  • Introduction
  • IDE Settings
  • Project
  • Repository
  • Comments
  • reStructuredText
  • Naming
  • Formatting
    • Formatting Structured Text and Extended Structured Text ExST
    • Formatting SFC
  • Practices
    • Practices Introduction
    • Common Practices
      • Common Practices Interfaces
      • Common Practices Data Structures vs Objects
      • Common Practices Inheritance
      • Common Practices Dependencies
        • Common Practices Dependencies Examples
          • Common Practices Dependencies Examples Dependency Injection
            • Dependency Injection Introduction
            • Dependency Injection Common Interfaces
            • Dependency Injection Devices
            • Dependency Injection Inter-Stopper-Communication
            • Dependency Injection Stopper Workflows
            • Dependency Injection Stopper
            • Dependency Injection Declaration in Main
            • Dependency Injection Summary
          • Dependencies Examples Abstract Factories
            • Abstract Factories Introduction
            • Abstract Factories Object
            • Abstract Factories Alarm Messages
            • Abstract Factories Alarm Message Service
              • Alarm Message Service Introduction
              • Alarm Message Service Common Interfaces
              • Alarm Message Service Collection Interfaces
              • Alarm Message Service Factories
              • Alarm Message Service Collection Implementations
              • Alarm Message Service Alarm Message Distributor
            • Abstract Factories OPC-UA HMI Connection
            • Abstract Factories Test it
            • Abstract Factories Summary
      • Common Practices ControlStatus Words
      • Common Practices Scope Pointer
      • Common Practices Divide The Libraries
      • Common Practices Return Values
    • STExST Practices
      • STExST Practices GOTO JMP
      • STExST Practices CASE OF
      • STExST Practices Assignment as Expression
      • STExST Practices Namespace Alias
      • STExST Practices VAR_OUTPUT
    • SFC Practices
      • SFC Practices Jumps
      • SFC Practices Cyclic Rotations
  • Glossary
    • Glossary A
    • Glossary B
    • Glossary C
      • Glossary Class
    • Glossary D
      • Glossary Data Transfer Object
      • Glossary Dto
    • Glossary E
    • Glossary F
      • Glossary Foo
    • Glossary G
    • Glossary H
    • Glossary I
    • Glossary J
    • Glossary K
    • Glossary L
    • Glossary M
    • Glossary N
    • Glossary O
    • Glossary P
    • Glossary Q
    • Glossary R
    • Glossary S
    • Glossary T
    • Glossary U
    • Glossary V
    • Glossary W
    • Glossary X
    • Glossary Y
    • Glossary Z

Common Practices: Dependencies

Table of Contents

Introduction

In an idealized software, there are only dependencies to interfaces or to abstract classes, but never to concrete implementations. This is not so true because we have classes of TwinCAT, which we include directly and do not work with abstractions, e.g. TON, TOF, F_TRIG etc.. For these classes there are no abstractions either, but this is not so bad for us because it is very unlikely that they will change. But in everything we develop, we are always working with abstractions, or more precisely, an interface. Abstract classes are there to take the implementation work off our hands, but abstract classes also have to implement their own interface. The following rules must be observed. For easier reading use concrete classes, but of course except the TwinCAT classes.

Do not use concrete classes in your classes

The code should use abstract interfaces instead of concrete classes. For objects that are created at compile time, the dependency must be realized via dependency injection. For objects that are created at runtime, abstract factories must be used.

No derivation from concrete classes

Inheritance represents the strongest binding in code. Therefore, for classes of which there are several derivatives, abstract classes should always be created first so that it is easier to adapt classes without it having an effect on subclasses.

Do not override methods of concrete classes

When overwriting methods of concrete classes, a dependency is created by inheritance, so here too: first create an abstract class and derive the necessary subclasses from it. This way the different functions can be implemented easily without creating dependencies to concrete classes.

Do not waste your time