is-a or has-a

Thread view:

Robert - 17 Feb 2005 21:01 GMT

Hello to all -

This isn't homework, although it might sound like it is. It's just
personal study.

If I were to author a class to handle socket communication for a
specific data object (widget) along the line of a specialized xml-rpc
class, I could see two ways of doing it.

In the first, I could derive the new class from a socket class
and add the methods getMyWidget() and sendMyWidget(...).

Or I could write a new class, add a socket member to it, encapsulate
it, and have a stricter set of methods with no loose inherited
stuff my app my not want.

Is this a is-a-socket or has-a-socket? Don't assume I know anything.
I'm new to OOP and want to make sure I have the concepts right.
I believe this is a has-a scenario as that will eliminate a lot of
inherited junk I don't care about. But then I'll be writing a lot
of accessor stuff, for example giving the application access to the
socket binding.

Which way is better?

Thanks in advance.

Reply to this Message

Tom Dyess - 17 Feb 2005 21:34 GMT

> Hello to all -
>
[quoted text clipped - 22 lines]
>
> Thanks in advance.

Unfortunately the answer is "depends." The benefits of inheritance (is-a) is
you can reuse interfaces of the superclass. This is beneficial if your
object will be using many of those same interfaces or you want your object
to "feel" like the superclass without having to re-implement the same
interfaces. On the other hand, if your superclass has alot of unnecessary
interfaces, it may seem overly complex to the user of your new object. The
benefits of aggregation/composition is a simplified object that only has the
interfaces needed by the user of the object.

For example, if you are using a (Linked)HashMap as your superclass, and all
you want to do is auto-cast your put and get methods, I would aggregate. If
you want to use the more complex interfaces of the superclass, I would
inherit and add your auto-casting interfaces. Using the (is-a) method will
allow you to use your object as a HashMap, while if you aggregate/compose,
you have to use a getter to get the HashMap for methods that want a
derivitave of HashMap. Clear as mud? PS: By interfaces, I mean
public/protected methods/variables. Let me know if this makes no sense and I
will try to explain it better.

By autocasting I mean:
public MyObject get(String key)

as opposed to

public Ojbect get(Object key)

by aggregation/composistion getter, I mean

HashMap getMap()

Signature

Tom Dyess
OraclePower.com

Reply to this Message

Andrew McDonagh - 17 Feb 2005 22:51 GMT

>>Hello to all -
>>
[quoted text clipped - 24 lines]
>
> Unfortunately the answer is "depends."

isn't it always ! :-)

> The benefits of inheritance (is-a) is
> you can reuse interfaces of the superclass. This is beneficial if your
[quoted text clipped - 4 lines]
> benefits of aggregation/composition is a simplified object that only has the
> interfaces needed by the user of the object.

An alternative approach would be to use a interface which limits the
methods available to clients, yet the implementing class derives from
the base class, saving it from having to provide the same methods.

The object would have to be passed around via its interface rather than
its actual class type. Only the place where it is instantiated needs to
know the actual class type.

...

public void someMethod() {

WidgetStore widgetStore = new WidgetStoreImpl();

widgetStoreUser.heresThe(widgetStore);
}
...

public interface WidgetStore {
void setWidget(Widget aWidget);
Widget getWidget();
}

public class WidgetStoreImpl extends Socket implements WidgetStore {

....lots of nice widget setting and getting via RPC
}

public class WidgetStoreUser {

public void heresThe(WidgetStore aWidgetStore) {
aWidgetStore.setWidget( myWidget);
}

}

Reply to this Message

Andrew McDonagh - 17 Feb 2005 22:37 GMT

> Hello to all -
>
[quoted text clipped - 7 lines]
> In the first, I could derive the new class from a socket class
> and add the methods getMyWidget() and sendMyWidget(...).

This would be 'is-a' socket.

> Or I could write a new class, add a socket member to it, encapsulate
> it, and have a stricter set of methods with no loose inherited
> stuff my app my not want.

this would be 'has-a' socket.

> Is this a is-a-socket or has-a-socket? Don't assume I know anything.
> I'm new to OOP and want to make sure I have the concepts right.
> I believe this is a has-a scenario as that will eliminate a lot of
> inherited junk I don't care about.

And this is usually a good thing. It decouples the client classes who
use the class from knowing 'how' the widget(s) at sent and received.

the class would need only getWidegt() and a setWidget() methods. The
fact that the implementation of those methods uses an RPC mechanism is
hidden from them.

But then I'll be writing a lot

> of accessor stuff, for example giving the application access to the
> socket binding.

You wouldn't have too. In fact its better that you didn't. Leave the
socket setup, usage & cleanup within this class, don't expose it to the
rest of the system.

If some other part of the system needs to 'control' when sockets are
initialised or torn down, then provide additional start() and stop()
methods on the class. These methods don't take any params, but allow
the rest of the system to control the comms, without knowing what type
of comms is being used.

> Which way is better?

Its generally better to favour encapsulation rather than inheritance.

Andrew

Reply to this Message

is-a or has-a

Free Magazines