unity-dev team mailing list archive

[Sam Spilsbury <smspillaz@xxxxxxxxx>]

Hey all,

There seems to be a lot of confusion over what the design of the
Switcher code wise is supposed to look like.

For months now, I've been toying around with a fix to bug 1060887,
which basically is a wart in our build process, which causes several
files to be re-generated for "testing" purposes. This causes build
times to be much longer than they should be, and makes the switcher
code very fragile because it is easy to break the script.

I spoke with Stephen about a preferred design for the major classes
such as the switcher. I was informed it should look something like
this:

NVI for the class that other classes talk to
 -> Which takes a function object that creates
 -> -> An object which implements the virtual interface of that class
 -> The non-virtual API calls delegate to the implementation instance
among virtual calls to get to the implementation.

However, this review went in the other day that changed that somewhat:

http://bazaar.launchpad.net/~unity-team/unity/trunk/revision/3079

The result is that now the NVI class (eg switcher::Controller) has
logic built in, and some of the methods are now nonvirtual.

I understand the desire to simplify the design somewhat, but it
actually makes it less testable in the long run. It is very important
for work down the road on bug 1060887 that all the switcher controller
and view methods be virtual, so that they can be replaced with mocks
or stubs at runtime later.

Having the tests depend on the behaviour of the external class
not-under-test is very bad because it creates coupling between the
behaviour of the external class and the test itself. The test
setup/teardown/verification conditions need to be updated every time
the external class not under test is updated in a way that might
affect the test.

An annoying side-effect of all of this is that I need to rewrite
several bits of code later in my pipeline of changes to accommodate
revision 3079.

I'd like some clarification on what the preferred switcher design is
actually meant to be. Do we want to strictly have the NVI classes
delegate to their implementations? Or are we accepting business logic
inside of our NVI classes where those functions are not virtual.

Best Regards,

Sam

-- 
Sam Spilsbury