1

There exists a general OOP principle that methods should return local variables rather than set object fields.

For instance, say I have the following piece of code (example in Java):

public class Number {
    public int myNum;
}

public class Horrible {
    public static void areYouSerious(Number num){
        num.myNum = 47;
    }
}

public class Test {
    public int num = new Number();

    public void doHorribleThings(){
        Horrible.areYouSerious(num);
    }

    public static void main(String[] args){
        Test test = new Test();
        test.doHorribleThings();
    }
}

Obviously this style of programming can go sideways very quickly, and becomes a massive headache for anyone attempting to maintain it. A more correct way of doing this would be the following:

public class Number {
    public int myNum;
}

public class NotAsBad {
    public static int getDefaultVal(){
        return 47;
    }
}

public class Test {
    public int num = new Number();

    public void doHorribleThings(){
        num.myNum = NotAsBad.getDefaultVal();
    }

    public static void main(String[] args){
        Test test = new Test();
        test.doHorribleThings();
    }
}

The first example is modifying a passed in reference, whereas the second is generalizing the static setting function, making it return a value which can be used to set the object field.

Is there a name for the principle that the second method should be preferred over the first? A sort of "modularity" principle?

Just as encapsulation is the term for restricting variable manipulation, I would like a term for limiting the scope of the effects of some piece of functionality.

If there is no existing term, I am going to call it consequence localization.

1

How about this instead?

public class Number
{
    private int startingValue;

    public Number(int value)
    {
        startingValue = Value;
    }
}

public static class EvenBetter
{
    public static int GetDefaultValue()
    {
        return 47;
    }
}

public static void Main(String[] args)
{
    int number = new Number(EvenBetter.GetDefaultValue());
}

You can clarify it further by putting the static GetDefaultValue() method into the Number class, and then instantiate it thusly:

int number = new Number(Number.GetDefaultValue());

or somesuch.

The reason that your first example is "bad" is that it is basically a "side-effect generator." What you're trying to achieve (eventually) is Functional Programming with Immutability. You do this by writing functions that accept some input and return some output without modifying the original input or causing other side-effects to occur.

For example: Map functions are not bad (even though they appear to produce side effects), because you always return a new collection, rather than modifying the collection in-place.

  • I appreciate that this is better code in the grand scheme of things, but it has nothing to do with the question. Also, my examples are meant to be similar enough that the real difference becomes glaringly obvious, which should highlight my question. – MirroredFate Mar 26 '14 at 23:50
  • @MirroredFate: See my update. If it's still unclear, I'll put the new text at the top. – Robert Harvey Mar 26 '14 at 23:52
  • I completely with why the first example is bad; however, I don't think immutability is the name of the principle. Again, I am trying to find the name of the principle that guides the second example. Just as encapsulation is the term for restricting variable manipulation, I would like a term for limiting the scope of the effects of some piece of functionality. – MirroredFate Mar 26 '14 at 23:59
  • "Functional Style," although your example is not quite there yet. – Robert Harvey Mar 27 '14 at 0:00
  • I am struggling to accept "Functional-style programming" or "immutability" as what I am talking about. I think it is a very close parallel, but I am not concerned with mutability. For instance, in my second example, the value myNum is changed by Test, and that's fine, because num was declared in Test's scope. – MirroredFate Mar 27 '14 at 0:06
0

method args should be pass by value or passed as immutable object references

That's what I read in some references materials under "encapsulation" topics. eg; java.lang.String. have'nt found any other term for it though.

  • 1
    If you have links to the reference material, please include them in your answer. – Adam Zuckerman Mar 27 '14 at 1:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.