axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Samisa Abeysinghe (JIRA)" <>
Subject [jira] Created: (AXIS2C-258) Using facroty in object creation
Date Wed, 06 Sep 2006 09:54:22 GMT
Using facroty in object creation

                 Key: AXIS2C-258
             Project: Axis2-C
          Issue Type: Improvement
    Affects Versions: Current (Nightly)
            Reporter: Samisa Abeysinghe

In some cases where we are using OO types, we are losing the benefits we
should be getting by using them, because of the way we are constructing
objects.  The typical situation is when you have a set of related
objects of the same or different types, which are constructed by
function calls from multiple locations in the code, and where the
implementation of each object in the set cannot be changed

Let's take Axiom as an example.  The idea is that the user of Axis2/C
can plug in their own implementation, and then all the code will use
that.  A single process should be able to use one implementation for one
document and another implementation for another document.

For the implementation to work, you can't change the implementation of a
single node in the document independently of all the other nodes.  All
the nodes in a document have to be of type axiom_node_impl_t.  The
problem is that the function calls that create nodes are scattered
throughout the code-base, and all create nodes of a particular, fixed
implementation type. So at the moment we are getting no benefit from the
use of OO types: we are just as tied to a single implementation type as
if we had not used OO types at all.

The general solution is to use a factory.  A factory is an object with
methods to create one or more types of object.  Nodes are created by
calling methods on the factory object.  To use a different
implementation, you just change a single function call, the call that
creates the factory.

In the particular case of Axiom, there's an easier solution which avoids
the need to pass around a factory all the time. Just allow the node (or
perhaps the document, as in the DOM) to be used as a factory.  This is
particularly easy because most of the functions that create a node have
already have a parent node as an argument.  So it's just a matter of
changing functions into methods.

So when you are creating a document from an input stream, the process

- call a function to create a stax_builder object

- use a method on the stax_builder object to get the document

- use methods on the document/node to do any programmatic node creation
of nodes to go in that tree

When creating a document completely programmatically:

- call a function to create document object

- user methods on the document/nodes to do any programmatic node
creation of nodes to go in that tree

(based on comments by James)

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message