![]() All other adapters of the lamp types, even those that do not support the new feature, also receive the nOperatingTime property via the abstract base FB_Lamp. However, the central interface I_Lamp is extended only to add another feature for one lamp type. Also, none of the SOLID principles shown so far are violated. This approach implements the feature as desired. (abstract elements are displayed in italics) In this way, the value of the operating hours counter is passed on to FB_Controller. The getter and the setter from the adapter access nOperatingTime from FB_LampSetDirectDALI. Since FB_LampSetDirectDALI supports the operating hours counter, the adapter ( FB_LampSetDirectDALIAdapter) overwrites the nOperatingTime property. NOperatingTime := fbController.nOperatingTime IF (fbController.nOperatingTime >= 0) THEN The absence of the operating hours counter can thus be detected. The getter of FB_Lamp (abstract function block from which all adapters inherit) returns the value -1. The getter and the setter of nOperatingTime in FB_Controller can thus directly access nOperatingTime of the individual adapters of the lamp types. Since all adapters inherit from FB_Lamp, the adapters of all lamp types receive this property, regardless of whether the lamp type supports an operating hours counter or not. Thus, the abstract function block FB_Lamp also receives the nOperatingTime property. The property for the new feature is integrated into the I_Lamp interface. What possibilities are there to transfer the value of nOperatingTime from FB_LampSetDirectDALI to the property nOperatingTime of FB_Controller? Here, too, there are now various approaches of integrating the required extension into the given software structure. The variable _nOperatingTime is the backing variable for the new property nOperatingTime and is declared in the function block. ![]() For this purpose, the function block FB_LampSetDirectDALI is extended by the property nOperatingTime. The DALI lamp should be able to count the operating hours. ![]() However, it is not a new lamp type that is defined, but an existing lamp type is extended by a functionality. Extension of the implementationĪlso this time, the application has to be extended. This will serve as a starting point for explaining the Interface Segregation Principle (ISP). This makes the DALI lamp behave exactly like the other lamp types without violating the Liskov Substitution Principle (LSP). The sample program was last adapted so that the output value from the new lamp type ( FB_LampSetDirectDALI) is scaled within the adapter from 0-254 to 0-100 %. The adapters have been added during the implementation of the Single Responsibility Principle (SRP) and ensure that the function blocks of the individual lamp types are only responsible for a single function (see IEC 61131-3: SOLID – The Single Responsibility Principle). Just like all other lamp types, the new lamp type (DALI lamp) has an adapter ( FB_LampSetDirectDALIAdapter). While the other lamp types output 0-100%, the new lamp type outputs a value from 0 to 254. The special feature of this lamp type is the scaling of the output value. In the last post ( IEC 61131-3: SOLID – The Liskov Substitution Principle), the example was extended by another lamp type ( FB_LampSetDirectDALI). The following shows how this design principle can be implemented. A module should implement only those interfaces that are needed for its task. The Interface Segregation Principle (ISP) focuses on the module’s interface. 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.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |