Question 5: Abstract factory

Ok i've had some experience with the whole factory concept in a second year module(Java), but there is something i'm not sure of. In the assignment they ask to create an Abstrac factory and implement it as a singleton Concrete factory so that two XmlHandlers(/Formatting techniques), or well that is at least how I understand it, can be created. With one handler creating a coma separated file and the other a tab separated file (Question3). Which is all good, but they want the Abstract factory to return a reference to the right formatting technique, and have the 'coma' or 'tab' pasted as parameter to the factory method. So i'm thinking the only way to do that is like so;

Language: C++
class AbstractHandlerFactory
{
public:
    virtual QXmlDefautltHandler* newObject(QString aSeperator);
    virtual ~AbstactFactoy(){}
}

with a concrete factory like so;

Language: C++
class XmlHandlerFactory : public AbstractFactory
{
    static XmlHandlerFactory* instance();
    virtual QXmlDefautltHandler* newObject(QString aSeperator);
}

implemented as so:

Language: C++
XmlHandlerFactory* XmlHandlerFactory::intance();
{
    //Whole singleton implementation thing
}
 
QXmlDefautltHandler XmlHandlerFactory::newObject(QString aSeprator);
{
    if(aSeperator == "coma")
        return new ComaHandler(); //Derived from QXmlDefautltHandler
    if(aSeperator == "tab")
        return new TabHandler(); //Derived from QXmlDefautltHandler
}  
//Similar to how the textbook did it

My question though is wouldn't it just be better to rather have two concrete classes say ComaHandlerFactory and TabHandlerFactory, with there own factory methods returning a more specific derived class, instead of the if statement in One Concrete Factory with a factory method returning a reference to the base class. And even more so, couldn't you rather just add a parameter to the constructor of one class derived XmlDefaultHandler indicating whether it should use coma/tab separated formatting technique.

From my experience of writing production code, the better solution is to set a flag in the writing class and use a switch statement that indicates to the file writer class to use either the comma or the tab. This is very much an over architected solution that looks like it is designed for the sole purpose of teaching the patterns rather than showing what good code in the wild looks like.

Don't get me wrong - it's very important to learn the patterns and this exercise does teach you that. But it doesn't teach you that this example is too small to justify the use of the patterns for code that would be used in real life.

Ha ha ha, in the "wild". Yeah man, i'm completely aware this question is to small to justify a pattern and that it is just there for teaching the pattern. But I fear it is teaching it wrong(or well badly). My concern is with the whole parameter in the factory thing. I see it as forcing us to concern the factory with things that doesn't concern it and ultimately making it less robust... Thanks for the input though.

Hey bro,

I understood it slightly differently and still working on this one. I have two abstract interfaces, one for the formatting technique (strategy) and the other the factory; which is then used in existing reader classes.

Language: C++
class GeneralFormatter : public QObject{
  Q_OBJECT
  public:
    virtual ~GeneralFormatter(){}
    virtual QString getFormatter()=0;//abstract function
}

and

Language: C++
class AbstractFactory 
{
  public:
    /**
       @arg className - the desired class to instantiate
       @return a DataObject-derived instance which
       is "close enough" to handle the properties of className.
    */
    virtual DataObject* newObject (QString className) = 0;
    virtual ~AbstractFactory() {}
};

Language: C++
class ObjectFactory : public QObject, public AbstractFactory {
  Q_OBJECT
  public:
    ObjectFactory(){}
    /** @return a singleton instance */
    static ObjectFactory* instance() ;
 
    virtual DataObject* newObject(QString className);
    CDItem* newCDItem();
 
};

Then create a concreate factory (ObjectFactory above) which is used as a initializer variable in the DataObjectReader class (which extends QXmlDefaultHandler). This meant we also had to create a CD dataobject that inherited from the DataObject class so the CD object could be created in the dataobject factory class as that only deals with DataObjects.

The reference to the different formatting strategies (comma,tab which implement the GeneralFormatter interface above) could then be referenced in the DataObjectReader thus leaving you with one reader class and settings the strategy for the output...

That is where I am now and after reading your post making me rethink things again. I found the above solution in chapter 16 page 377 (UML on p378). This was after trying to solve it differently and still work in progress. Just thought I would throw it out there for anyone else's input as I am having issues trying to implement the above..

