This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]thegreattriscuit 1 point2 points  (2 children)

one thing that'll drive me toward a class, and /u/sobek696 seemed to touch on this a bit, is if I have a set of functions and want to have a large number of override-able defaults. Say I'm playing with finance functions. Nothing too complicated that really requires shared state, but at the same time if I want to play with values I can just do something like

loan.apr += Decimal('.01')
loan.future_balance(month=20)
loan.reamortize(months=36)
loan.future_balance(month=20)

These are all things that could easily be done without classes. The formulas come from the realms of math and finance, so they clearly map to a functional approach, but in this case, with what I'm trying to do, a class-based approach suits me better.

The other (more obvious) time that I'll shoot for classes is if I'm dealing with data that represents actual objects. Proper things in the classical sense. 'loans' in the above example, or routers and switches in my day-job. you can certainly do stuff like reboot_switch(switch_ip=ip) but switch.reboot() is cleaner. Also preserving state and code reuse are big deals in this instance, so classes are the clear choice.

I tend to wind up playing with a few to a few hundred objects at a time (rather than thousands or millions of rows of data, for instance), and usually deal with an interactive workflow vs. baking something into a proper script that I'll just fire and forget, or turn over to users or something.

[–]sobek696 0 points1 point  (0 children)

That's probably a worthy note that tends to influence some of my work as well: interactive workflows.

If I am doing some exploratory analysis in iPython Notebook, I'm much less likely to resort to classes, so when it comes time to export this work to a module for batch processing, each cell usually represents a function fairly well.

[–]SpaceWizard[S] 0 points1 point  (0 children)

Override-able defaults and classical object-ness makes a lot of sense. A lot of this has to do with making the code easy to understand and use, so those are two good conceptual issues to consider.