Interface Versioning via Access Class Segmentation
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Modular software design faces limitations as interfaces defined during the design phase cannot be changed post-deployment, leading to compatibility issues and complex error handling when new parameters or methods are added, affecting flexibility and extensibility.
Innovation Solution
Implementing a system with super classes that have unique version designations for interfaces, allowing an access class to dynamically provide access to the appropriate interface based on version, ensuring backward compatibility and transparent handling of different interface versions.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If the interface is defined during the design phase and deployed without versioning, then the implementation is simple and stable, but the interface cannot be changed afterwards and new parameters or methods cannot be added
Solution Approach 1:
The interface system is segmented into multiple versions, where each version is represented by a separate super class. This allows the interface to be divided into distinct evolutionary stages (first interface, second interface, etc.), enabling new parameters and methods to be added in subsequent versions without affecting existing implementations that rely on older versions.
Solution Approach 2:
An access class is introduced as an intermediary between the client code and the interface implementations. This access class dynamically determines which super class (and thus which interface version) to instantiate based on the feature being accessed. This mediator handles the complexity of version management internally, allowing client code to remain simple while supporting multiple interface versions.
2Adaptability or versatility
If new parameters are added to the interface, then the functionality is extended, but old implementations must carefully handle the new parameters with complex error handling
Solution Approach 1:
The interface parameters and methods are segmented into different version groups. Each super class represents a specific version with its own set of parameters and methods. Old implementations that inherit from earlier super classes automatically only see the parameters and methods appropriate to their version, eliminating the need to handle new parameters that they don't support.
Solution Approach 2:
The interface system becomes dynamic through the access class, which can instantiate different super classes based on runtime conditions. This dynamic behavior allows the system to adapt to different interface versions without requiring static error handling code in each implementation. The complexity of determining which version to use is moved from the implementation level to the access level.
3Adaptability or versatility
If the interface is made flexible to allow changes, then new methods can be added, but calling instances must address that the new method might not be implemented by old classes
Solution Approach 1:
Interface methods are segmented by version, with each super class containing only the methods appropriate to its version. This segmentation ensures that old classes implementing earlier versions never encounter method calls for methods that don't exist in their version, as the access class routes calls to the appropriate super class based on the feature being accessed.
Solution Approach 2:
The access class serves multiple functions: it acts as a factory that creates appropriate instances of super classes, serves as a router that directs method calls to the correct version, and provides a unified interface to client code. This multi-functionality allows the system to manage multiple interface versions with a single point of control, simplifying compatibility management.
Data Source
AI summary
A system and method of interface visioning to improve extendibility and flexibility in modular software design. A first super class implements a first interface. A second super class implements both a first interface and a second interface. Each super class has a unique version designation. An access class is instantiated when a feature using an interface is requested. The access class identifies from the feature the version designation and provides access to the appropriate interface through either the first super class or the second super class.