I have a general question...when should i be using static classes or static methods?..
I know the idea that static methods can be called without instantiating...and static classes should only be used for static methods?...but are there any performance concerns also with it...and when should they be preferred over instance methods and classes?..If someone could just briefly mention when i should opt for using them and when i should avoid them?
I think the following two links offer a clear answer for what you're looking for. Take a look at them:
For static classes:
When to Use Static Classes in C#
For static methods:
When is it appropriate to use static methods? ( Jon Skeet [the Guru] answered this one :o) )
One thing to keep in mind is the testing implications of static methods. A static method "seals" a lot of seams. Seams are where you can change behavior without changing your production code; examples are subclassing, or linking to a testing library. Since static methods are resolved at compile time and aren't dynamically bound you can't throw in a testing object and change the way a static method behaves. Testing that class is going to be a drag.
For things like mathematical functions you can be pretty sure a static method will be ok, but you almost certainly wouldn't want a static method that connects to a database. Think about how you'd test code that uses a static method you're thinking of making.
Here's a good link from the google testing blog:Static Methods are Death to Testability
I think a general rule of thumb could be that utility functions should be static. A typical example would be how in any oop language a Math class would contain static methods like sqrt(), since there is really no need to have something like a separate Math object.
As for static classes you should think of classes keeping a form of state, typically like session information, which is needed irrespective of the exact path travelled through your application, and of which you typically need exactly one. (think of your browser, probably always keeping exactly 1 cookie-jar like class)
Static variables are the less evil twin of global variables (they keep their value, but with their scope limited to a function), which are typically useful to either keep some form of state (e.g. caching of data) or to enumerate things that should be unique but whose numbering is not very important outside the scope of your function or application (say, numbering debugging or profiling cries from your own debug("..") or profile() functions)
Basically, only use any of them when you are very sure that doing things the "right" OOP-like way would lead to the creation of a monster.
As I understand it that's when there's no sense to create an object of a class to invoke an action or that class is common within the application. For example, in C#, Console class is sealed (so you can't create an object and inherit it, and there's really no sense to do it). But professionals will explain you better, however.
Related
As stateless methods are mostly marked as static, they do not require the instance. But I am wondering whether there could be a case where a stateless method still can be an instance method of a class?
The reason I ask is that I have read some learning materials that mention "stateless and static methods", so I am thinking about the difference.
For example if you want to make use of what is called "Strategy Pattern" in OOP-terms.
For example, if you are programming a little calculator, and you want to apply a binary operation to the two numbers on top of the stack, you want to map user input to instances of the classes Addition, Subtraction, ..., Division, which all implement an interface BinaryOperator and have a (stateless!) method int apply(int firstArg, int secondArg).
The basic arithmetic operations +, -, *, / are as stateless as anything can possibly get, but still, you are attaching them to instances of classes.
This is kind-of a canonical example, because whenever you mix OOP with purely functional programming, all objects without mutable state become something like collections of closures, which are essentially the good-old-oop-strategies on methamphetamines.
Keep in mind: depending on the used language/technology, static can be almost an anti-pattern.
In Java for example, static is implemented in a way that basically kills polymorphism. But polymorphism is one of the cornerstones of OOP. You use it to enable yourself to easily add new functionality - by extending some class and overriding a certain method. But when using static, you directly "link" yourself to that very specific class and method implementation. If you need different behaviour, you either have
change the caller to invoke some other method
change the behaviour of that static method.
And of course: again, in Java, in order to do proper unit testing, static can get in your way quickly. And most often, when people find "woha, my code under test calls that static method, and ouch, calling that static method throws up in our unit test environment" - their "answer" is to turn to mocking frameworks that allow to mock static methods (like PowerMock or JMockit). And that can lead to other issues.
Thus: static has its place, but depending on your technology stack you should be really careful about using it. Not having state is probably thus necessary, but sufficient when determining whether some method should be static or not.
In terms of good Objective-C coding practices, if I create a function that has no state, is it better to write it as a static method of some class or as a C function?
For example, I have a special filepath retrieval method that checks the Caches directory before proceeding to the main NSBundle. I currently have it as a static method under an otherwise empty Utils class. Should this be a C function instead?
The reason I've chosen to use a static method (for now) is that a) it's consistent with Objective-C syntax, and b) the class helps to categorize the method. However, I feel like I'm cheating a little, since I could easily fill up my Util class with these stateless static methods and end up with an ugly "shell class", whose sole purpose would be to hold them.
What convention do you use? Is one "better" than the other, by some objective metric? Thank you!
If you can think of an existing class of which this might make a good method, you can inject your method into it by making an Objective-C category. This keeps your two reasons for using a static method while not polluting the class space with an extra class.
For example:
#interface NSString (MyStringCategories)
- (NSString*) myCoolMethod;
#end
// [StringCategories.m]
#import "StringCategories.h"
#implementation NSString (MyStringCategories)
- (NSString*) myCoolMethod {
// do cool stuff here
return whateverYouLike;
}
#end
Now you can send myCoolMethod to any string. Cool!
In your particular case, it sounds like a method on NSBundle might be an appropriate architecture. And don't forget, it can be a class method, so you don't need to instantiate anything in order to call your method.
This is quite a difficult question to answer because for a lot of people the answer will depend on what their personal preferences and tastes are. I personally think that if you have a function that is a function, i.e. it has nothing to do with an object, it has no internal state etc. pp. please let it be a function and do not try to wrap everything you possibly can into an object just because you are using an OO language and you can.
In order to keep my answer short let me refer to a (imo) quite good book:
http://www.gotw.ca/publications/c++cs.htm
I know that this is for C++, but there are quite a few insights that can be shared with other languages (esp. Objective-C and Objective-C++) especially from the part called "Class Design and Inheritance". There you will find an item titeled "Prefer writing nonmember nonfriend functions".
Bottom line: "Nonmember nonfriend functions improve encapsulation by minimizing dependencies[...] They also break apart monolithic classes[...] [and] improve genericity[...]".
I think there is quite some truth in that item.
If there's no class to clearly bind it to, then I use a function. I also use functions for these utility bits because they can be stripped if not used or referenced. In that regard, it's also helpful to use a function because a link error is better than a runtime error (in the even the .m was accidentally omitted from the build, or if was referenced from another externally updated method). One problem with ObjC symbols is that they do not get stripped, so they naturally carry a high amount of dependency -- all the objc methods and classes, and required category methods must exist in the final binary. That's not an issue with really small programs or libraries, but it quickly gains weight with medium/large systems and libraries.
Everything does not need to be declared in an #interface - especially with larger systems where all those declarations will really turn your interdependencies into spaghetti. Compared to methods, functions are faster, smaller, may be optimized better by the compiler or during linking, and may be stripped if not referenced.
If you need polymorphism, it just belongs in a class for organization or convenience, then a class or instance method is often a better choice.
I also minimize declaring category methods for the same reasons. When you're using functions, you can easily write a wrapper method where you need it and get the best of both worlds.
I understand the differences between them (at least in C#). I know the effects they have on the elements to which they are assigned. What I don't understand is why it is important to implement them - why not have everything Public?
The material I read on the subject usually goes on about how classes and methods shouldn't have unnecessary access to others, but I've yet to come across an example of why/how that would be a bad thing. It seems like a security thing, but I'm the programmer; I create the methods and define what they will (or will not) do. Why would I spend all the effort to write a function which tried to change a variable it shouldn't, or tried to read information in another class, if that would be bad?
I apologize if this is a dumb question. It's just something I ran into on the first articles I ever read on OOP, and I've never felt like it really clicked.
I'm the programmer is a correct assumption only if you're the only programmer.
In many cases, other programmers work with the first programmer's code. They use it in ways he didn't intend by fiddling with the values of fields they shouldn't, and they create a hack that works, but breaks when the producer of the original code changes it.
OOP is about creating libraries with well-defined contracts. If all your variables are public and accessible to others, then the "contract" theoretically includes every field in the object (and its sub-objects), so it becomes much harder to build a new, different implementation that still honors the original contract.
Also, the more "moving parts" of your object are exposed, the easier it is for a user of your class to manipulate it incorrectly.
You probably don't need this, but here's an example I consider amusing:
Say you sell a car with no hood over the engine compartment. Come nighttime, the driver turns on the lights. He gets to his destination, gets out of the car and then remembers he left the light on. He's too lazy to unlock the car's door, so he pulls the wire to the lights out from where it's attached to the battery. This works fine - the light is out. However, because he didn't use the intended mechanism, he finds himself with a problem next time he's driving in the dark.
Living in the USA (go ahead, downvote me!), he refuses to take responsibility for his incorrect use of the car's innards, and sues you, the manufacturer for creating a product that's unsafe to drive in the dark because the lights can't be reliably turned on after having been turned off.
This is why all cars have hoods over their engine compartments :)
A more serious example: You create a Fraction class, with a numerator and denominator field and a bunch of methods to manipulate fractions. Your constructor doesn't let its caller create a fraction with a 0 denominator, but since your fields are public, it's easy for a user to set the denominator of an existing (valid) fraction to 0, and hilarity ensues.
First, nothing in the language forces you to use access modifiers - you are free to make everything public in your class if you wish. However, there are some compelling reasons for using them. Here's my perspective.
Hiding the internals of how your class operates allows you to protect that class from unintended uses. While you may be the creator of the class, in many cases you will not be the only consumer - or even maintainer. Hiding internal state protects the class for people who may not understand its workings as well as you. Making everything public creates the temptation to "tweak" the internal state or internal behavior when the class isn't acting the way you may want - rather than actually correcting the public interface of internal implementation. This is the road to ruin.
Hiding internals helps to de-clutter the namespace, and allows tools like Intellisense to display only the relevant and meaningful methods/properties/fields. Don't discount tools like Intellisense - they are a powerful means for developers to quickly identify what they can do with your class.
Hiding internals allows you to structure an interface appropriate for the problem the class is solving. Exposing all of the internals (which often substantially outnumber the exposed interface) makes it hard to later understand what the class is trying to solve.
Hiding internals allows you to focus your testing on the appropriate portion - the public interface. When all methods/properties of a class are public, the number of permutations you must potentially test increases significantly - since any particular call path becomes possible.
Hiding internals helps you control (enforce) the call paths through your class. This makes it easier to ensure that your consumers understand what your class can be asked to do - and when. Typically, there are only a few paths through your code that are meaningful and useful. Allowing a consumer to take any path makes it more likely that they will not get meaningful results - and will interpret that as your code being buggy. Limiting how your consumers can use your class actually frees them to use it correctly.
Hiding the internal implementation frees you to change it with the knowledge that it will not adversely impact consumers of your class - so long as your public interface remains unchanged. If you decide to use a dictionary rather than a list internally - no one should care. But if you made all the internals of your class available, someone could write code that depends on the fact that your internally use a list. Imagine having to change all of the consumers when you want to change such choices about your implementation. The golden rule is: consumers of a class should not care how the class does what it does.
It is primarily a hiding and sharing thing. You may produce and use all your own code, but other people provide libraries, etc. to be used more widely.
Making things non-public allows you to explicitly define the external interface of your class. The non-public stuff is not part of the external interface, which means you can change anything you want internally without affecting anyone using the external interface,
You only want to expose the API and keep everything else hidden. Why?
Ok lets assume you want to make an awesome Matrix library so you make
class Matrix {
public Object[][] data //data your matrix storages
...
public Object[] getRow()
}
By default any other programmer that use your library will want to maximize the speed of his program by tapping into the underlying structure.
//Someone else's function
Object one() {data[0][0]}
Now, you discover that using list to emulate the matrix will increase performance so you change data from
Object[][] data => Object[] data
causes Object one() to break. In other words by changing your implementation you broke backward compatibility :-(
By encapsulating you divide internal implementation from external interface (achieved with a private modifier).
That way you can change implementation as much as possible without breaking backward compatibility :D Profit!!!
Of course if you are the only programmer that is ever going to modify or use that class you might as well as keep it public.
Note: There are other major benefits for encapsulating your stuff, this is just one of many. See Encapsulation for more details
I think the best reason for this is to provide layers of abstraction on your code.
As your application grows, you will need to have your objects interacting with other objects. Having publicly modifiable fields makes it harder to wrap your head around your entire application.
Limiting what you make public on your classes makes it easier to abstract your design so you can understand each layer of your code.
For some classes, it may seem ridiculous to have private members, with a bunch of methods that just set and get those values. The reason for it is that let's say you have a class where the members are public and directly accessible:
class A
{
public int i;
....
}
And now you go on using that in a bunch of code you wrote. Now after writing a bunch of code that directly accesses i and now you realize that i should have some constraints on it, like i should always be >= 0 and less than 100 (for argument's sake).
Now, you could go through all of your code where you used i and check for this constraint, but you could just add a public setI method that would do it for you:
class A
{
private int i;
public int I
{
get {return i;}
set
{
if (value >= 0 && value < 100)
i = value;
else
throw some exception...
}
}
}
This hides all of that error checking. While the example is trite, situations like these come up quite often.
It is not related to security at all.
Access modifers and scope are all about structure, layers, organization, and communication.
If you are the only programmer, it is probably fine until you have so much code even you can't remember. At that point, it's just like a team environment - the access modifiers and the structure of the code guide you to stay within the architecture.
Every time I come across an implementation of the singleton pattern or any static classes (i.e. classes with (almost) only static members) I wonder whether this isn't actually a hack and therefore heavy abuse of the principle of classes and instances just to design single objects instead of designing classes and creating a single instance. To me, it looks like static members of classes in general try to add some sort of characteristics to classes which they actually aren't supposed to have and which rather make them object themselves.
But is it really desirable to have single objects implemented like that?
Or do you see things completely differently and don't think that such static classes or singletons have anything in common with actual objects?
Static members are effectively just namespacing for globals, yes. Nothing wrong with that; namespacing is good, and globals are the cleanest way to accomplish some tasks.
Singletons can be somewhat more interesting (load on demand...) but they're a similar construct (yeah, you could think of a static member as an anonymous singleton managed by the compiler).
Like most things, these tools have their place, and only the ideologues worry about whether or not they "fit" with a particular ideology.
Depending on your language, classes are objects. In ruby and java, they're of class Class; in python, I don't remember (subclasses of type?).
In java, you can't avoid putting things on classes. This means you sometimes have to use classes like you would use namespaces and modules. A lot of the static methods on Math are a good example of this. I'd say that having these methods be static makes the best of a bad situation.
I think whether it's "dirty" to have static attributes depends very much on the context. What you really should look for is proper encapsulation: it's good if you can draw a curve through the conceptual space of your code and say "everything on this side doesn't need to know anything about things on that side, except for the interface across the curve.
You can view it from a performance and memory perspective. For example, in the following code:
public class StringUtils
{
public static boolean isEmpty(String value)
{
// some code
}
public static String reverseString(String value)
{
// some code
}
}
Do you really want to instantiate StringUtils objects all over the place just to call a method that doesn't store any member variables? In a simple program, it doesn't matter much. But once your program starts to get to a certain size and you call these methods thousands of times, well let's just the instantiations can add up. And why? To be a purist? It's not worth the cost. Just use the same instance.
Say I have an application which has a single configuration file. How would I create functions to operate on that file without the use of a "singleton" if my language does not support global functions outside of a class (like Java or C#)?
It seems to me the only real way to accomplish that is have a singleton class. Using the singleton pattern you also don't need to pass around a pointer to the object, since you can just use the static method to get it again.
I don't see how this is a violation of any OO principles. To do it a different way, like put the configuration functions in another class that doesn't deal with configuration (like a "utility" class) is more of a violation of OO principles.
Suppose that you have a multi-threaded application which requires a central data repository. The consumers and producers use or put data in the repository, including the external application object which accesses the repository through an interface.
If you made this repository a normal class object, you'd have the problem of initializing it and getting a pointer to every object that needed it. Not the toughest problem, but it can be very confusing with a lot of threads and objects.
On the other hand, if you do this:
public enum Data implements MyInterface{
INSTANCE;
private final Whatevertype secretstuff = new Whatevertype();
...etc...
public void PutThing( Sometype indata){ ... };
public Sometype GetThing( int somecode ){ ...};
...etc...
}
You (a) don't have to instantiate anything and (b) can access from anywhere with
Data.INSTANCE.GetThing(42);
etc. It's just like Highlander... THERE CAN ONLY BE ONE
Let's say I have a simple class called WebsterDictionary that has a function that can take a word and return its definition. Perhaps there is another function that can take a definition and return a word. The class is used all the time by many clients.
To facilitate the lookups, the class contains a member variable that is an in-memory Dictionary which stores the words and their associated definitions. Assume the Dictionary can never change once it is initialized -- it's constant and would not vary across instances.
Is this a good candidate for static class? I've been reading that static classes should be stateless...but this class has state (the in-memory dictionary) right?
EDIT: Also, if this does become a static class, when do I initialize the Dictionary since there would no longer be a constructor? Do I do check to see if the reference to the Dictionary is null every time one of the static methods is called?
Thanks.
A static class is suitable when the functionality doesn't need to be replaceable (e.g. for tests). If you might want to use a stub or a mock, you should create an appropriate interface, and then implement it with a singleton.
To expand upon others' answers, a static class or singleton is useful when you need to have only one instance of a class. This is much easier to accomplish when the data is immutable. Thus, there is a possibility that a static class is what you want to use for this. But it's not necessarily the case that it's automatically what you want to use.
My advice is to ask yourself one question: will the world come crashing down if I instantiate more than one of these objects? If so, use a singleton or static class. Otherwise, use a regular class.
A static class might be what you want here (see other answers). But don't make the mistake of calling your dictionary "immutable".
Immutable does not mean "can never change at runtime" in the sense that you used the phrase, because your Dictionary actually does change at runtime; after you must create it you must also add the items. Even at this point you may intend that it never change again, but it is possible to change it. Your intent is not enforced anywhere.
A true immutable object cannot change after creation, no matter how much you try. Instead, when you need a variation of the object you must create a new instance with the desired attributes.
You can think of a static class in one sense as having exactly one instance. That's probably not the best choice for a pattern where you depend on creating new instances for each state change.
You could either go Singleton or a Static class. I would probably go with a Singleton but I think it's mostly a preference issue in this particular situation.
A static class is appropriate when only one "instance" should ever exist, in which case the Singleton pattern may or may not be more appropriate (depending on the details). For an immutable object that you'll need multiple instances of, of course a static class is inappropriate.
What you are looking for might be Singleton?
It is not necessary that static class need not have state (it can have static members as part of it, which can be part of its state).
It sounds very much like you're describing the Monostate pattern: you would like the same WebsterDictionary to be shared by everyone. It just so happens that the WebsterDictionary is also immutable, but that is an orthogonal concern: just make it impossible to update (for example, by using a read-only wrapper).
As you said the class is holding some form of global state, even if it is read only. Going the Singleton approach makes it really clear it is holding data.
If you use dependency injection you can have it inject singleton instances, instead of making all the classes have code that gets you the instance. This means the other classes won't be tied to the Singleton approach, and if you can more easily replace it when testing (combined with an interface to enable replace with test mocks).