Patent Application
20100125831
Embodiments of the invention relate to increasing the flexibility and extensibility of modular software design. More specifically, embodiments of the invention relate to interface versioning.
Software designers often use modular components to provide flexibility and extensibility of the design software. As a result of the modular construction, each component can be replaced or enlarged in functionality by new components. Unfortunately, the interface for each component must be defined in advance and cannot be changed afterwards. The interfaces for each component are defined during the design phase of the software. During implementation and testing, those interfaces may be modified, but once the interface is deployed, changes to the interface are no longer possible. For example, once the interface is deployed, a customer may have implemented the interface and created new components that use the interface. If the interface later changes, the implementation of the customer would fail.
It is possible to mitigate this problem by permitting new parameters that can added to the interface, but must be flagged as optional. This permits old implementations to ignore the new parameters and allows new implementations to use them. Additionally, new methods may be added to the interface, but calling instances must address that the new method might not be implemented by an old class implementing the interface. As a result, very careful error handling is required.
A system and method of interface visioning to improve extendibility and flexibility in modular software design is disclosed. 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.
The invention is illustrated by way of example and not by way of limitation in the figures of the accompanying drawings in which like references indicate similar elements. It should be noted that references to “an” or “one” embodiment in this disclosure are not necessarily to the same embodiment, and such references mean at least one.
An application 106 may execute on the processor 102 from main memory 104. Application may use methods and obtain data through one or more interfaces, such as interface1 108, interface2 110 and interfaceN 112. In one embodiment, for example, interface 108 is a first version of an interface while interface2 110 is a second version of that interface.
Interface 110 may have additional methods and parameters and need not be backward compatible. Using the embodiment described below, complex error handling and incompatibility are nevertheless avoided. Interface1 108 is implemented by a first super class, 132. Interface2 110 may be a second version of the interface. However, to ensure backward compatibility at the system (rather than the interface), super class2 134 implements interface 108 and interface 110.
When application 106 (or other component) seeks to use a feature, it passes the name of the feature to a constructor 118 which instantiates an access class 114 or 116 to encapsulate the feature object 124. The access class identifies from the feature object 124, which interface, e.g., 108, 110, 112 the feature object 124 needs to use and provides access to the interface via the corresponding super class 132, 134.
In one embodiment, the super class 132, 134 includes a version designation as a static attribute. The feature object inherits the version designation as a static attribute from the super class. In this manner, the access class can identify from the attributes of the feature object which super class must be accessed.
Notably, end user, e.g., application 106 need not know what interfaces 108, 110 have been implemented nor what version of a feature 124 will be used. Rather, it need only know the feature name and the handling of different interface versions occurs transparently within the access class 114, 116.
A first super class 212 implements a first interface 202. First super class includes the static attribute “version=1”, which provides a version designation for super class 212. Later in time, additional features may be added that are not provided for in first interface 202. Thus, a second super class 214 may be deployed to implement both first interface 202 and second interface 204. The second super class 214 has a static attribute “version=2” to provide a version designation for the second super class 214. Second interface 204 may implement a subordinate interface 220 to provide additional methods to users of the second interface 204.
For purposes of expandability it is within the scope and contemplation of embodiments of the invention to have, for example, a third super class that implements a first through third interface up to an nth super class implementing a first through nth interface. This serves to provide great extensibility in modular design. Because each user interface is permitted to add new methods and parameters without accounting for backward compatibility and without requiring accessing components (end users) to know anything about the versioning design flexibility and simplicity are greatly increased.
An access class 216 identifies which super class supports a feature requested by an interface caller, e.g., an application (not shown). Access class 216 instantiates a feature class object 218 and calls the method requested by the application. The access class contains all method of all supported interfaces. Each method checks the version of the instantiated feature object. If the feature is available in the interface implementation, the feature can be called. Otherwise, the access class 216 throws an exception that may be caught by the caller.
Feature class 218 is derived from one of the super classes (here super class2 214) and therefore implicitly implements methods from an appropriate version of interface. Because feature class inherits a version designation from a corresponding super class, the access class can identify which super class to use in accessing the interfaces 202, 204.
Stated slightly differently to provide a concrete example outside of the billing context, super class2 214 may be a generic instance of the class “animal.” One feature may, for example, be the same for all “animals,” e.g., “running” thus “animal” may provide a running method that, e.g., “cat” and “dog” both derive from “animal.” Therefore neither “cat” nor “dog” need to implement “running” each time. Feature class 218 may represent, e.g., “dog” which implements the interface “animal” and provides special methods, e.g., barking for animal's generic method “make noise.” The access class 216 requests feature “dog” instantiates 218 and calls “make noise.” Feature class 218 responds with a bark because that is the way “dog” provides make noise.
It should be appreciated that reference throughout this specification to “one embodiment” or “an embodiment” means that a particular feature, structure or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Therefore, it is emphasized and should be appreciated that two or more references to “an embodiment” or “one embodiment” or “an alternative embodiment” in various portions of this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures or characteristics may be combined as suitable in one or more embodiments of the invention.
Elements of embodiments of the present invention may also be provided as a machine-readable medium for storing the machine-executable instructions. The machine-readable medium may include, but is not limited to, flash memory, optical disks, compact disks read only memory (CD-ROM), digital versatile/video disks (DVD) ROM, random access memory (RAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic or optical cards, propagation media or other type of machine-readable media suitable for storing electronic instructions.
In the foregoing specification, the invention has been described with reference to the specific embodiments thereof. It will, however, be evident that various modifications and changes can be made thereto without departing from the broader spirit and scope of the invention as set forth in the appended claims. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.
