Re: Instantiating an abstract class
On Fri, 17 Oct 2008 01:23:37 -0700 (PDT), "dascandy@gmail.com"
<dascandy@gmail.com> wrote:
class Interface
{
public:
? virtual void foo() const = 0;
};
int main()
{
MockRepository mocks;
? Interface *concrete = mocks.newMock<Interface>();
? mocks.ExpectCall(concrete, Interface::foo);
mocks.ReplayAll();
concrete->foo();
mocks.VerifyAll();
}
Given just the interface above, this works already. The point is that
the Interface object isn't constructed per se, so if it contains any
nontrivial member (std::string, other object of sorts) those will not
be initialized properly and will make the mock behave differently from
the original. That's why the question popped up.
Presumably the newMock method is basically allocating some memory and
casting a pointer?
Is it not possible to define a mock class template? Something like...
template<typename T>
class Mock_Implementation : public T
{
public:
virtual void foo () const;
};
template<typename T>
void MockImplementation<T>::foo () const
{
throw Not_Implemented ();
};
The above probably being private to the MockRepository class, then
newMock simply constructs an instance of that.
This is a minor variation of the factory method design pattern.
http://en.wikipedia.org/wiki/Factory_method_pattern
The only reason I can think why this wouldn't work is if you don't
know anything about the Interface class and therefore don't know which
methods to implement. I guess, given the template parameter to the
newMock method, this may well be the case - but it still seems
strange.
I wouldn't be surprised if some distant future C++ standard provides
sufficient reflection features for a template to identify and
implement all pure virtuals for a given class, but I do mean *distant*
future.
Failing the factory method option, I'm not sure there's even a
constructor to call. I mean, yes, there may be some code waiting to be
called from *another* constructor, but there's no way to access it
that I know of, other than to define a derived non-abstract class.
Any code that's generated for that constructor probably isn't suitable
for direct calling even if you could find a way to call it - it will
be designed to be called from another constructor, and may well be
lacking some kind of stub that would be present for non-abstract
constructor code. Though that's only *slightly* intelligent guessing -
my knowledge of C++ implementation doesn't go that deep.