[
https://issues.apache.org/jira/browse/AXIS2C-256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Samisa Abeysinghe closed AXIS2C-256.
------------------------------------
Resolution: Fixed
Fix Version/s: 1.0.0
Bulk of the overuse of OO has been dropped with the drop of the use of ops
struct.
> Overuse of OO types
> -------------------
>
> Key: AXIS2C-256
> URL: https://issues.apache.org/jira/browse/AXIS2C-256
> Project: Axis2-C
> Issue Type: Improvement
> Affects Versions: Current (Nightly)
> Reporter: Samisa Abeysinghe
> Fix For: 1.0.0
>
>
> I think we're using OO types too much. By an OO type, I mean a type
> which uses the pattern of being a struct with just a pointer to an ops
> struct of function pointers.
> Using an OO type has a significant cost, compared to a straightforward C
> approach. There's a cost in ease of use, code clarity, development
> time, ease of maintenance as well as in runtime performance. The
> overall cost of using an OO type in C is much higher than in Java or C++
> or other languages that natively support OO programming. An OO type
> should only be used in C in situations where there is a good reason to
> use them.
> The key criteria is whether code that uses the OO type might need to use
> different implementations of the type, where the choice of which
> implementation to use needs to be made at runtime. Some of the uses of
> OO types on Axis2/C do satisfy this (eg the Axiom node type). But
> equally it looks to me like there are many uses that do not satisfy this
> criteria.
> A typical example of something that I think should not be an object is
> axis2_http_request_line. Conceptually this is just a bundle of data
> (method, URI and HTTP version). I can't think of any reason why it needs
> to be an OO type.
> A good indication that this type really shouldn't be done in OO way is
> that there's only one implementation and the constructor for the
> implementation (axis2_http_request_line_create) is in the header file
> for the interface. Moreover a function that uses the object
> (axis2_http_request_line_parse_line) is in the same file as the
> implementation of the object. Thus in order to use a different
> implementation of the object, the request line parsing code would have
> to be redone. In short, in practice there's only going to be one
> implementation of axis2_http_request_line_t, so there's no point in
> doing it as an OO type.
> Certainly it be should be properly encapsulated, but it would be much
> simpler to just make it an opaque struct. In other words, the include
> file would look roughly like this:
> typedef struct axis2_http_request_line axis2_http_request_line_t;
> axis2_char_t *
> axis2_http_request_line_get_method(const axis2_http_request_line_t line,
> const axis2_env_t *env);
> axis2_char_t *
> axis2_http_request_line_get_http_version(const axis2_http_request_line_t line,
> const axis2_env_t *env);
> axis2_char_t *
> axis2_http_request_line_get_uri(const axis2_http_request_line_t line,
> const axis2_env_t *env);
> axis2_char_t *
> axis2_http_request_line_to_string(axis2_http_request_line_t line,
> const axis2_env_t *env);
> axis2_status_t
> axis2_http_request_line_get_free(axis2_http_request_line_t line,
> const axis2_env_t *env);
> axis2_http_request_line_t *
> axis2_http_request_line_create(const axis2_env_t *env,
> const axis2_char_t *method,
> const axis2_char_t *uri,
> const axis2_char_t *http_version);
> axis2_http_request_line_t *
> axis2_http_request_line_parse_line(const axis2_env_t *env,
> const axis2_char_t *str);
> This is:
> - much simpler for a user of the library
> - much simpler to implement
> (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]
