I have a tricky python structure issue that I can't quite wrap my head around.
Reading in large files is being pulled out of our application code and into its own package. It used to be that one class, lets call it Object
, would be used to access file properties, and be passed around our Application
. So Application
package would call Object.datetime
, but now would have to call Object.file_handler.datetime
. So I have a few options:
For every property in
FileHandler
, create a property inObject
that just references thefile_handler
object. So inObject
do:@property def datetime(self): return self.file_handler.datetime
This looks really gross because there are dozens of properties/functions, and it's super tight coupling. This is our current solution.
Find a way to copy those functions/properties automatically. Something like:
for property in self.file_handler: create self.property with value self.file_handler.property
Due to the size of files this MUST be a reference and not a memory copy.
Go through the application and replace every call to
self.object.property
withself.object.file_handler.property
. SinceApplication
is production level code, this is a big ask. It could break other things that we haven't touched in a while (unit tests exist but they're not great).Restructure everything.
FileHandler
must be in a different package, and I don't want to copy/paste the functionality intoApplication
. I can't haveObject
extendFileHandler
becauseObject
representsFileHandler
at one instance in time (it makes my head hurt; basicallyObject
is anApplication
instance and there are multipleApplication
s run perFileHandler
object;FileHandler
objects are passed toApplication
through an iterator). I needObject
becauseFileHandler
can't implementApplication
features - they should have been two classes in the first place. If someone is interested in this let me know and I can provide more structural details, but I'm leaning towards a hacky one-off solution.
This is a software design problem that I can't seem to crack. I recognize that our code is fragile and not well designed/tested, but it is what it is (most of it predates me, and this isn't a Software Engineering team - mostly math/physics people). Does anyone have guidance? Option 2 is my favorite but I can't find code to make it work.