views:

617

answers:

4

Possible Duplicate:
Static vs. non-static method

which one is better for a good design

or are there any difference? or is it just up to the developer?

class Foo
{
    int x;

    void add(Foo* f1) //Method 1
    {
        x += f1->x;
    }

    static void add(Foo* f1, Foo* 2) //Method 2
    {
        f1->x = f1->x + f2->x;
    }

    static Foo* add(Foo* f1, Foo* 2) //Method 3
    {
        Foo* foo = new Foo();
        foo->x = f1->x + f2->x;
        return foo;
    }
}
+2  A: 

From an OO point of view, I think that the better way is:

class Foo
{
    int x;

    void add(Foo* f1) //Method 1
    {
        x += f1->x;
    }
}

a method should be linked to an object not to a class.

C++ is Object oriented not Class oriented.

In my opinion, using too many static method breaks the benefit of objects (polymorphsim, inheritance...)

luc
+3  A: 

First and third options are good - which one to choose depends on your intentions. I wouldn't use second option - it doesn't reveal it's intention.

When you use first method, you clearly state, that addition will modify object. When a programmer sees:

Foo f1, f2;
f1.add(&f2);

He/she already knows, that f1 can/will be modified by this call.

When you use third method, you state, that none of passed objects will be modified, so when programmer sees:

Foo f1, f2;
Foo *result;
result = Foo.add(&f1, &f2);

He/she knows, that f1 and f2 will NOT be modified (and you should use options that language gives you to enforce this).

As I wrote - choice between first and third method depends on your intentions. If you want to treat Foo as value object - that means that you can trust that once you set it's fields they will remain that way no matter where you pass your object, use third method. If you want to treat Foo as object which state can and will change, and you agree that passing a Foo object to a method can change it's state - use first option.

However, when you use second option - programmer will not know whether you modify first, second, both or neither of arguments. Don't use this option.

maciejkow
+2  A: 

The difference of the static-ness or non-static-ness of a method for a programmer is mostly a question of what design and behaviour you wish to accomplish. There is no absolute truth or an always correct answer for this.

The straightforward difference is that static methods are stateless whereas non-static methods are stateful. If it's a matter of instantiation, there are many designs that favour static methods, for example.

But the correct answer for your design only you can achieve by inspecting thoroughly the responsibilities of the classes in your design.

Avihu Turzion
A: 

If you can implement the function/method by using only the public features of the class, then you should make it a non-member function/method (a static method in a separate class in some languages, or an extension method in C# or VB.NET).

Static methods mixed into the same class as instance methods tend to be quite obscure and confusing. They can only see static data, so it's like mixing the definition of a singleton into the definition of something else. It's a lot clearer to separate them out.

Daniel Earwicker