How to separate interface from implementation when using JARs?  
Author Message
MJT.Keijsers





PostPosted: 2007-9-17 19:34:00 Top

java-programmer, How 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 {

 
Marc





PostPosted: 2007-9-17 19:43:00 Top

java-programmer >> How to separate interface from implementation when using JARs? On Sep 17, 1:33 pm, email***@***.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




 
Hunter Gratzner





PostPosted: 2007-9-17 20:15:00 Top

java-programmer >> How to separate interface from implementation when using JARs? On Sep 17, 1:33 pm, email***@***.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++.

 
 
Patrick May





PostPosted: 2007-9-18 1:24:00 Top

java-programmer >> How to separate interface from implementation when using JARs? Marc <email***@***.com> writes:
> 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.

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.
email***@***.com | (C++, Java, Common Lisp, Jini, middleware, SOA)
 
 
Roedy Green





PostPosted: 2007-9-18 10:10:00 Top

java-programmer >> How to separate interface from implementation when using JARs? On Mon, 17 Sep 2007 04:33:50 -0700, email***@***.com wrote,
quoted or indirectly quoted someone who said :

>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.
--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
 
 
Patrick May





PostPosted: 2007-9-18 12:29:00 Top

java-programmer >> How to separate interface from implementation when using JARs? Roedy Green <email***@***.com> writes:
> On Mon, 17 Sep 2007 04:33:50 -0700, email***@***.com wrote,
> quoted or indirectly quoted someone who said :
>
>>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.

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.
email***@***.com | (C++, Java, Common Lisp, Jini, middleware, SOA)
 
 
Lew





PostPosted: 2007-9-19 6:18:00 Top

java-programmer >> How to separate interface from implementation when using JARs? email***@***.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.

franco wrote:
> 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.

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.

--
Lew