[
https://issues.apache.org/jira/browse/AXIS2C-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Samisa Abeysinghe resolved AXIS2C-258.
--------------------------------------
Resolution: Won't Fix
This is an important design model that we should consider if we ever happen to
go for a 2.0 model. But not right now.
> Using facroty in object creation
> --------------------------------
>
> Key: AXIS2C-258
> URL: https://issues.apache.org/jira/browse/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
> independently.
> 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
> is:
> - 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.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
