A Python-based associate and I have pondered over the use of the following design pattern, which I call a “Bank” (I think it differs somewhat from the Flyweight pattern):
Say you have a game that instantiates Enemy objects. An Enemy, once incapacitated, disappears from the screen. When this happens, you can:[LIST=1]
[]delete it, and instantiate a new Enemy the next time you need one (which I think uses up garbage)
[]preserve it in a storage-type class, so that the next time you need an Enemy, you can try to reuse the ones you already made in the past (which my acquaintance thinks is resource-intensive and uncouth)
[/LIST]
Assuming my buddy is wrong, I’m motivated to write a Bank class. A bank is a complicated list, which starts out as empty. When you ask the bank for an object, it searches the list for one, and if it doesn’t have one, it’ll create one and add it to the internal list. Then it returns a reference to that object and “checks out” the object. When you return the object to the bank, it checks its list for the object, and if it finds it, it “checks in” that object. This minimizes instantiation and eliminates deletion, at the cost of running the loan() and remit() functions.
So my question for you is, is a Bank worth it? I’d like to think so, and once I create a Bank, I can try to determine whether it has any positive impact on my program’s performance. But there are good reasons to believe that it isn’t, and if anyone has any insight into this, please enlighten me.
