octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Musings about the chapter "OO-programming" in the docs


From: Alexander Klein
Subject: Musings about the chapter "OO-programming" in the docs
Date: Fri, 1 Apr 2011 13:22:00 +0200

Hello list,

I'm just starting to transform a homegrown library of procedural code to 
OO-octave, and while reading the respective chapter in the docs, I was really 
baffled about the complexity of some of the methods shown in the examples.

The text states that a class should define getters and setters, which is quite 
a good thing from an OO-point of view, but then goes on to define get and set 
methods for the example polynomial class that are superficially OO, but almost 
completely procedural under the hood. Set even goes so far as to process 
variable argument lists.

Maybe I'm missing something, but given the complexity of the conditional blocks 
for error trapping and all the slow string compares that happen in set - and in 
get as well - wouldn't it be much better to refactor the whole example to match 
common OO-design rules from languages like Smalltalk or Java?

Just this morning, I trashed some of the code that I had generated while 
working through the example, and reprogrammed it the OO-way (to each instance 
variable its own getter/setter method, short methods preferred) which resulted 
in a getter like this ...

function result = getVector ( a )

        checkGetterParameters ( "getVector", 1, nargin );

        result = a.vector;

end

... which hands off error trapping to a private method like that ...

function checkGetterParameters ( getter_name, nargin_should, nargin_have )

        e = nargchk ( nargin_should, nargin_should, nargin_have );

        if ( e )

                error ( "%s: %s", getter_name, e ) 

        end
end

... and makes life a whole lot easier.

I'm sure the author of the original OO-chapter had something in mind when he 
defined the examples the way they are now, but aside from the compatibility to 
graphics handles mentioned somewhere in the text, I just don't get it.

What am I missing?

Kind regards,

        Alex

-- 
Alexander Klein, Dipl.-Math.
TransMIT Zentrum für Numerische Methoden
Heinrich-Buff-Ring 44
35392 Giessen



reply via email to

[Prev in Thread] Current Thread [Next in Thread]