Functionality or interaction?

Thread view:

Aned - 04 Oct 2006 23:48 GMT

Is there any way to distinguish between methods that are responsible
for the communication between components(i.e. classes) and methods
that are responsible for providing the real computation?

Reply to this Message

Matt Humphrey - 05 Oct 2006 01:10 GMT

> Is there any way to distinguish between methods that are responsible
> for the communication between components(i.e. classes) and methods
> that are responsible for providing the real computation?

At the finest level, everything the computer does is computation. You could
say that a method that does not invoke methods on other objects has no
communication, but it's virtually impossible to do anything interesting (at
a high enough level of abstraction) using only primitives and assignment.

Matt Humphrey matth@ivizNOSPAM.com http://www.iviz.com/

Reply to this Message

Patricia Shanahan - 05 Oct 2006 01:55 GMT

> Is there any way to distinguish between methods that are responsible
> for the communication between components(i.e. classes) and methods
> that are responsible for providing the real computation?

Difficult in most cases, except through identifier and comments. Also,
it is a somewhat fuzzy concept.

In floating point programs, such as many scientific and engineering
programs, the methods that do the real computation are those that do
lots of floating point arithmetic.

Similarly, in an editor it may be possible to identify methods that
directly access or modify the data structure representing the material
being edited.

Patricia

Reply to this Message

Simon Brooke - 05 Oct 2006 10:21 GMT

> Is there any way to distinguish between methods that are responsible
> for the communication between components(i.e. classes) and methods
> that are responsible for providing the real computation?

A method exposed as an API (thus responsible for communication) should be
both public and usually not final. A method which is intended for internal
computation will be protected or private, and, if protected, may be final.

But note that a lot of people are less rigorous about this sort of thing
than perhaps they ought to be.

Signature

simon@jasmine.org.uk (Simon Brooke) http://www.jasmine.org.uk/~simon/
Das Internet is nicht fuer gefingerclicken und giffengrabben... Ist
nicht fuer gewerken bei das dumpkopfen. Das mausklicken sichtseeren
keepen das bandwit-spewin hans in das pockets muss; relaxen und
watchen das cursorblinken. -- quoted from the jargon file

Reply to this Message

Lew - 06 Oct 2006 04:46 GMT

> A method exposed as an API (thus responsible for communication) should be
> both public and usually not final.

Why should a public method usually not be final?

- Lew

Reply to this Message

Chris Uppal - 06 Oct 2006 11:54 GMT

> > A method exposed as an API (thus responsible for communication) should
> > be both public and usually not final.
>
> Why should a public method usually not be final?

Depends on whether you subscribe to the thesis that all methods should be final
unless they have been specifically designed to be overridden. I don't myself,
but I do think there's a lot to be said for the idea.

If you don't, then the reason is simply that methods should usually not be
final unless there is a specific reason to make them so.

BTW, there is another thesis to the effect that an object should not invoke its
own public methods unless they are intended specifically to be overridden. If
you do follow that pattern (which I admit I don't, though I probably should
make more effort to do so), then overriding public methods is always safe, so
there is no reason to make them final.

-- chris

Reply to this Message

Functionality or interaction?

Free Magazines