Software Engineering - Can public data records (or structs) be passed in an OO system?

Author

Can public data records (or structs) be passed in an OO system?

T. Hoskins

2004-08-23, 3:57 am

I have heard several arguments for the use of structs for data passing
in a system I am helping to develop that was developed using an OO
approach.

Is any use of a public record (struct) forbidden in OO (even raw data
passing)?

Here's some arguments:

For cases when you are simply passing raw data from one component
class to another, there is no need to make the data being passed a
class. In other words, having raw data classes isn't necessary.

Having a "data class" that just has Gets and Sets of the same exact
name as the data attributes is a waste. No real abstraction is
occuring. If you change the attributes, the accessors would have to
change to reflect the attribute changes.

In all the OO courses that I have taken, this particular nuance was
never really addressed. It was just a given that all entities were
classes. It seems like a legitate argument though that if you are
simply talking about raw data passing (no underlying logic at all),
the use of a public record (struct) could be used.

Thoughts?

Phlip

2004-08-23, 3:57 am

T. Hoskins wrote:

> I have heard several arguments for the use of structs for data passing
> in a system I am helping to develop that was developed using an OO
> approach.
>
> Is any use of a public record (struct) forbidden in OO (even raw data
> passing)?

The point of modern programming - including OO - is to make changes safe.
The OO rules help when for a given change you know which code must be
inspected and verified afterwards.

The short answer to your question - if you can pass a single datum, such as
an int, why can't you pass an aggregation of data?

> Here's some arguments:
>
> For cases when you are simply passing raw data from one component
> class to another, there is no need to make the data being passed a
> class. In other words, having raw data classes isn't necessary.

Right. C++ helps when you use the 'struct' keyword to mean a bucket of data,
and 'class' to mean a bucket of behaviors.

If those things you pass have no behavior, then your classes themselves must
perform the behaviors, and they are responsible for their own encapsulation.

> Having a "data class" that just has Gets and Sets of the same exact
> name as the data attributes is a waste. No real abstraction is
> occuring. If you change the attributes, the accessors would have to
> change to reflect the attribute changes.

Right. Even if you wrapped all data in Get/Set pairs, when you change how
those Getters and Setters behave you must still inspect all clients of those
classes to ensure they don't break.

(However, /Smalltalk Best Practice Patterns/ and get into the Variable State
pattern. It turns the argument around, and treats a record as a class
capable of Getting and Setting a list of variables by name. GUIs use these
all the time as Properties, Configurations or Attributes.)

> In all the OO courses that I have taken, this particular nuance was
> never really addressed. It was just a given that all entities were
> classes. It seems like a legitate argument though that if you are
> simply talking about raw data passing (no underlying logic at all),
> the use of a public record (struct) could be used.

Your courses probably also neglected automated testing. That is much much
much more important than fretting about tangential ways to reduce a defect
rate.

Encapsulation is hierarchical. The ultimate problem is not naked data, it is
globally accessible primitive things.

--
Phlip
http://industrialxp.org/community/b...tUserInterfaces

Sponsored Links