 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / September 2007How to separate interface from implementation when using JARs?
Hi, In an engineering world where I used to be working with C++ I am now shiftnig to Java. In C++ I would publishe my interfaces in header files. In Java I can use the interface concept. However this is not sufficient for me. I want to be able to full separate the implementation from the interface of e.g. a class method. Example: public interface MyMath { On Sep 17, 1:33 pm, MJT.Keijs...@gmail.com wrote a message and was too soon to send :-), Full text below: Hi, In an engineering world where I used to be working with C++ I am now shiftnig to Java. In C++ I would publishe my interfaces in header files. In Java I can use the interface concept. However this is not sufficient for me. I want to be able to full separate the implementation from the interface of e.g. a class method. Example: public interface MyMath { int MyAdd(int a, int n); } class Calculate implements MyMath { int MyAdd(int a, int n) { return a - b; } I would use this class as an import in my client code: #import Calculate class client { void DoIt() { Calculate c = new Calculate(); int sum = c.MyAdd(9,7); } Once I discover the implementation error in the Calculate and want to fix that I do not want to change the client code to require recompilation/distribution. In C++ I would not have to change the header file,only a cpp file. I would compile and link the math library to a dll and redistribute only that DLL. In basic JAVA, when I recompile my client code will recompile leading to a new (changed?) client JAR which I should also redistibute. This is undesired for me. I played with RMI and managed to do this when using two JVM's, but in the 'simple' scenario where I want to divide a project in separate JARs for maintainability, do I have to accept the fact that the client code changes, or must I apply RMI? Kind Regards, Marc i dont see what the problem is, just put the interface in one jar. for example: myapi.jar then put the implementing classes in another file mylib.jar you could also put the classes that use both in another file myapp.jar this is what we typically do. > In an engineering world where I used to be working with C++ I am > now shiftnig to Java. In C++ I would publishe my interfaces in [quoted text clipped - 31 lines] > (changed?) client JAR which I should also redistibute. This is > undesired for me. If I understand your issue correctly, you can achieve something similar by creating separate jar files for interfaces and implementations. With that approach, you could release only the implementation jar when fixing a bug. If you have a distributed system, you could dynamically download updates by distributing jars only to class servers. One Java technology that supports this is Jini (http://www.jini.org). Regards, Patrick ------------------------------------------------------------------------ S P Engineering, Inc. | Large scale, mission-critical, distributed OO | systems design and implementation. pjm@spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA) > On Sep 17, 1:33 pm, MJT.Keijs...@gmail.com wrote a message and was too > soon to send :-), Full text below: [quoted text clipped - 48 lines] > > Marc I think you are confusing two functions of C/C++ world with the Java world. in C/C++ .h files can specify an interface and/or a namespace. binaries compiled against the namespace can have the implementations swapped out without recompiling. in Java interfaces do not do this, they allow any class that implements the interface to be used in the same code. This is statically typed polymorphism - not what you want. what you want to do in this case is not to make a interface and then an implementation class, but just make a class in a specific package and have your jar provide that. Example: // the main program import org.marc.Math; ... int x = Math.myAdd(3, 4); ... // first revision of the class. this is in your jar package org.marc; class Math { public static int myAdd(int a, int b) { return a - b; } } // the bug is found and fixed, now remake the jar with this code, and swap out the old jar with the new one in the classpath (like the loadpath, but for java). package org.marc; class Math { public static int myAdd(int a, int b) { return a + b; } } to tie it all together, "org.marc.Math" is the "interface", but don't use the term in Java because it already exists for another purpose. MJT.Keijs...@gmail.com wrote: >> In an engineering world where I used to be working with C++ I am now >> shiftnig to Java. In C++ I would publishe my interfaces in header >> files. In Java I can use the interface concept. >> However this is not sufficient for me. I want to be able to full >> separate the implementation from the interface of e.g. a class >> method. > I think you are confusing two functions of C/C++ world with the Java > world. [quoted text clipped - 10 lines] > an implementation class, but just make a class in a specific package > and have your jar provide that. Another approach you should google is "Dependency Injection" (DI), a.k.a. "Inversion of Control" (IOC), whereby you instantiate a class at runtime conforming to an interface, with the implementation specified by a runtime resource (e.g., deployment descriptor). All calls to the class are via interface-specced methods, grabbing an instance of that implementation via a (perhaps static) factory method that accesses the resource and delivers up a conformant instance. This turns out to be somewhat more flexible and powerful than the C++ header mechanism, once you get used to thinking of it this way.  SignatureLew On Sep 17, 1:33 pm, MJT.Keijs...@gmail.com wrote: > Hi, > > In an engineering world where I used to be working with C++ I am now > shiftnig to Java. In C++ I would publishe my interfaces in header > files. In Java I can use the interface concept. > However this is not sufficient for me. If you want to have C++ use C++. >In an engineering world where I used to be working with C++ I am now >shiftnig to Java. In C++ I would publishe my interfaces in header >files. In Java I can use the interface concept. >However this is not sufficient for me. I want to be able to full >separate the implementation from the interface of e.g. a class method. What is the limitation of Java interfaces? The equivalent of publishing C++ H files is publishing the Javadoc. SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com >>In an engineering world where I used to be working with C++ I am now >>shiftnig to Java. In C++ I would publishe my interfaces in header [quoted text clipped - 4 lines] > What is the limitation of Java interfaces? The equivalent of > publishing C++ H files is publishing the Javadoc. Not really. It's the equivalent of publishing the Java interfaces without any implementing classes. Regards, Patrick ------------------------------------------------------------------------ S P Engineering, Inc. | Large scale, mission-critical, distributed OO | systems design and implementation. pjm@spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA) Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.