Rick:

It has been my experience that every individual Class definition should be as small and distinct as possible; this seems to increase its chance for reuse in other applications.

For instance, you should seldom Class a Form that includes textboxes, combos, labels, etc. Instead, Class the Form as empty, create various Textbox Classes, Combo Classes, etc. and combine these as needed. Always think in components like separate puzzle pieces.

Regarding Arrays, I have had success returning a parseable string instead of an Array from a Function and breaking out the information needed...

Just some ideas for you,

-Irv.

>Hello world,
>
>I want to rewrite some procedural code as OOP. My question is how far should I go with the rewrite? I am an OOP beginner, so I apologize if this is a dumb question.
>
>Currently, my procedural code looks like this:
>
>{begin}
>
> Open tables (lots)
>
> SELECT main table
>
> SCAN FOR condition
>
> DO Processing WITH aReturnValues, MainTableValues
>
> Write to main table and child table
>
> ENDSCAN
>
> Close tables
>
>{end}
>
>"Processing" (above) is a procedure with lots of called procs/functions. It would be a function, except the return values are in an array, and I do not know how to return an array from a function. (Is it possible to return an array from a function?)
>
>So the rewrite I have in mind would look like this:
>
>{begin}
>
> Open main table and child table
>
> myProc = CREATEOBJECT( "ProcessingClass" )
>
> SCAN FOR condition
>
> = oMyProc( @aReturnValues, MainTableValues )
>
> Write to main table and child table
>
> ENDSCAN
>
> Close main table and child table
>
> RELEASE oMyProc
>
>{end}
>
>To comply with encapsulation, the object would internally open all the tables it needs for processing.
>
>On the other hand, should I put EVERYTHING into oMyProc/ProcessingClass? Perhaps the whole sequence could look like this:
>
> = oMyProc()
>
>What do you think?
>
>Thanks,
>
>Rick Graves