Java multi-interface application skills

 

Java has a clear rule when designing interfaces and class rules. Java does not support multi-inheritance of classes (implementations), but supports multi-inheritance of interfaces (definitions.

I do not know the original intention of this design, but such a provision implies the following meanings.

Interfaces are the product of design, that is, the definition of software functions defined during the design requirement. Classes are the product of implementation. They are completed in the implementation process according to the specific implementation conditions. If the code is used, it means:

During the design, I need the "module" I designed to provide two functions:

1. Add two integers.

2. Provides the function of connecting two strings.

 

I am a great designer. In order not to affect my overall thinking, I will not stop at this moment to implement it, so I need something similar to pseudocode to record my Implementation ideas. Java says, well, we provide you with something called an interface. You only need to write down what you want to implement without providing specific implementation methods.

 

 Interface imyfunc {</P> <p> Public int add (int A, int B); </P> <p> Public String Concat (string str1, string str1 ); <br/>}< br/>

....... Other designs.

Well, Which of the following is the best way to implement this task?

Xiao bandits received the encoding task. It's easy to analyze the design ideas of a master.

 Class mymathimp implements imyfunc {</P> <p> Public int add (INT N1, int N2) {</P> <p> // all input values are integers, if it is not an integer, an error occurs during compilation. <br/> // so I don't need to check it and add it directly. Haha, the salary is mixed up today. </P> <p> return N1 + N2; </P> <p >}</P> <p> Public String Concat (string S1, strings2) {</P> <p> // Well, check it. If one of the strings is null, <br/> // do I display "string null" or "string? If both are null, <br/> // do I display a "null" or "nullnull? <Br/> // It is really complicated. The rigor is more complicated than the specific implementation. I just want to put it in another method. </P> <p> return checkedconcat (S1, S2); <br/>}</P> <p> string checkedconcat (string S1, string S2) {<br/> If (S1 = NULL & S2 = NULL) Return "null"; <br/> If (S1 = NULL) S1 = "null "; <br/> If (s2 = NULL) S2 = "null"; <br/> return S1 + S2; <br/>}</P> <p>}

 

Checkedconcat I also want to be called elsewhere, so I don't want to design it as ptivate. So the mymoduleimp I designed can see three methods from the outside.

 

In my opinion, I provided two methods, and I implemented three methods. Fortunately, there were interfaces. When I published this module, I only provided interface documentation. In this way, you can open this interface in the intelligent sensor ide to see only the two methods defined by the master.

 

Therefore, the interface can only expose the method of the design intent to the caller.

 

So, when a class provides methods with different functions, I want to display only some functions at different times. What should I do?

In fact, sun's Code does not handle this issue well. For example, one of my classes provides object initialization and object release methods, integer and string operations, and graphic operations. Of course, this is just an example.

Some people say that the class design is unreasonable. So many different types of functions should be implemented in different classes.

That's right! But ..........

If our object is locally generated, the cost of multiple new objects is not too high. If our object is called remotely, the cost of generating multiple objects is high.

In addition, the methods and business methods managed by any object cannot be implemented in two classes? What is the use of narcissism in addition to a class that only manages itself? Some objects that must be managed, such as initialization and release, cannot work only in business methods. Therefore, at least two types of functions must be completed in the same category. If there are enough methods to overload them, you will see that they are a lot of functional methods mixed in alphabetical order.

A typical example is the urlconnection class. When you open it, you can set the request parameter method, obtain the Response Header domain method, and obtain a lot of input and output methods. But fortunately, their naming methods make a lot of methods with the same features work together.

How can we effectively organize the classification of methods that implement different functions? We can do this through multiple interfaces.

 

This idea has been adopted as early as the com era. Whether you get the iunknown interface, the idispatch interface, or the business interface, the reverse response is actually the same coclass object, however, you can see different functions through different interfaces. At the same time, you only need to instantiate it once and get any interface to generate other interfaces from this interface. This is very meaningful for callers. I can not only get function categories of different functions, in addition, you do not need to instantiate multiple objects multiple times.

 

Interface imath {</P> <p> Public int add (int A, int B); </P> <p> Public int MUL (int A, int B ); <br/>}</P> <p> interface istrutil {</P> <p> Public String Concat (string S1, string S2 ); </P> <p> Public String upper (string S1 ); </P> <p >}</P> <p> interface iobjmanager {</P> <p> void Init (); </P> <p> void destory (); </P> <p >}</P> <p> class mymoduleimp implements imath, istrutil, iobjmanager {</P> <p> Public int add (int A, int B) {<br/> return A + B; <br/>}</P> <p> Public int MUL (int A, int B) {<br/> return a * B; <br/>}</P> <p> Public String Concat (string S1, string S2) {<br/> return checkedconcat (S1, S2 ); <br/>}</P> <p> Public String upper (string S1) {<br/> return checkedupper (S1 ); <br/>}</P> <p> Public void Init () {<br/> system. out. println ("init ......... "); <br/>}</P> <p> Public void destory () {<br/> system. out. println ("destory ......... "); <br/>}</P> <p> string checkedconcat (string S1, string S2) {</P> <p> If (S1 = NULL & S2 = NULL) <br/> return "null "; <br/> If (S1 = NULL) S1 = "null"; <br/> If (s2 = NULL) S2 = "null "; <br/> return S1 + S2; <br/>}</P> <p> string checkedupper (string S1) {</P> <p> If (S1 = NULL) return NULL; <br/> return s1.touppercase (); <br/>}< br/>}

 

OK!

Iobjmanager om = new mymoduleimp (); // or getobjfromnet. If we encapsulate the methods for generating instances in a unified manner, and the object lifecycle management is specified in an interface similar to iunknown, we can have a unified management behavior for different classes of functions, just like the instantiation of remote EJB objects.

 

Om. Now we can see only the iobjmanager interface method. We can init. destory.

When we need its business method:

 

Imath M = (imath) om; // equivalent to QueryInterface

M. What we can see here is only the functional methods related to math.

 

In addition, when we want to add a method and retain the original method, we only need to declare it in the new interface and let the implementation class inherit from this interface (in fact, the interface name is added after the implements keyword ). In this way, the new and old interfaces can be used together without affecting the previous code or subsequent users to use the new interfaces:

 Interface imathex {</P> <p> Public int add (int A, int B); </P> <p> Public int MUL (int A, int B ); </P> <p> Public double SQRT (double A); </P> <p >}</P> <p> class mymoduleimp implements imath, imathex, istrutil, iobjmanager {</P> <p> // added public double SQRT (double A) Implementation </P> <p >}< br/>

 

 

In this way, the code that uses imath to calculate the "addition and multiplication" is not affected at all, and the new program can use imathex to calculate the "addition, multiplication, and square" operation.

Therefore, multiple interfaces not only enable us to effectively organize code with different functions, but also provide a unified management method for objects, while avoiding the overhead caused by multiple object generation.