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-256) Overuse of OO types
Date Wed, 06 Sep 2006 09:46:22 GMT
Overuse of OO types

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

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

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_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.
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