Moving to an OOP model from an classically imperitive one

[tim.thelion at gmail.com]

> A reasonable compromise might be to keep the *data* assocated
> 
> with a SubuserProgram in a class, maybe together with a few
> 
> methods that are tightly coupled to it, but have the major
> 
> pieces of functionality such as install() implemented by
> 
> separate functions that operate *on* the class, rather than
> 
> being inside it.
> 

I think this is sound advice.  I'm still not sure what I'll come up with.

One of the other reasons why an OOP model might be right for me is that of caching.  I currently load a lot of attributes regarding programs from disk, and I do so multiple times, I could either pass those attributes around, OR, using a class, I could store those attributes in the object after loading them just once.  I have no experience with OOP except in the domain of GUIs(where it seems inescapable, all major toolkits use OOP), so I'm not yet sure how this will turn out.

Tim