Thanks!

Say no to the OO-ist. When you nest and branch conditionals, all you need to do is read the code from top to bottom. Like a great novel, one simple linear prose of code. With the OO-overboard paradigm, it’s like a terrible choose-your-own-adventure kid’s book. You’re constantly flipping between classes and juggling patterns and so many more complex concepts. Just if-things out and you’ll be fine.
■Utils, Utils, Utils! – Code smell? No way – code perfume! Litter about as many util and helper classes as you wish. These folks are helpful, and when you stick them off somewhere, someone else can use them too. That’s code reuse, and good for everyone, right? Be forewarned, the OO-police will say that functionality belongs in some object, as that object’s responsibility. Forget it, you’re way to pragmatic to break things down like they want. You’ve got a product to ship after all!

* Use Statics – This is an attack on both statics and free functions.. but it violates Meyer’s Principle of least encapsulation: if a method depends only on the public interface of an object it is less binding to have it as a static/free function than it is a member function… object.Method() is a nicer syntax than Method(object), but it attaches less baggage to Object so it is more flexible and orthogonal. Trading this for easier test harnessing is not a good trade. That said.. This is a point you stress strongly so as my experience with unit testing grows I may come to agree with you.

* Be Defensive. This is a flat out assault on the tenants of Design By Contract and I won’t stand for it! DBC and TDD go together like a hand and a glove! If passing NULL is an invalid action (a bug, a contract violation) than YES assert the fuck out of it! This doesn’t mean the method is untestable: test to make sure it asserts on invalid input (do make sure the test framework can catch the asserts for standard fails and anticipate them as a pass condition in some cases)! And then give it valid input to test it succeeds on. I really don’t see what you are getting at here. Do you want people to be able to pass in erroneous data and get back a valid result? Just plain wrong IMHO.

* Use Primitives Wherever Possible – The less ‘cookie objects’ you introduce, the less dependencies your code has, the more orthogonal and modular it is. Wrapping a primitive in an object for the sake of mocking is just insane to me: what are you going to mock? It generating a given value? This is my 2nd least favorite point (behind the before-mentioned assault on DBC)

* Side Effects are the Way to Go – This wins my award for the line I agree with most. Side effects are something I see all the time in production code and they ALWAYS end up generating subtle bugs, injecting tendrils of hidden coupling, and making it really unpleasant to refactor things. They can be the result of Singleton overuse, global state flags, or a million other things. They are very very easy to add yourself (often when you need to add a little extra functionality to an existing system and don’t want to muck things up too much). As such they are becoming the design flaw I watch out for most of all: Every class, every method, must have a laser-focus purpose. Any side effects are unacceptable and if it means a major refactoring when a tiny feature is added this is a price I must be willing to pay, because the seemingly cheaper path of just adding a few hidden state variables is far worse in the long run.

* Create Utility Classes – I take issue with this.. see my prior point about the ’static methods’ for my argument, because it is the same here. Reduce coupling! Meyer’s! Yaaaaaghh!

* Use non-virtual – in the games industry we know.. we know. We know that virtual == overhead. We don’t strive for bad design and we pay the piper where it makes sense, but we don’t make things virtual for the sole sake of testability. But being virtual does enable mocking, so perhaps a compromise is a TEST_VIRTUAL macro that says ‘virtual’ when in unit-test land and nothing in other cases, such that unit-test mockings can override it safely? I dunno, maybe that is a bad idea.. In any case if it is a class that you are gonna wanna mock, you are gonna wanna have the class implementing an abstract base class (interface) in the first place I would assume.

* #ifdef PROD is silly. #ifdef DEBUG is fine. Tests should be running which full debug code active IMO (even if optimizations are turned on) since this helps them do the tag-team of awesomeness with ASSERTs you are using for poor-mans DBC.

1. Your aversion to final classes. Use composition not inheritence. Inheritance breaks incapsulation in many ways.

2. Your aversion to asserting non-null. Null breaks type safety and assertions are needed to validate that the function contract (supply me with arguments of a certain type) is actually being honored. A null string reference is not a reference to a string *at all*. Null references by default are a hold over from C and assembly pointers, they are a misfeature in a strongly typed language like Java or C++ (although this can be fixed with smart pointers in C++). Many strongly typed languages, like ML, use non nullable references by default and require specification of nullability in the type for this very reason.

3. Your aversion to utility functions is the only thing I think is truly rediculous. Utility functions *increase* testibility not decrease it. Separating functions from a class that aren’t involved in the maintenance of the classes invariant also increases the encapsulation of the class. To test that the class cannot be transformed into an invalid state, you only need to test methods that actually have access to that state.

Also a separate function that does not have priveledged access to your Url class can be tested for functionality without having to double check that it violated a class invariant, because it *can’t* violate one.

Big classes with lots of helper methods are common in java, but this is actually very bad. Classes should only have one responsibility, e.g. to manage some resource, or maintain an on a piece of data, etc. Adding lots of utility methods into the class viol

That said, a utility function (or static method in java) should not be stateful in any way, and by that I also mean it should not use external services that aren’t passed into the function as arguments. However, this it is true of *any* object that it is bad to access global state.

Utility functions aren’t really an OO idiom, but they are a *good* idiom, and they are not hostile to testing. OO is great, but it isn’t the only thing in our bag of tricks.

1. Be Defensive – They’re out to Get Your Code!
I usually am defensive on arguments of my api methods and I would tend not to sacrifice this defensiveness in my production code for tests unless I find myself in a situation unable to test.
In the end I cannot change that deliberately lateron as it would be a breakage of runtime behaviour.

2. Final Methods
Here I disagree even stronger as my api would then allow overriding/subclassing without being designed for inheritance. (For internal classes I would be in the same situation as in 1, when I cannot write a test because of it, only then I would think about removing the final keyword)

I would even go so far to consider Java having the wrong default (an unfinal keyword would be the way to go)

Cheers,
Jan

Thank’s for the article.

Fabio Nascimento