I have a script with a bunch of Subs & Functions that make use of the FileSystemObject, and currently I have a local objFileSystem variable in each procedure. My initial thought was to make the procedures decoupled and reusable, but now I am wondering if I am better off with a single global scope objFileSystem?
I understand this wouldn't be a true Singleton (being VBScript), it is just the question of a single shared object vs multiple dedicated objects, which is like a Singleton.
I have recursion in a couple of places, and I am curious if that changes the best practice at all?
I have a similar condition with a Registry object, and I wonder if the best practice is the same, or do these two behave differently?
I am not (overly) concerned with performance nor memory management, but I would like to understand the Why of any best practice.
If you actually do re-use functions/procedures elsewhere and aim for strict encapsulation: stick with local instantiation of those objects. Otherwise use singleton instances. This applies to the FileSystemObject and probably to the "registry object" as well (assuming you mean a WMI object here).
Related
I have just studied blocks it is good ,easy to use,helps in inline coding and keeps thing at one place .But I am not able to understand the following two points clearly.
1)How blocks are different from methods and delegates?
2)Advantages of using blocks over methods and delegates.Where are blocks more useful than delegates and methods.
Kindly explain and help me in understanding the concepts better.Thanks in advance!
A seemingly curious question as you ask:
1)How blocks are different from methods and delegates?
2)Advantages of using blocks over methods and delegates.Where are blocks more useful than delegates and methods.
After you wrote:
easy to use, helps in inline coding and keeps thing at one place
Regardless, though I maybe misunderstanding what you are after, here some further points to your own to consider in case they are helpful:
Instance methods and delegates are both associated with an instance of an object; so there is a self with instance variables, properties and other methods all of which can be referenced and used. Both come with accompanying state.
A block, like a function, is not associated with an instance of an object.
A block however differs from a function in that it can capture values and variables (those annotated with __block) from the method/function they are defined within. So they carry some state.
As to advantages of one over the others, it is really a question of picking the appropriate one for the scenario – none is "better" and the others. Decide what you need; adding behaviour to an object (method), passing an instance/method pair to provide some functionality (delegate), providing functionality based on values in the local scope (block), etc., etc.; and use the appropriate construct.
HTH
I have a program that will grab several global settings from an API when first logged in. These values are then used extensively throughout the program. Currently I am storing them in global variables, but it does not seem very OOP.
What are the alternatives to global variables for storing extensively used settings? Use constants? Class variables? Where would I initialize the values through the API call, since this would only need to happen once? I have seen some examples that instantiate a class to get to the variables but that does not make much sense to me.
I would like to set the values on login and after this call the variables everywhere else with a simple expression like Global.myvalue or GLOBAL_MYVALUE
The Singleton Pattern might be handy for this:
https://ruby-doc.org/stdlib-2.1.0/libdoc/singleton/rdoc/Singleton.html
It's hard to give you a concise answer based on the information you provided, but I would avoid using global variables at all costs.
A good starting point would be to think of a class that could be a common ancestor to all the places where you use these variables and store them in that class. If your subclasses inherit from that class, these variables will automatically be available in their context.
Edit: like #seph posted, the singleton pattern seems to be a much better solution though
I have a GameEngine class which is a sprite, and a GameModel which is a Singleton and holds a lot of the data.
I then get the data with
GameModel.getInstance().variable;
my game engine has a lot of them in it now and i was wondering if it would be more efficient if i had a reference to the GameModel in my GameEngine instead of creating it all the time
private var _data:GameModel = GameModel.getInstance();
trace(_data.variable);
I have a pretty strong feeling it will be more efficient but if anyone could let me know for sure and let me know if you can potentially see flaws with this method that would be much appreciated, cheers, rory.
It's definitely a good idea to store the instance in a property, since the lookup will be faster, but also because it lowers the GameEngine's knowledge of the GameModel's implementation details.
For example, imagine you've got a bunch of GameModel.getInstance() calls inside your GameEngine class and you decide to drop the singleton behaviour. You'll be rewriting all those calls, however if you'd cached the instance in a property you'd only need to rewrite one line.
That said, forget about singletons altogether, they're a far greater evil than premature optimization, but if you MUST use one, at least store the instance in a property in your client classes.
You could certainly add it as an instance, but I doubt it would make a noticeable difference. Premature optimization is the root of all evil and that :)
If you are really curious you should try to benchmark it and see if it actually changes anything.
EDIT: Oh yes, as the other answer here mentions - might want to drop singletons altogether. I would recommend looking at swiftsuspenders https://github.com/tschneidereit/SwiftSuspenders/ for dependency injection (or even robotlegs, for a great light-weight MVC solution, including swiftsuspenders).
I'm currently "updating" my development knowledge especially on TDD principles by reading books, articles on the web and watching videos. Something that pops up everywhere is the warning, not to use global state variables as they make the system fragile and less easy to test and since singletons are not much better or rather the same, not to use those either.
Now I'm wondering: Can I actually be consistent about this?
What about a cache, that the application uses so it doesn't have to look up frequently used database objects again and again? I NEED a single instance of that cache to be passed around, otherwise what would be the point?
Another example are DAOs or as we call them providers. They do nothing but provide JPA database access for us but otherwise have no state. So why not make them singleton?
And controllers in the web frontend? All they do is react to requests - again with no internal state.
Wouldn't it waste a lot of performance instantiating the latter two again and again? I'm sure there are a few more examples where this applies.
Maybe it's okay to use singletons, as long as they don't have any member variables except for finals?
And even if they have member variables but all of them are injected into them, it should be save to use them, as any object, singleton or not, can modify injected objects so it really doesn't make any difference.
I'm a bit confused about this whole "avoid singletons" business, I'm not even sure I fully understand the risks involved. But most of all I'd like to hear thoughts on the above examples, as those are the most common places in our application where we use singletons.
Thanks!
btw: we're using springs dependency injection, so how to do it is not my question, rather why avoid it and where it is okay.
The issue with Singletons is not so much the Singleton design pattern per se as their being overused under the covers as stateful global God objects all over applications.
That way of using them has 2 major drawbacks :
Dependencies on singletons are hidden dependencies, and objects are tightly coupled to them, which hampers discoverability, maintainability and testability of the code.
Objects depend on singletons they don't have any idea which state they're in. The order in which a singleton's behaviors are used here and there starts to become important, and you start seeing "MySingleton.Initialize()"s all over the place, which is dangerous and defeats the whole purpose of having a single instance.
Only singletons that trump these pitfalls are IMO worth considering - that means stateless, immutable objects that somehow get injected into their consumers and can be replaced with other instances with the same contract.
Other than that, Singleton-ification is most often premature optimization applied on the wrong objects.
This blog post pretty much sums it up : http://blogs.msdn.com/b/scottdensmore/archive/2004/05/25/140827.aspx
You are absolutely correct -- there are cases when single instance is needed. However "avoid singletons" business does not tell that they are not needed. In my understanding it states that singleton behavior should be added by Dependency Container, not by static instance.
That would allow you to mock it in your unittests while having only one instance in production. you may find this link useful: Object Scopes in Ninject
The problem with singletons and global variables is that we need them but that most programming languages offer only one "global" context.
Imagine that you could do this:
Global g1 = new Global();
g1.run( ... some code ... );
Global g2 = new Global();
g2.run( ... some code ... );
When the code is run by g2, none of the singletons and globals from the run of g1 are visible. This is actually what we want: A efficient way to say "okay, I'm done with the globals and stuff, get rid of them".
The solution is a factory which can build all your singletons and globals for you and put them into the code in the right place. Then you can create new instances of this factory (along with new singletons and globals) in your tests as you need it.
This is what "dependency injection" is all about. Here is a short introduction.
We have a class that is more like a template (with lot of properties and overridden methods). I need to make many objects of that class type. Can I use clone() to create objects with specific settings if I have one object created? I know I need to override the Clone method. Is the performance going to take a hit by using Clone()?
Cloning an object as a way of creating new objects is not necessarily the cleanest method of creating objects. It is better to use constructors or factory methods (which call constructors).
You may be interested in using a factory or builder pattern. Or if you are worried about the memory overhead of a large number of similar objects, take a look at the flyweight pattern.
Clone in itself is not bad practice, its generally shallow. BUt i think you want to be using a pattern. More than likely Prototype Pattern is your solution.
The clone you are doing is really a cookie cutting of your prototype.
The link i sent is from DO factory and has code samples for you.