Maintainable way for keeping objects in memory

Question

I am trying to figure out the best way to keep objects in memory without having them scattered everywhere within the code.

For example: I have a PyQT menu system which interacts with objects. Currently, these menus are able to create and modify an object by hitting code outside of their menu-related files, but afterwards the objects are being held inside the menu objects themselves.

e.g.

from foo_obj import Foo

class Menu
foo = Foo()
...

Some objects that need to be accessed from multiple menus sit in their own file where they are saved to a variable and imported into the "highest-level" file (main.py) so they aren't destroyed till the program terminates.

I'm sure this is not the best way to go about this. I have heard of MVC design and I have tried to follow something like that where almost all controller logic such as modifying the objects, conditionals, etc. are in their own "controller-like" files, and menu files are almost entirely views. Unfortunately, the issue still remains that I cannot find a good way to store these objects without creating some sort of abstract concept like object_container.py.

What is a good approach for this type of issue?

Answer 1

Some objects that need to be accessed from multiple menus sit in their own file where they are saved to a variable and imported into the "highest-level" file (main.py) so they aren't destroyed till the program terminates.

I'm sure this is not the best way to go about this.

This is exactly what Dependency Injection tells you to do. Mark Seemann called where you do this the CompositionRoot. The only reason he didn't just call it main was because some screwball frameworks don't let you code in main. They make you code somewhere below that. He's saying even so, compose your objects as high up the call stack as you can. Also, you don't need some fancy dependency injection container framework to make this work either. Pure-DI, as he calls it now, is really just good old fashioned reference passing dressed up with a fancy name to sell books and software. But the pattern of constructing and composing long lived objects up high even if you use them down low has been around a long time. It still works just as well today, fancy name or not.

Now that doesn't mean you can't use creational patterns like abstract factory. It means that objects meant to live as long as the program should start (and end) life at your composition root (main). After you're done building them you call one method on that thing you built and start it ticking. That seperates construction code from behavior code.

MVC has nothing at all to do with any of that. That's about separating responsibilities into separate components so they can change independently. MVC is old. It doesn't speak to anything else. It doesn't know when to create these components or how to let them talk to each other. Back when we invented it we had no clue how objects should talk to each other. That's how old it is.

There are other patterns that do talk to this issue that may be worth studying. One is Domain Driven Design. It talks about an constructing an aggregate root that takes care of this problem. It has rules about isolating it from the other aggregates that reside in other domains.

There is also Clean Architecture that tells you to build an object graph that follows the dependency inversion principle all at once and lets layers talk to layers through abstractions. You're free to build this object graph all at once and then start it ticking. No container or aggregate required.

In any of these cases you should be able to build the things that go in your menu, then build your menu and pass those things into the menu.

There are other container schemes like service locator. The main problem is they can end up forcing a lot of other code to know that the service locator exists. This is bad simply because the less an object knows about the fewer things can hurt it when they change. Create enough brittle objects and soon you won't be able to make changes. You won't want to touch the code because every time you do it breaks.

So yes, there are ways to go wrong here. But you have some decent ways to go right.