3

So I've been coding in Java for a decent amount of time, but recently, I've started a class that cares about my coding design. In the past, if I had two methods inside a class that needed to edit the same variable, I would make the variable a class variable. However, I know that some people prefer creating their methods to take in the explicit parameters, and then return the edited version. This results in pretty much the same effect as what I usually do, but I was wondering if there is an advantage one way or the other.

Example 1:

    public class foo{
        private static String toBeEdited;

        private static void main(String args[]){
            toBeEdited = "Original string";
            editingMethod();
            ... Code that uses the toBeEdited variable with its new value...
        }
        private static void editingMethod(){
            toBeEdited = "Edited String";
        }
    }

Example 2:

    public class foo{

        private static void main(String args[]){
            String toBeEdited;
            toBeEdited = "Original string";
            toBeEdited = editingMethod(toBeEdited);
            ... Code that uses the toBeEdited variable with its new value...
        }
        private static String editingMethod(String tBE){
            tBE = "Edited String";
            return tBE;
        }
    }

Thanks!

  • @RobertBräutigam I went ahead and added 2 examples. Let me know if it still isn't clear. – Tyler M Sep 8 '18 at 23:13
4

The advantage of 1 is lower Arity, it has fewer arguments. The fewer there are the easier they are to remember.

The advantage of 2 is that it's effect and dependency are explicit. Where it's used it's obvious that it will use a string and that it will change a string.

Both impact readability but 2 is a huge improvement where 1 is only a small improvement.

0

The biggest advantage of example 2 is that it makes the class immutable. The specific example you gave is not the best one to show this advantage because it uses static methods. The first example even uses a static field which IMHO is a bad practice by itself.

But if the field was not static, the first example modifies the state of the object, while the seconds isn't. Immutable objects are especially important for multithreading but it also makes the code easier to reason about. Therefore, even if the field and the methods were not static, then I'd probably prefer the 2nd option because it makes the class immutable.

Note also that if that field is not intrinsic to the essence (or, main responsibility) of the object, then it's another indication that it shouldn't be a member of the class (though it may be a member of another class), and if it is intrinsic to the class essence, then if you make the class immutable as I suggested, then each time this value changes you should return a new instance of the class with the new value, leaving the existing instance unchanged.

  • I fail to see how you get to be immutable from either 1 or 2. Both change the value of the member variable toBeEdited. Mark that as final and watch what happens. – candied_orange Sep 9 '18 at 16:00
  • @candied_orange, toBeEdited is a (mutable) member only in the first example. In the second it's just a local variable, hence the class has no mutable state (assuming that there are no other mutable fields in the class) – Arnon Axelrod Sep 9 '18 at 16:55
  • 1
    true. But that's only about where you put the variable. Not about if you access it explicitly or implicitly as a side effect. – candied_orange Sep 9 '18 at 17:01
  • 1
    Sorry, I don't understand your last sentence. But regarding the place of the variable, it matters a lot: a local variable resides on the stack and does not affect the state of the object. It also goes out of scope as soon as the method completed. In contrast, a field is stored in the heap as part of the object, and when it changes it changes the state of the object. It's accessible (typically through the class methods) and shared by all references of that object, and that's where things may get messy. – Arnon Axelrod Sep 10 '18 at 8:50
  • All true but if you read the OPs question, not just the code, you'll see he's asking about methods that "take in explicit parameters". You're bringing up a valid but different issue. You might as well be complaining that main() is private. This isn't codereview.stackexchange.com. – candied_orange Sep 10 '18 at 10:15

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.