Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.programming > #4797

Re: Two object oriented methods, which is better?

From Kaz Kylheku <kaz@kylheku.com>
Newsgroups comp.programming
Subject Re: Two object oriented methods, which is better?
Date 2014-09-18 19:24 +0000
Organization Aioe.org NNTP Server
Message-ID <20140918115941.364@kylheku.com> (permalink)
References <lvf8uf$o09$2@speranza.aioe.org>

Show all headers | View raw


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.

Back to comp.programming | Previous | Next — Previous in thread | Find similar | Unroll thread


Thread

Two object oriented methods, which is better? Victor Porton <porton@narod.ru> - 2014-09-18 21:40 +0300
  Re: Two object oriented methods, which is better? Melzzzzz <mel@zzzzz.com> - 2014-09-18 20:46 +0200
    Re: Two object oriented methods, which is better? Kaz Kylheku <kaz@kylheku.com> - 2014-09-18 18:59 +0000
      Re: Two object oriented methods, which is better? Melzzzzz <mel@zzzzz.com> - 2014-09-18 21:08 +0200
        Re: Two object oriented methods, which is better? Kaz Kylheku <kaz@kylheku.com> - 2014-09-18 19:26 +0000
  Re: Two object oriented methods, which is better? Kaz Kylheku <kaz@kylheku.com> - 2014-09-18 19:24 +0000

csiph-web