Frequently Asked Questions

Why QT?

I want to make the components loadable, so that applications can be extended without recompilation. So the componets have to be separate library modules. And QT provides a way to cast pointers across library boundaries (qobject_cast).

Why not POCO (Plain Old C++ Object)?

Short answer is that I don't know how to do that. As C++ does not provide reflection information, there's no way to load a library and find out what's in there unless some information were manually inserted. The downside is that we have to define the objects Qt way. But we got the information we need. Is it intrusive? Yes and No. Yes. We cannot just use any c++ objects. No, because we can still use the objects in other Qt applications without linking to QtIOCContainer. In this sense, the objects are POQO (Plain Old Qt Object).

The other alternative is to use a C++ reflection library (e.g. SEAL Reflex Library) to do the same thing. It might be a better solution. But I guess the components have to be linked in the application and no longer pluggable.

Where's constructor injection?

There isn't any. Qt PluginLoader does not support this.

What about prototype objects?

QtIocContainer does not provide the capability to define prototype objects. However, you can always define a singleton factory object and let the clients of the factory retrieve a prototype object everytime it needs one. I believe that the concept of prototype object is inherently contradictory to the concept of an IOC container.

What about autowiring?

I don't think the benefits of autowiring worth the confusion it brings. So QtIOCContainer does not provide it.

---

Zhihong "John" Wang (zhihong_w@yahoo.com).