I have a class called
D2Array which represents a fixed-size 2D array. It's meant to be generic and it comes with quite its lot of methods: getting an element, setting an element, extract a whole row, column, etc.
Now I want to write
MyClass, which contains a
D2Array, and in order to use
MyClass properly I'll need to manipulate the state of the inner array. A straightforward solution would be having a getter to the array, manipulating it outside
MyClass, and then putting it back into it through a setter.
(Instead of the usual
Template<Type> notation, I used
Template-Type to describe template parameters, which is a bit of a contraption, but StarUML wouldn't let me do otherwise.)
This way however, any
D2Array could be fed to the setter, which would then need some sort of validation to prevent invalid states from happening. This can quickly become expensive in my case and I find it horribly counter-intuitive that the setter may throw, so I think this is clearly not a suitable solution.
Another straightforward solution which also has the benefit of strongly enforcing encapsulation: in
MyClass, write public methods to manipulate the inner array.
This is actually fine when you need to allow manipulation of the array only in a way that is not trivial. However, when you just want to expose part or whole of the existing methods on the array, it translates to literally writing one-liners which simply forward arguments to the appropriate methods. It already feels dull having to do it for one class, let alone doing it for several classes which all use an inner array in a similar yet different fashion.
Retrospectively, I think this is the essence of my problem: I want to expose only a subset of the interface of my inner array, exactly as-is, having to write the least amount of forwarding methods to do so, and the contents of this subset also depends on the needs of the class which uses an inner array.
I came up with the following solution, which seems to fit my requirements nicely, but I'm wondering if it's not kind of an anti-pattern:
- Write a new class
D2ArrayWrapper(dumb name for the sake of the example), which contains the inner array as a protected member, and publicly declares and defines forwarding methods to all of the inner
D2ArrayWrapper. This way, it contains an inner 2D array and already has all of the forwarding methods implemented, saving me the pain of writing them myself. This gain is doubled if I want to write
MyClass2which also manages a
D2Array: just have it inherit from
- If I want any array method not to be accessible from outside
MyClass, I just need to re-declare it from
MyClass, as a protected or private member.
Reasons I like it:
- It kind of achieves what I wanted.
Reasons I dislike it:
- Instead of re-declaring and re-defining the array methods that I want to be accessible from
MyClass, I re-declare the array methods that I don't want to be accessible from
MyClass. My DRY problem is not gone, simply reversed. (Also in C++, a simple
usingstatement does the trick, but in Java, a whole re-definition is needed).
- It only works in languages which handle multiple inheritance. It would work in languages which only support single inheritance too, but then it simply wastes inheritance possibilities for that class, which I find to be a huge unwanted side-effect.
- It feels overkill when compared against the simplicity of the original goal.
I'm kind of at loss right now as to which solution I should go with.
Solution 1 is a no-go because of the complexity a validation would incur.
Solution 2 is fine, but feels dumb and somewhat inelegant.
Solution 3 feels like an overcomplication of things that got slightly out of hand, and after having given it some thought, I'm pretty sure that's not something I want to go with.
As a result I'm considering going with solution 2, but is there not another way?