static functions Why??

[saikumar029]

Static functions are those functions which do not have the access to "this" pointer of the class and it can not be declared as virtual. why??

[kbw]

Scope.

It controls the scope of funtions/data that are only concerned with a specific class that would otherwise have to be global.

[EzwRko23]

Static functions and data members are not truly OOP, and in fact, the more you are skilled at programming, the less you should need them. They are really just globals with optional access restrictions (if you make them private). The scope is global - static members live for the entire lifetime of the application, just as globals, and they share the disadvantages of globals. Fortunately every program can be rewritten into a program with no static members and a single global entry point.

[kempofighter]

I strongly disagree with xorebxebx's characterization of static members. It is perfectly reasonable to have static constants defined at class scope which apply to a collection of objects. constant attributes can be made non-static if you expect each object to initialize them differently. static variables do not necessarily make your project less object oriented. Static members and attributes are also used for patterns such as singleton where you want convenient access to the one and only object of the class. The scope of static class members is certainly not global!

[Bazzy]

But the OP is talking about static functions, not data.
Our friend xorebxebx tried to troll once more

[EzwRko23]

But the OP is talking about static functions, not data.

I referred to any static members. Static functions are nothing more than just global functions.
They don't behave like other OOP constructs: e.g. they are not inherited, they cannot be specified in an interface, their implementation cannot be easily substituted for testing. Essentially they are code operating on arguments and global data - this is structural programming, not OOP.

static variables do not necessarily make your project less object oriented.

All right. Call it as you wish. They are a sign that your OO design is seriously flawed.
Anyway, there is nothing really that bad in using globals, if you know what you are doing, but you are programming structurally then.

Static members and attributes are also used for patterns such as singleton

Singleton as usually used in C++ or Java is an anti-pattern, not a pattern. It is just a fancy-named global variable (stateful singleton) or global constant (stateless singleton). Funny they added static to C++, because it already had global variables/functions from C. But this makes the language feature list longer, and attract people that like dealling with complex things, so I suspect it was a good marketing move. They used a new name and a slightly modified syntax, so they could sell the old thing (globals) as the new thing (statics). And people bought it.
Now we have to maintain crappy applications riddled everywhere with static...

The scope of static class members is certainly not global!

So what is it? If there is exactly **one** something per the whole application, its scope is global.


http://corfield.org/blog/post.cfm/Static_is_Evil

[kbw]

The link is commenting on the use of Java and, at most, dismisses C++. I presume this is the context of your comments. I thought it was already established that the Smalltalk view of OO isn't the only one.

Static functions are nothing more than just global functions. They don't behave like other OOP constructs.

Agreed. C++ doesn't just support Object Oriented Programming (unlike Java). Just because a feature doesn't fit what you think OO ought to be, doesn't make it redundant.

They are a sign that your OO design is seriously flawed.

Are you saying that if (in Java) you specify an enum, the design is flawed? Because that's static data as far as I can tell.
And what do you consider seriously flawed anyway? And if you can avoid these practices why are you guys always refactoring your code?

Singleton as usually used in C++ or Java is an anti-pattern ...

It doesn't really matter whether a Creator is class static or an external Factory. From my point of view, it's a matter of policy. A small implementation may want a light implementation and a more complex system may need more varied behaviours. You can't just say one implemenation of a pattern is wrong. (In fact you have, but that doesn't make you right.)

Class static entries have global lifetime, class scope, with visibility controlled by the class (public/private).

[EzwRko23]

The link is commenting on the use of Java and, at most, dismisses C++

But it applies to C++ as well.

It doesn't really matter whether a Creator is class static or an external Factory.

It does matter for code maintainability and testing. It is a similar difference like having a constant value hardcoded vs provided from the configuration file.

You can't just say one implemenation of a pattern is wrong

I'm not saying implementation is wrong, I'm saying the whole pattern is wrong. A single object for the whole application without ability to limit its scope is just a global. And most of the time globals are what you should avoid - because of hidden dependencies they introduce.

Anyway, can you tell me what is exactly that magic "class scope with global lifetime"? Because for me as a user of the language it is indistinguishable from a global variable.

[Bazzy]

non-static member functions are like global functions which take a pointer to a class as argument...

[1yR4jE8b]

I agree with xorebxebx's statements mostly, especially about how using static data is not OOP. However, C++ is not a strictly OOP language and Java is only nearly completely OOP (not everything in Java is a first class object).

However, I like to use static members in classes to give scope to my globals to make them easier to understand. For example, when I use a regular expression library I always define some expressions I use alot statically in a RegularExpression class. That way, when I use the defined constant IP_ADDRESS as RegularExpression::IP_ADDRESS, then it's easier to understand exactly what the constant IP_ADDRESS is. It really is no different than just making it called REGULAR_EXPRESSION_IP_ADDRESS, but, since it's defined in the class it's simply cleaner IMO.

In fact, in C++, if I know I'm not going to be making any instances of a particular object (let's use RegularExpression as an example again), I simply use a namespace instead, but in languages like Java don't have them so I am forced to use a Class, private default constructor, etc...

I rarely ever use static functions in a class.

[EzwRko23]

However, I like to use static members in classes to give scope to my globals to make them easier to understand. For example, when I use a regular expression library I always define some expressions I use alot statically in a RegularExpression class. That way, when I use the defined constant IP_ADDRESS as RegularExpression::IP_ADDRESS, then it's easier to understand exactly what the constant IP_ADDRESS is. It really is no different than just making it called REGULAR_EXPRESSION_IP_ADDRESS, but, since it's defined in the class it's simply cleaner IMO

I agree it is useful. But it is just dividing the globals into various namespaces...

I simply use a namespace instead,

Oh, you have just said that. :)

non-static member functions are like global functions which take a pointer to a class as argument...

This pointer makes a lot of difference.

[Disch]

I think xorebxebx is too quick to dismiss things as "antipatterns" when they have real, practical uses.

Granted they may be overused and/or used incorrected by many people, but that doesn't mean they should never be used.

Both singletons and static members have a place in well designed OOP.

[filipe]

At least he hasn't argued that "that's a violation of the so-and-so principle". Yet. :)

[Disch]

I have some time before work so here's some practical examples.


A practical use of static members: The named constructor idiom:

class Foo
{
public:
  static Foo FromFile(const char* filename);
};

// usage
Foo f = Foo::FromFile("myfile.txt");

Preferable to globals because:
- Putting it inside the class makes the logic easier to understand
- Doesn't pollute global namespace
- named ctors may need to access private members. Making them static members spares you of having to make them all friends.

Preferable to normal ctors because:
- Solves ambiguities when parameter lists are similar/the same (Foo::FromFile("bah"); vs Foo::FromText("bah");)



A practical use of singletons: Resource Managers:

class ImageManager
{
 // singleton stuff here
public:
  const Image& GetImage(std::string filename);
};

// usage

const Image& img = ImageManager::Get().GetImage("my image.png");
// loads the image if not already loaded
//  returns already loaded image if image has been previously loaded 

Preferable to globals because:
- Doesn't pollute global namespace
- Can apply other design patterns. For example ImageManager could be derived from ResourceManager<T> allowing you to easily reuse code for many different kinds of resource managers.

Preferable to instantiated objects because:
- No matter how many instances of your main application class are running, you would want them all to share the same resource pool. There's no point in having the exact same image loaded multiple times in memory.