Hi, Sorry for not replying sooner, my email has been a little backed-up. The Java bindings that I supply are based upon interfaces with the intention that a client application could swap between implementations of those interfaces as appropriate. This works OK in my internal tests. However, defining factory methods for the creation of objects would simplify the process of swaping between implementations [the technical reason for this is that constructor methods cannot be defined by a Java interface - hence the requirement for defined factor methods which are consistently implemented]. I have not added factory methods to the Java bindings that I supply since I have attempted to be consistent with the strawman. Whilst the factory methods would be useful they need not be defined by the SAGA API, rather they could be an extention in the Java API. Graeme Quoting Pascal Kleijer <k-pasukaru@ap.jp.nec.com>:

Hi all,

In Java, a design pattern is defined by an Interface, like:

public interface Foo { ... public void foo (); ... }

public interface Bar { ... public void bar (); ... }

All methods in the interface are abstract (virtual in C++) and all attributes are static and global.

You can then implement this interface on any object. 1 object can implement more then one interface but cannot inherit of more then 1 class, as opposed to C++. Default inheritance is the Object class. That means you have to use the aggregation paradigm with interface to archives multi-inheritance.

public class MyFoo implements Foo, Bar { public void foo () { System.out.println ("Hello SAGA foo[l] ;p"); } public void bar () { System.out.println ("A bar of black chocolate!"); } }

public class AndreFoo implements Foo { public void foo () { System.out.println ("Hello Andre!"); } }

// Code Foo foo= new MyFoo(); foo.foo(); foo= new AndreFoo(); foo.foo();

If your program have different implementations of the same Foo interface that are supposed to do the same (API contract), that is possible, see Hidemoto's example. Like the XML parsers you can implement a SPI (Service Provider Interface) to access the different implementations without having to care about the full class names and locations (packages). Some default SPI are directly endorsed by the Java runtime, like the XML stuff.

I did not check the implementation yet, but it should be implicit that the implementation uses design patterns otherwise it will be a hard job to switch between implementations.

Best regards, Pascal Kleijer

Andre Merzky wrote:

...

Hi Hidemote, Graeme,

please excuse my ignorance - as said before, I am Java agnostic, and my question might be off target...

Hidemote mentioned the use of the factory pattern at GGF already, and other people I know which do Java issued similar statements.

How does that actually compare to other languages? E.g. in C/C++, you can usually link your code against a specific _API_ in a shared library - as long as a library implements the same API, there is no need to recompile (just exchange library).

Also, in C/C++ it is possible to implement an API with plugins: so you create a thin API layer, which forwards to dunamically loaded plugins, which can then provide different implementations of the API calls.

The latter way is what we actually do in our C++ implementation (plugins are called adaptors though).

The difference I see is actually that in both cases, the fact that the API is implemented by different vendors is completely hidden on API level, w/o the need for any additional patterns like factories.

So, is there a difference between these approaches? And if not: what is the advantage of the factory approach?

Thanks,

Andre.

Quoting [Hidemoto Nakada] (May 17 2006):

...

All,

I have a question on the Java Binding. Does the current Java binding include explicit factory notion?

Factory mechanism is important to - reuse a source code with several implementation of the API without modification of the code. - leverage several implementation simultaneously from one client code.

One good example of factory design can be found in the Dom parser definition; org.w3c.dom.DomImplementation. When you create a Dom document

- get a DomImplementation from org.w3c.dom.bootstrap.DomImplementationRegistory - then create a Document object using DomImplementation.

This mechanism might be too complicated for SAGA, but I think some flavor of this is required.

-hidemoto

Pascal, I will include an experimental factories interface in the next release demo how the plug-and-play aspect can work. Graeme Quoting Pascal Kleijer <k-pasukaru@ap.jp.nec.com>:

Hello Graeme,

...

Sorry for not replying sooner, my email has been a little backed-up.

Usual on the SAGA-RG ML ;)

...

The Java bindings that I supply are based upon interfaces with the intention that a client application could swap between implementations of those interfaces as appropriate.

