As discussed on IRC. The first commit (making CCoinsView an interface class and creating CCoinsViewDummy to reimplement the current CCoinsView) is confusing, and really doesn't add any functionality. I'd prefer to skip that.

I assume you're talking about HaveInputs(), GetValueIn(), GetPriority() and GetOutputFor()
Do we want those to be virtual?
Abstract classes often have methods implemented that use pure virtual methods that the child classes must implement like in here.
Are we expecting them to be reimplemented by child classes?

No, I just meant that the classes with virtual functions need virtual destructors.

Nits resolved.

I would prefer moving GetOutputFor, GetPriority, GetValueIn, and HaveInputs to become validation/policy related utiliy functions in main, avoiding the issue altogether.

haveinputs is used in consensus (see jtimon@0ac0610). GetValueIn (which uses GetOutputFor) could be modified to avoid some code duplication with consensus.
GetPriority could probably be moved to policy, I'm just not there yet.
In any case, this change doesn't prevent future changes in that direction.
To clarify, I misunderstood theuni in his previous comment, he was just talking about the virtual destructors which I fixed, so I'm not sure what the issue you want to avoid altogether is...

Ok, that can happen independently if it doesn't solve any controversy. I just don't think GetOutputFor, GetPriority, GetValueIn and HaveInputs belong in CCoins (despite me being the one who put them there).

untested ACK, but verified b627d9abbe25a11ffca02ef1f3ab312575e5e450 as moveonly.

utACK

Updated doing the includes better (not inclding coins.h nor coinscache.h from main.h), after doing that it needed rebase, so I rebased it. The non-includes code remains the same.

Needed rebase.

I'm having second thoughts about this, closing for now.