Binding new methods to hou classes // importance of OOP for FX TD

[ikoon]

I am quite a Python noob, so I may be using wrong terminology.

My situation:
 - I define my scripts as "independent methods" in .py files, and I import those files
 - I run those methods from the Tab menu or from the Shelf (with hotkeys), or from HDA buttons
 - more and more often I import "smaller" methods into "bigger" methods
 - my "way of organisation" is simple: I keep methods of one kind in one .py file with a descriptive filename
 - some methods add functionality to hou.Node, hou.PathBasedPaneTab, or so

Please, should I start to bind methods to hou classes?

Should I define my own classes?

Is this an important milestone in the "evolution" of FX TD, to move from Python scripting to Python OOP?

[symek]

It really depends on a case, but whatever is your case DO NOT* bind your own methods to Houdini classes.

Classes are often considered to be overused. Lots of code uses OOP without real merit. If you're now in a 'free functions world', it's generally good place to be, as long as you don't have hundreds of methods passing around things, which could easily be a state of the class instead.

Now, the thing is, state is handy, tempting, but state is also evil, specially in Python, because it doesn't have a concept of privateness. If you can avoid keeping your states and methods in one place (classes), it is usually considered advantageous. Code becomes usually more verbose, but also cleaner, safer and MUCH more resilient to breaks caused by changes (obviously at some point it becomes strange and obsessive to avoid classes, so choose you pill carefully). Python modules and namespaces actually mitigate the main reason of overdosing classes, which is the urge of young programmers to keep methods organized in one place (reason for which classes should NOT be used).

As much as this doesn't look OOP , you can do things like:

obj = hou.Node(...) # some python object

obj = my_sexy_module.do_something(obj, **params)

obj = my_sexy_module.do_something_else(obj, **params)

and it's totally valid way of doing things.

You should be worried if you start seeing things like:

obj = do_something(obj, my_secrets, **params)

obj = do_something_else(obj, my_secrets, **params)

which basically means you start passing around state which should be kept by the class:

obj = MyObject(hou.Node(...))

obj.do_something(**parms)

I don't mean to alienate you with OOP, but if you feel like you're doing fine without them, don't bother. It's not like they're obligatory

 

EDIT:

* - bacause every reasonable person would/should assume that whatever comes after hou.* is SESI land not third party. Then idiom is:
 

from jiri import shelftools as tools

objs = tools.do_funcy_stuff_with_objs(hou.node("/obj"))

 

Edited June 2, 2020 by symek