upfront I develop software for big data applications of which use is beyond my control (it ends up with a user), but I am not a trained software developer. So I apologize for any wrong terminology.

Now my question is: Is a class hierachy justified when implemented mainly/solely to aide static checking (checking at compile time)??

An example:

A single "array" class may contain a 1, 2 or 3 dimensional array of floats as a variable (depending how the object is invoked) and has a method "inversion". Of course only 2D squared arrays can be inverted and I have the option to throw an exemption at run time if the method is called and the actual variable is 1D, 3D or 2D rectangular.

I could also make a class hierarchy which contrast child classes 1D, 2D, 3D, and 2D further into rectangular and squared. Then, the inversion method would only be defined for 2D squared. If "inversion" is called by 1D the compiler can pick that up as the method is not defined.

The latter approach is obviously more complicated and involves more code but it is the one I have preferred so far. I have preferred it because when one puts all the little bits and pieces together to large executables this way provides a lot of help to get it right at compile time, not when the exec is in the "wild".

Now I was told by a trained programmer that class hierarchies should never be implemented for the sake of aiding static checking as it makes maintenance unnecessary complicated, thus he would use approach 1.

If you have experience in that field I would appreciate if you could share it.

Thanks a lot


It depends. Better static checking is good. But extra complexity is bad. Is the better checking worth the extra complexity? It depends on the situation. Attempting to reduce this to a rule of either "always do this" or "never do this" is a sign of naive thinking.

There are three factors to consider:

  1. How likely is the mistake which the static typing prevents?
  2. How much work is the extra static typing to setup?
  3. How much friction does working with the static types cause?

You should indeed design classes that are useful to solve the problem and that correspond to meaningful abstractions. Static type checking should not be the purpose of your design. But it's a nice side effect that comes for free if you follow that advice.

In your example, 1D, 2D, and 3D are different kind of matrixes, and it makes sense to have specialised classes. Beware however from too deep class hierarchies, because it might introduce some constraints. For example, if you have 2D-square and 2D-rectangle, you can no longer copy 2D matrixes without knowing what kind of matrix it is, unless you implement some cloning mechanism.

Now, you can of course do some consistency checks at run-time. But you need to plan them. The static type checking, although it adds some constraints and complexity, has the benefit of uncovering issues and inconsistencies you were not thinking of.

This site is temporarily in read only mode and not accepting new answers.

Not the answer you're looking for? Browse other questions tagged .