The Multiple Interface Support in G Design Pattern had been first presented on the NIWeek 2016 Advanced Users Track (AKA “Room 15”):
In a follow-up discussion I’ve been asked for a more detailed explanation and sample code – leading to this document and bonus material (attached) :
To provide a way for calling the same Object through different Interfaces.
G classes support Single Inheritance only. No Interfaces (Java, C#). No Mixins (C++, Groovy, Python, Ruby, etc.). No Traits (Scala). To achieve high levels of code reuse contemporary software design techniques (such as SOLID Design Principles) recommend separating callers from concrete class implementations through some sort of well-defined and stable “interfaces”. In particular, the Interface Segregation Principle (ISP) requires that “Clients should not be forced to depend on methods that they do not use”. This LabVIEW-specific Design Pattern allows creating multiple “interfaces” (suitable for different caller types) to the same by-value base class.
(*) Facade Pattern is used to provide a simple and specific Interface to one or more classes that have a complex and general Interface. Facade Pattern looks much like Adapter and Decorator Patterns, but the intent (use cases) are quite different.
To implement ‘regular’ Interfaces follow Workflow A:
Single Responsibility Principle requires classes to delegate implementing non-core functionality to helper classes. Dependency Inversion Principle requires decoupling classes from their helper classes through Dependency Interfaces.
Follow Workflow B to implement Dependency Interfaces for a given Helper Class:
Design Pattern Pros
Design Pattern Cons
[Dmitry Sagatelyan] Provided sample code () shows how to implement both, ‘regular’ Base Class Interfaces and Dependency Interfaces. It also shows how to design () and implement an application-specific Configuration Handler class.
CLA, LabVIEW Champion
Arktur Technologies LLC