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.

3

2 Answers 2

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.

6
  • 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. Mar 26, 2014 at 23:50
  • @MirroredFate: See my update. If it's still unclear, I'll put the new text at the top. Mar 26, 2014 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. Mar 26, 2014 at 23:59
  • "Functional Style," although your example is not quite there yet. Mar 27, 2014 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. Mar 27, 2014 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
  • 1
    If you have links to the reference material, please include them in your answer. Mar 27, 2014 at 1:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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