Kaz Kylheku
9/18/2014 7:24:00 PM
On 2014-09-18, Victor Porton <porton@narod.ru> wrote:
> [Sorry for multiple postings, but traffic of comp.object is so low (as I
> found after my posting there), that almost nobody will suffer of my multiple
> posting.]
>
> If I want to push a specific (for a given subclass) value into an array
> argument of a method, should I just pass the value of the argument to a
> method which would modify it, or should I create a method which just
> returns
> the list of additional values (and use it in the first mentioned method)?
>
> Pseudocode (with "#" starting comments) for a method f:
>
> # modify_array is a dynamic method
> function f(object, array) {
> object->modify_array(array);
> }
>
> or
>
> # common_array_members is a dynamic method
> function f(object, array) {
> array = concat(array, object->common_array_members());
> }
>
> What is more object oriented? Which is better?
The second is more functional since it avoids destructively manpulating the
array object. (It assigns to a local variable, but that is a secondary concern
and removable.)
The second approach might be seen as less OO, because the responsibility for
the "modify_array" logic is in a non-OO function. The implementation of object
can only vary what it returns out of common_array_members, but has no say in
what modification is done with it.
However, that is just a perspective. We don't have to divide the world
into "regular function" and "OO function". If we regard f to be an OO
function, then this goes away.
We have a functional abstraction f(obj, array), which does something
appropriate based on the type of obj. The fact that f is a wrapper
which invokes methods and performs some of the logic is immaterial to the
caller. When the object framework grows more complicatd, the logic
which is done in f can be moved into a method, so that f becomes
a pure method wrapper.
This kind of thing is epecially of no concern in a language which doesn't
stupidly use different syntax for calling OO methods and regular functions;
f(obj, a) could start out being a regular function, and later be upgraded to an
OO method if necessary. The programmer doesn't have to scan the program
for f(x,y) syntax and convert to x.f(y); f(x,y) is the object-oriented call.
Also the functional aspect and OO aspect are orthogonal, because you can
have this:
function f(object, array) {
local new_array = object->generate_array(array); # do not modify
...
}
The responsibility for how the objectg and array are combined rests in
the method, and clobbering the array is avoided.