Now that I discover more about Python, I see that there many different ways to write your code. And it feels like we have next to our dominant default cube loads of other boxes were we can put stuff inside. To name a few: we could make a bunch of functions first, or we could make an hierarchy of classes, split or not split up modules, use or not use decorators, and a bunch more.
So it’s like knowing Python is not enough (it feels like I could make mistakes like storing a house in a drawer), and the next question is How do I use it efficiently. Does Design Patterns give an answer to that, or what is your experience?
The truest answer would be : I don’t organize my code.
My slightly more idealized answer would be: I define global variables, write everything as functions, and then call the functions with any needed local variables. I love functions, especially nesting them, it may not be the most memory efficient but it’s super easy to keep track of.
The general question of how to break up software into pieces so that it is understandable, maintainable, and efficient, is an art that one learns after many years of practice and review by more experienced programmers. One book that tries to distill and teach this learning is “A Philosophy of Software Design” by John Ousterhout, which I recommend. Though it is probably overkill for typical small Blender addons in Python. The book is about principles that apply no matter what language you are writing in.
You do this as you go. When it becomes hard to read or hard to work on, it’s usually not difficult to figure out why. I usually come up with a solution right then and there, regardless of whether it’s Python or something else. It’s quite difficult to give you a good complete answer here, because the good info on this is usually in some book I forgot the title of, and books about this appear by the hundreds every year.
I think some good principles for a beginner are:
don’t repeat yourself (aka DRY): if you have the same piece of code all over the place, it probably should be a function.
separation of concerns: a function should only do one thing, and not have extra side-effects. A mild case of this would be a function which sets a value but also returns it. An extreme case would be a function which reads a value from a database to return it, but while doing so also writes to the database.
To prevent the worst offense right away, please don’t try to wrap everything in a class. Objects have state (aka fields, aka members, aka properties, aka instance variables, aka aka aka), which is an abstraction that helps to bundle related data together, but it also obfuscates what the data is; think “When was this value last set? What is it going to be when my function uses it?”. It creates indirection: the worst contender for readability. Abstractions always trade readability for manageability, and they can often be a really bad deal.
Some design patterns will even directly contradict general principles. E.g. the builder pattern low-key violates separation of concerns, by continuously returning the same object on which you called a function, e.g.: HotdogBuilder().withMayo(LOTS).withKetchup(LITTLE).withOnions(DICED).build().
A good strategy is to not try to improve anything unless you have a strong feeling that you should. Good enough is good enough.