OOP and "Manager" Classes for Common Code🤔

[maskedmelon]

If I am writing a piece of software and it is going to have many instances of a few different types of objects is it better to aggregate common/repetitive code for updates into a "manager" type class than having all that code replicated across hundreds or thousands of objects?

For example, if I have an object, say, a Collider and it contains a collision box and maybe a method for correcting position on collision, is it better to implement the code for detecting collisions within that object or within a separate CollisionManager class that could iterate over all active colliders to check for collisions?

I wouldn't think it would make a difference either way for speed, but it seems liek it would use a lot less memory to house all the collision code in a single instance than duplicating it across many objects.

[loramin]

Originally Posted by maskedmelon [You must be logged in to view images. Log in or Register.]

If I am writing a piece of software and it is going to have many instances of a few different types of objects is it better to aggregate common/repetitive code for updates into a "manager" type class than having all that code replicated across hundreds or thousands of objects?

For example, if I have an object, say, a Collider and it contains a collision box and maybe a method for correcting position on collision, is it better to implement the code for detecting collisions within that object or within a separate CollisionManager class that could iterate over all active colliders to check for collisions?

I wouldn't think it would make a difference either way for speed, but it seems liek it would use a lot less memory to house all the collision code in a single instance than duplicating it across many objects.

C, C++, C#, or whatever it is you're using, isn't my wheelhouse. I'd tell you to abandon OOP entirely and take a functional approach ... but then I'm a Javascript programmer. I learned C back in college, but that was about as long ago as the original classic EQ.

Even so, this sounds wrong:

Originally Posted by maskedmelon [You must be logged in to view images. Log in or Register.]

it seems liek it would use a lot less memory to house all the collision code in a single instance than duplicating it across many objects.

Generally the idea of classes is that their code lives in exactly one place: on the class. It's not like every class's methods gets copied with every instance you create. Instead, all your instances just have a single pointer back to the class, and it doesn't matter whether that class has one or a thousand methods. In other words, no matter how many instances you create, there is no duplication, only new pointers to the same existing code.

But again, not a C guy, so maybe it works differently? I'd just be surprised if it did.

If my understanding is correct, this is really more a code organization/architectural issue than a memory optimization one, and you should choose whichever approach best fits your application.

[maskedmelon]

Originally Posted by loramin [You must be logged in to view images. Log in or Register.]

C, C++, C#, or whatever it is you're using, isn't my wheelhouse. I'd tell you to abandon OOP entirely and take a functional approach ... but then I'm a Javascript programmer. I learned C back in college, but that was about as long ago as the original classic EQ.

Even so, this sounds wrong:



Generally the idea of classes is that their code lives in exactly one place: on the class. It's not like every class's methods gets copied with every instance you create. Instead, all your instances just have a single pointer back to the class, and it doesn't matter whether that class has one or a thousand methods. In other words, no matter how many instances you create, there is no duplication, only new pointers to the same existing code.

But again, not a C guy, so maybe it works differently? I'd just be surprised if it did.

If my understanding is correct, this is really more a code organization/architectural issue than a memory optimization one, and you should choose whichever approach best fits your application.

hmm, so the only thing housed in an instance are the fields/variables and a pointer for methods? It took a few hundred-thousand instances of one object to reach around 600mb memory, so I suppose that makes sense. Would also make sense why static methods aren't favored much.

[maskedmelon]

oo yeah, found a diagram on stackexchange that depicts the same thing you said, Lor ^^;

Glad memory isn't really an issue, but still curious about best implementation though. Going to give it some more thought.

[mickmoranis]

0010101110101001010101000101001011

lol

[loramin]

Originally Posted by maskedmelon [You must be logged in to view images. Log in or Register.]

oo yeah, found a diagram on stackexchange that depicts the same thing you said, Lor ^^;

Glad memory isn't really an issue, but still curious about best implementation though. Going to give it some more thought.

I really think you would benefit from reading a good programming theory book. My personal favorite in that category is Martin Fowler's Refactoring. It's a bit dense and a little old, but you don't have to read it cover to cover, and the principles in it don't go out of date. Also it uses Java, but 95+% of it's ideas aren't language-dependent, and Java's syntax is very similar to C. The subtitle of the book is "Improving the Design of Existing Code", so it might not seem applicable to you and your new code, but ...

Basically the book is a giant collection of "refactorings", ie. ways to take code written one way and re-write it in a better way without altering what it actually does. It also contains a chapter on "code smells", ie. patterns/signs that some code likely should be refactored. But most importantly, it doesn't just tell you what smells and refactorings to use: it tells you why, in a very well-thought out and logical fashion.

When you start to learn how to identify "smelly" code patterns, how to improve them, and most importantly why you want to take your code from version A to version B, it really helps you build a better sense of "I should architect this code that way because of X principle".

For instance, I just flipped to a random page for "Replace Constructor with Factory Method". He spends about half a page explaining how to do the refactoring, half a page on why you'd want to, and three pages of examples that clarify both making the actual code changes and why you'd want to. After reading it you have a much better understanding of when you would be better off with a factory method, and you can use that knowledge even when you're writing new code, not just to convert an existing constructor.

If Fowler isn't your speed another really popular title (that I haven't gotten around to reading) is Code Complete. And there are plenty of other good ones, but the point is that if you learn from really experienced people what patterns have costs and benefits, it equips you much better to make architectural decisions on your own.

[Irulan]

Unless you're doing cool math god and calling the hardware directly, there's not a huge performance difference in modern C compilers i guess, based on my most anecdotal cursory experience between your examples

So it kinda boils down to readability and management

[America]

all the code in the world cant spark this blunt in my hand. not even the leetest russian ukrainian czech datapirate coin miner on earth can blaze me up rn. perspective wisdom.

sometimes the best option is the 1 that "just werks"

[mickmoranis]

what if someone makes a blunt delivery by drone app tho?