Name for use of methods that return rather than set

Question

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.

Answer 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.

Answer 2

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.