We are missing a lot of context but strong type systems give you the superpower to make unwanted state unrepresentable:
Here we can see the class member invalid being used as a flag to express that this method didn’t work out as expected. It is very easy for someone else down the line to ignore/forget (/never even knew about it) to check that invalid flag and just use the result regardless, which will likely lead to more failures later on.
Instead the author should directly return something that indicates invalidness. This could be as simple as returning a boolean or especially if this is a constructor it would be better to throw an error.
That way the invalid class never even gets instantiated and is therefore impossible to misuse. All validated by the type system.
Not as far as I’m aware of. You can kinda fake it with references like you would in C++.
With all the missing context it would also be possible that the author is trying to track invalid whatevers and the invalid flag is actually wanted state.
In Java, all objects are passed to methods ‘by reference’, and there is no way to mark them as immutable. So strictly speaking, they’re all ‘out variables’. This is the cause of a lot of mistakes in Java, where you eg. pass a list to a method, which then mutates it in some way. That will change the original that the caller passed in, which is normally unintended and may break class invariants. So Java tends to have an absurd number of ‘safety copies’ and immutable wrappers of collections.
I’d probably describe the inability to mark things immutable as the main problem with Java. The golden rule of concurrency is that if you share mutable state, you must use an appropriate synchronisation primitive. It’s not easy to mark things immutable (final doesn’t do what const does in C++) and although you can make class internals private if you like, the junior devs at my work will come along and add accessor methods.
tl:dr; yes it does. Passing an AtomicBoolean as a method argument will do as a built-in ‘mutable object that holds a boolean and can be checked by caller’, although it’ll be slower than your own custom object since it does sync you won’t need.
I’m from C# that has the following for your list example:
// If you add an item to this list, it will effect usages outside. You can't reassign it though.publicvoidExample(List<string> exampleParam)
//Full passing by ref, if you re-assign it to a complete new object, outside usages will be effectedpublicvoidExample(ref List<string> exampleParam)
//Output only, this acts as if the method assigned a variable named exampleParam. publicvoidExample(out List<string> exampleParam)
We are missing a lot of context but strong type systems give you the superpower to make unwanted state unrepresentable:
Here we can see the class member
invalidbeing used as a flag to express that this method didn’t work out as expected. It is very easy for someone else down the line to ignore/forget (/never even knew about it) to check thatinvalidflag and just use the result regardless, which will likely lead to more failures later on.Instead the author should directly return something that indicates invalidness. This could be as simple as returning a boolean or especially if this is a constructor it would be better to throw an error.
That way the invalid class never even gets instantiated and is therefore impossible to misuse. All validated by the type system.
It could be an OUT variable? (Does java have them?)
Not as far as I’m aware of. You can kinda fake it with references like you would in C++.
With all the missing context it would also be possible that the author is trying to track invalid whatevers and the
invalidflag is actually wanted state.In Java, all objects are passed to methods ‘by reference’, and there is no way to mark them as immutable. So strictly speaking, they’re all ‘out variables’. This is the cause of a lot of mistakes in Java, where you eg. pass a list to a method, which then mutates it in some way. That will change the original that the caller passed in, which is normally unintended and may break class invariants. So Java tends to have an absurd number of ‘safety copies’ and immutable wrappers of collections.
I’d probably describe the inability to mark things immutable as the main problem with Java. The golden rule of concurrency is that if you share mutable state, you must use an appropriate synchronisation primitive. It’s not easy to mark things immutable (
finaldoesn’t do whatconstdoes in C++) and although you can make class internalsprivateif you like, the junior devs at my work will come along and add accessor methods.tl:dr; yes it does. Passing an
AtomicBooleanas a method argument will do as a built-in ‘mutable object that holds a boolean and can be checked by caller’, although it’ll be slower than your own custom object since it does sync you won’t need.I’m from C# that has the following for your list example:
// If you add an item to this list, it will effect usages outside. You can't reassign it though. public void Example(List<string> exampleParam) //Full passing by ref, if you re-assign it to a complete new object, outside usages will be effected public void Example(ref List<string> exampleParam) //Output only, this acts as if the method assigned a variable named exampleParam. public void Example(out List<string> exampleParam)