Real interface-oriented development based on osgi-from bluedavy technical blog

Whether interface-oriented development can be implemented is closely related to the container or framework used by the system. The most important thing for interface-oriented development is to solve the system dependency problem, at this point, the most mature solution is IOC, and the most successful IOC container is spring. Does osgi-based solution bring different perspectives, let's take a look at these examples:
1. Class A: Class A that implements the B interface in the Execution System
How simple it is to implement this in osgi:
Servicereference [] servicerefs = context. getservicereference (B. Class. getname ());
For (INT I = 0; I <servicerefs. length; I ++ ){
B = (B) Context. getservice (servicerefs [I]);
B .exe cute ();
}
People who are used to IOC will say that the above method still needs to take the initiative to get such a bad result through context. In osgi, you can also use the following method to call it:
Public void setservice (B ){
B .exe cute ();
}
This method is satisfactory. In this case, you only need to configure the class's reference to B as cardinality = "0 .. N ", then the osgi framework will automatically call the execute method of the class implementing the B interface.
PS: You can imagine how easy it is to implement cor pattern in this way ....
2. Class A references the log interface, but it does not matter whether there is any log interface implementation in the system. Such operations must be normal.
It is also very easy to achieve this in osgi:
Public void setlog (log ){
This. log = log;
}
You only need to configure this class's reference to log as: cardinality = "0 .. 1"
3. Class A wants to determine which class to call based on certain conditions
In osgi, attributes such as attribute filtering and version filtering can be used to dynamically determine the classes that call the corresponding implementation interfaces, it can be imagined that it is more simple and convenient to implement similar business logic processing.
4. Dynamic
This is because of the characteristics of osgi. In a system built based on osgi, we can define the interface first, and then start the entire system. After an interface is implemented, deployed in the osgi framework, you can use this interface directly after you use it. The entire system does not need to be restarted or other troublesome operations.

From the preceding simple examples, we can see that osgi-based real interface-oriented development has become very easy and flexible, dynamic features make it possible to build a system in full interface mode, which is very important for iterative development models.
Why is this method truly interface-oriented development? We can see that in traditional development methods, no matter what, the system can run only after the class that implements the interface is available, but it is not required in osgi-based development, in an osgi-based system, developers can determine that the functions are implemented after all the required interfaces are provided, without the need to check whether the system has specific interfaces, more importantly, most traditional development methods define dependencies before running, while osgi-based systems can easily determine dependencies during runtime, this is self-evident in improving system flexibility.

PS: I know a lot about spring. After reading the above examples, I will tell you that the above examples can be implemented based on spring, but it is not necessary to make more enhancements, spring itself does not have a complete classloader mechanism, so it will become very complicated to implement these dynamic features based on it, and now osgi has provided these, why do we need to use spring-based enhancement to achieve these goals already achieved in osgi?