Reusable Code and how you deem it reusable quality

[KasHKoW]

Hey, I'm interested in reusable code. As I just started, I feel mines kinda bad. As it will improve obviously. But, I wanted to ask the community what type of functions/class/code do you typically find reusable? Why do you deem it reusable, and What extends or inherits that code.

[Groogy]

I would say that something that is reusable is most often very compact and have a few dependencies. Simple examples would be implementations of data containers like growing array, tree's, heap's, graph's or even some algorithms as long as the interface is pretty clean.

Anyway something that you can cut-n-paste directly is reusable code if you ask me

Though if you cut-n-paste and then have to change a few things but not the actual functionality then it's also reusable but not as... erhm.. what is the word I am looking for. Self-contained as the previous example?

[Nexus]

When you design a new class or function, reflect on how it is going to be used. Try not to limit it to a single special case. Empathize with other people that should use your code, and make sure it is intuitive to use. Keep public interfaces small, don't introduce functionality just because it might be useful one day. Reuse existing solutions from the standard library and Boost instead of handcrafting your own. Aggregate similar functionality by using C++'s abstraction mechanisms.

Further design tips can be found here. Maybe you should read an advanced C++ book such as Effective C++.

[keyforge]

Nexus, I'm writing a 3D game engine and I'm using Singleton's for my Resource Manager, Physics Manager, and State Manager, would this be a bad design pattern? It's useful to access textures and change states between classes.

[Nexus]

I wouldn't generalize that, but I think the Singleton pattern is one of those techniques that are often overused just "because they are helpful". It seems like they are the easier solution because they can be accessed from everywhere. There are of course situations where singletons are appropriate, but on the other side, there are drawbacks that are not obvious in the first place. Not every class of which there is only one instance needs to be a singleton. Some issues:

• Because a singleton is in principle a global variable, it increases the complexity of the program. There are more dependencies because you can access a singleton from everywhere, the responsibilities are not local anymore.
• This also makes maintainance and bugfixing more difficult, since user code in several places needs to be considered and access is harder to control.
• Global state is a problem when using multiple threads, since it needs locking, which again increases the code complexity and runtime overhead.
• Another problem with globals is the initialization and destruction order. As the C++ standard doesn't define it for global and static variables in different translation units, one has to be careful and use special techniques for singletons depending on each other.

[Contadotempo]

Regarding threads, what can be said about them?
Should they be used often? For example, to separate a physics manager from a resource loader.

I usually keep my programming very linear (no threading), especially because I've never learnt much about thread programming.
But for for advanced situations, where for example I have to deal with a lot of objects, should I start considering that?

By the way I don't mean to thread hi-jack. I tend to take these tips to heart and get pretty interested.

(Excuse my English)

[Groogy]

For singletons I agree with Nexus. They are more close to being an anti-pattern than actually being a design pattern. In my engine I have one root-singleton which is the application. Nothing more. Any other singleton is "Read-only" data like resource managers for textures, fonts, models and shaders.

But the general rule is, if you are getting more than one singleton class that you have to work with(not read from but actually do stuff with) then you are probably doing something wrong and it will eventually turn around and bite you in the ass.

Even as it is now for my game engine I Feel that I am having too many singletons because I have different resource managers, one for every type. So I might even redesign this to be all placed under one singleton just to keep dependencies at a minimum.

[OniLinkPlus]

For singletons I agree with Nexus. They are more close to being an anti-pattern than actually being a design pattern. In my engine I have one root-singleton which is the application. Nothing more. Any other singleton is "Read-only" data like resource managers for textures, fonts, models and shaders.

But the general rule is, if you are getting more than one singleton class that you have to work with(not read from but actually do stuff with) then you are probably doing something wrong and it will eventually turn around and bite you in the ass.

Even as it is now for my game engine I Feel that I am having too many singletons because I have different resource managers, one for every type. So I might even redesign this to be all placed under one singleton just to keep dependencies at a minimum.

I too use just one singleton, which is the engine. My resource managers are handled by a single Get* function for each type of resource (except music, music has several functions), which checks a file-space map of resources.