cheers,
Conor

Well I'll be damned, yeah never even thought about it like that. Liking the whole GeneralFormatter interface though. Will have to see if I can maybe work that somehow. Maybe a combination. Looked at page 378 Uml again, but I don't think that really applies to this situation because there the reader uses the factory to create other objects, where in the question I think the factory is suppose to create the two formatting techniques(Handlers in my case, which actually = readers in effect), not some class that represents a more concrete object in the real world, i.e. a customer. But then again I might be the devil preaching to the choir...ha ha ha.

Anyways, I'm off to kick boxing for my daily dose of violence...lol. Will tackle this problem with less brain cells tomorrow. o_O

I also read the question differently and came up with a different implementation (which I can't remember off hand). What I do remember is struggling with the singleton pattern because of the qApp variable. Took me ages to work out that that is only included if you choose to include the QtGui stuff in the project. It struck me as strange having to include a gui feature in a non-gui application, but then I guess unless I'm mistaken that Qt is primarily used for gui based apps anyway.

You are right and I can now see I overcomplicated my solution unnecessarily.. Enjoy getting your head banged up. I am going to restart this one again and move code across that I can reuse.. I can see where I went wrong and am pretty sure I got what is required in my head now - will post my findings if i come right to see what you think.

I think I got it.

As above for the GeneralDelimiter.h (basically the same as GeneralFormatter.h) and then create the 2 concrete strategies for this (i.e. tab and comma)..

Then create an abstract factory such as

Language: C++
#include "GeneralDelimiter.h"
class AbstractFactory : public QObject{
  Q_OBJECT
  public:
    virtual ~AbstractFactory(){}
    //reference to GeneralDelimiter strategy
    virtual GeneralDelimiter* newDelimiter(QString delimiter)=0;
};

and then implement the concrete facotry class that gets the specific strategy you want. This would also implement the Singleton pattern. It also solves all the pattern requirements.

Then I changed my implementaion class that inherits QXmlDefaultHandler so handle teh delimiter in rendering each CD.

thanks for help. Makes it clearer to run though things with others sometimes.

Yeah man, it does. Back from kick boxing, going to work on it myself now, after a shower that is..lol. But yeah, I think I'm basically going to do the same thing. Anyways, send me an email next time you want to go through something. mj.engelbrecht@gmail.com

rezrovs Wrote:
-------------------------------------------------------
> I also read the question differently and came up
> with a different implementation (which I can't
> remember off hand). What I do remember is
> struggling with the singleton pattern because of
> the qApp variable. Took me ages to work out that
> that is only included if you choose to include the
> QtGui stuff in the project. It struck me as
> strange having to include a gui feature in a
> non-gui application, but then I guess unless I'm
> mistaken that Qt is primarily used for gui based
> apps anyway.

Be careful. If you're writing a console application you should be using QCoreApplication not QApplication.

qApp is not a variable, it's a precompiler macro and it's defined in QCoreApplication as

Language: C++ (QT)
#define qApp QCoreApplication::instance()

It is redefined in QApplication.h as

Language: C++ (QT)
#if defined(qApp)
#undef qApp
#endif
#define qApp (static_cast<QApplication *>(QCoreApplication::instance()))

If your application class is QCoreApplication and you include QtGui, you're putting yourself in danger since qApp will return a QCoreApplication object disguised as a QApplication object. If you try and execute any member functions that need data defined in QApplication, your program will crash.

Oh dear, I knew there would be a catch to it. Pity I've already submitted the assignment. Thanks for the info though - that does make sense. I do remember though that I tried to use the QCoreApplication one and for some reason I couldn't get it to work (and I'll never remember now what I was trying.)

Did you get that information from the textbook or have you been reading up about it online?

I use Qt 4.6.1 professionally so I know the framework quite well. I've also gotten used to diving into other people's code to see how they do things. I find it a good way to learn new tips and tricks.

The under-the-hood code of Qt is some of the easiest to read of any framework I've been in contact, leagues easier to read, learn and use than MFC.

Working in it professionally must make the assignments as good as a non-issue for you! Thanks for all the explanations you're putting up