0

I have an object with a lot of methods. These methods can be grouped or clustered. Groups are e.g. 'model1', 'model2',..., which have methods like calc_density,calc_temperature, get_temperature,... Another group 'modify' would collect all methods to modify the data of the object (a dict).

Right now I have all methods in the single file, which will in future grow (roughly 50-200 methods). I "solve" the problem with adding the group name to the method name, which I think is not nice.

my_object.model1CalcDensity
my_object.model2CalcTemperature
my_object.modifyApplyLimits

Ideally, I would like to have a structure like

my_object.model1.CalcDensity
my_object.model2.CalcTemperature
my_object.modify.ApplyLimits

and the methods of a group should be in a separate file for each group. I know, how I would do this with simple functions in a module, but am not sure how this works with methods of an object. (But I have to admit that my Python knowledge is very limited) Is there a "standard" solution?

Georgy
  • 12,464
  • 7
  • 65
  • 73
baudri
  • 3
  • 3
  • 1
    Can't you define a separate class for each "group" of functionality, and give the "master class" properties which are objects of those classes. That would allow you to access the methods in exactly the way that you say you would "ideally like". – Robin Zigmond Apr 11 '19 at 08:21
  • I think I am not familiar enough with OOP to fully understand your proposal, since I come from CFD modelling in FORTRAN. The object right now holds the data like the composition and the methods add the properties (density, temperature,..) to this dataset for each group or modify the composition. Would this work with your idea? Where can I find an example for your scenario? – baudri Apr 11 '19 at 08:38
  • Could you clarify more on the "modify" group? It's not clear what you mean by "*collect all methods to modify the data of the object (a dict)*". – Georgy Apr 11 '19 at 21:06
  • @baudri As a shortcut to OO design, group methods that act on the same data together with the data. I forgot who said it, but think of an object as a private scope for data and the methods that operate on them. – RWRkeSBZ Apr 11 '19 at 21:13
  • ...and by the way, welcome to SO! – progmatico Apr 14 '19 at 18:15

1 Answers1

0

It looks you know how to partition your code with modules and functions. If you turn my_object into a package you can achieve exactly the wanted syntax by groupng your functions inside different modules in the package and then importing the package from the outside of it. A module or a package is still an object so that may suffice and be the easiest path for you.

If instead you go OOP style, in OOP design you don't partition a single object (or class) through several files. You actually restrict any class to have only 5 to 7 methods, so you never really have to partition a big class and you think how you group classes in modules or packages based on relationships they have with each other, their goals and such. Having several different classes in the same module is also common in Python. You think how to partition functional groups inside a system (or sub-system) and then choose appropriate classes.

If you were to partition a class, that's because you already made the mistake of writing a "giant class". Like converting a classic modular program by just wrapping it in a big App object. Sometimes classes get bigger than they should. The corresponding objects are also referred as "God objects" because being bigger means more knowlegde is kept inside. They should be rewritten.

This could go more or less in the line of Rob Zigmond comment, if you still want a single object holding all the functions, although by the 5 to 7 limit that's not recommended. Note also that this limit is based in our memory abilities. You'll remember such of small group of methods for each object, but not a 50-200 method list.

For the classic module/package way, see here as an example I answered. The imports don't use the dot because they are relative which is common practice but you can just import the top module and then dot through the attributes inside.

progmatico
  • 4,714
  • 1
  • 16
  • 27