[saga-rg] Is there Factory in Java Binding?

[G.E.POUND at soton.ac.uk]

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 at 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 at 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
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >
> >
> >
> >
> >
>