How simple is oo simple to break?
(Submitted by: J. B. Rainsberger) The general philosophy is this: if it can’t break on its own, it’s too simple to break. First example is the getX() method. Suppose the getX() method only answers the value of an instance variable. In that case, getX() cannot break unless either the compiler or the interpreter is also broken. For that reason, don’t test getX(); there is no benefit. The same is true of the setX() method, although if your setX() method does any parameter validation or has any side effects, you likely need to test it. Next example: suppose you have written a method that does nothing but forward parameters into a method called on another object. That method is too simple to break. public void myMethod(final int a, final String b) { myCollaborator.anotherMethod(a, b); } myMethod cannot possibly break because it does nothing: it forwards its input to another object and that’s all. The only precondition for this method is “myCollaborator != null”, but that is generally the re
(Submitted by: J. B. Rainsberger) The general philosophy is this: if it can’t break on its own, it’s too simple to break. First example is the getX() method. Suppose the getX() method only answers the value of an instance variable. In that case, getX() cannot break unless either the compiler or the interpreter is also broken. For that reason, don’t test getX(); there is no benefit. The same is true of the setX() method, although if your setX() method does any parameter validation or has any side effects, you likely need to test it. Next example: suppose you have written a method that does nothing but forward parameters into a method called on another object. That method is too simple to break.
(Submitted by: J. B. Rainsberger) The general philosophy is this: if it can’t break on its own, it’s too simple to break. First example is the getX() method. Suppose the getX() method only answers the value of an instance variable. In that case, getX() cannot break unless either the compiler or the interpreter is also broken. For that reason, don’t test getX(); there is no benefit. The same is true of the setX() method, although if your setX() method does any parameter validation or has any side effects, you likely need to test it. Next example: suppose you have written a method that does nothing but forward parameters into a method called on another object. That method is too simple to break. public void myMethod(final int a, final String b) { myCollaborator.anotherMethod(a, b); } myMethod cannot possibly break because it does nothing: it forwards its input to another object and that’s all. The only precondition for this method is “myCollaborator !
