Software Engineering - Passing Ptrs to Complex Private Attributes in OO System

Author

Passing Ptrs to Complex Private Attributes in OO System

T. Hoskins

2004-08-29, 8:56 pm

An issue I have run into recently involves the passing of pointers to
private attributes (via interface), which are complex types (class
objects).

Some of my colleagues have stated that such a thing may "break OO
rules", but others don't agree. I am inclined to agree with the
latter.

In this example, the attribute is a fairly complex class object, which
is fed by multiple components (each generally set different aspects of
the object in question, with some overlap). It seems inefficent to
have have each component do a "Get" to retrieve the current attribute
state, use the class interface of the attibute class to set the
appropriate values, and then do a "Set" to set the attribute state.
However, I am wondering if I am tainted by past experiences, since
there does seem to be some validity to the fact it negates the
attribute being "private" if you can retrieve a pointer to it once
using an interface, and then make changes to it in the future without
accessing the class interface again.

It should be noted that there is no way to set the ptr, only get (no
way to change the actual address).

Is there any OO gurus out there that can shed some light on the
subject?

Tim Haughton

2004-08-30, 8:57 pm

"T. Hoskins" <jnthoskins@yahoo.com> wrote in message
news:7bd30012.0408291452.10737e8e@posting.google.com...
> An issue I have run into recently involves the passing of pointers to
> private attributes (via interface), which are complex types (class
> objects).
>

So you have this kind of thing...

class Foo
{
private:
Bar* m_bar;

// Some other stuff

public:
Bar* getBar()
{
return m_bar;
}
};

Is that right?

> Some of my colleagues have stated that such a thing may "break OO
> rules", but others don't agree. I am inclined to agree with the
> latter.

Any rule in particular? I presume they're talking about encapsulation.

The thing about OO, the big payback, comes when a developer wants to take an
interface, take some behaviour, and vary that behaviour independent of that
interface. OO is great for that. Inheritance, polymorphism and encapsulation
are all ways of achieving this payback.

There are 'rules' governing just about every aspect of OO programming. It's
OK to break any of them if, in doing so, you find a simple solution to a
particular problem. If your rule breaking causes you pain, it's time to
start following the relevant rules in the parts of your code that are
causing you problems.

>
> In this example, the attribute is a fairly complex class object, which
> is fed by multiple components (each generally set different aspects of
> the object in question, with some overlap). It seems inefficent to
> have have each component do a "Get" to retrieve the current attribute
> state, use the class interface of the attibute class to set the
> appropriate values, and then do a "Set" to set the attribute state.
> However, I am wondering if I am tainted by past experiences, since
> there does seem to be some validity to the fact it negates the
> attribute being "private" if you can retrieve a pointer to it once
> using an interface, and then make changes to it in the future without
> accessing the class interface again.

All developers are tainted by past experience. We're human. It seems
counterintuitive, but often the best thing to do, is to 'reset' your
learning from project to project. Allow yourself to fall foul to low
encapsulation, high coupling etc., but only once. When you feel the pain,
swoop in with your knowledge of textbook OOP and remove the pain. This way,
you'll have a code base that has just the right amount 'textbook OO'. Too
little causes pain, too much is expensive.

With respect to the point in question, one possibility that comes to mind,
is that rather than exposing a pointer to a private member, have your two
classes implement a common interface, and your outer class can delegate to
the inner class as neccessary - a standard composition delegation pattern.

[snip]

--
Regards,

Tim Haughton

Chief Technical Officer
Agitek Ltd
www.agitek.co.uk

Sponsored Links