This works OK in my internal tests. However, defining factory methods for the creation of objects would simplify the process of swaping between implementations [the technical reason for this is that constructor methods cannot be defined by a Java interface - hence the requirement for defined factor methods which are consistently implemented].

I have not added factory methods to the Java bindings that I supply since I have attempted to be consistent with the strawman. Whilst the factory methods would be useful they need not be defined by the SAGA API, rather they could be an extention in the Java API.

The SAGA group have not worked on any Java bindings L&F at the moment. This will be up to the bindings implementors. In fact the first arrived might set the standards for the others. In the current case I can say you are the first full implementation proposer. So that puts you in the defacto standard hat.

However it is clear that we need factories to create the different objects, at least for the main APIs. A model used for XML in Java is clean and works well. It can completely hide the implementation from the specification.

Since you have realized the first Java bindings it will be used as first draft for defining the factories behaviors and the general L&F. I still didn't have time to analyze the code. I hope it will come soon and be able to assess the work.

Pascal

...

Graeme

Quoting Pascal Kleijer <k-pasukaru@ap.jp.nec.com>:

...

Hi all,

In Java, a design pattern is defined by an Interface, like:

public interface Foo { ... public void foo (); ... }

public interface Bar { ... public void bar (); ... }

All methods in the interface are abstract (virtual in C++) and all attributes are static and global.

You can then implement this interface on any object. 1 object can implement more then one interface but cannot inherit of more then 1 class, as opposed to C++. Default inheritance is the Object class.

That

...

...

means you have to use the aggregation paradigm with interface to archives multi-inheritance.

public class MyFoo implements Foo, Bar { public void foo () { System.out.println ("Hello SAGA foo[l] ;p"); } public void bar () { System.out.println ("A bar of black chocolate!"); } }

public class AndreFoo implements Foo { public void foo () { System.out.println ("Hello Andre!"); } }

// Code Foo foo= new MyFoo(); foo.foo(); foo= new AndreFoo(); foo.foo();

If your program have different implementations of the same Foo interface that are supposed to do the same (API contract), that is possible, see Hidemoto's example. Like the XML parsers you can implement a SPI (Service Provider Interface) to access the different implementations without having to care about the full class names and locations (packages). Some default SPI are directly endorsed by the Java runtime, like the XML stuff.

I did not check the implementation yet, but it should be implicit that the implementation uses design patterns otherwise it will be a hard job to switch between implementations.

Best regards, Pascal Kleijer

Andre Merzky wrote:

...

Hi Hidemote, Graeme,

please excuse my ignorance - as said before, I am Java agnostic, and my question might be off target...

Hidemote mentioned the use of the factory pattern at GGF already, and other people I know which do Java issued similar statements.

How does that actually compare to other languages? E.g. in C/C++, you can usually link your code against a specific _API_ in a shared library - as long as a library implements the same API, there is no need to recompile (just exchange library).

Also, in C/C++ it is possible to implement an API with plugins: so you create a thin API layer, which forwards to dunamically loaded plugins, which can then provide different implementations of the API calls.

The latter way is what we actually do in our C++ implementation (plugins are called adaptors though).

The difference I see is actually that in both cases, the fact that the API is implemented by different vendors is completely hidden on API level, w/o the need for any additional patterns like factories.

So, is there a difference between these approaches? And if not: what is the advantage of the factory approach?

Thanks,

Andre.

Quoting [Hidemoto Nakada] (May 17 2006):

...

All,

I have a question on the Java Binding. Does the current Java binding include explicit factory notion?

Factory mechanism is important to - reuse a source code with several implementation of the API without modification of the code. - leverage several implementation simultaneously from one client code.

One good example of factory design can be found in the Dom parser definition; org.w3c.dom.DomImplementation. When you create a Dom document

- get a DomImplementation from org.w3c.dom.bootstrap.DomImplementationRegistory - then create a Document object using DomImplementation.

This mechanism might be too complicated for SAGA, but I think some flavor of this is required.

-hidemoto