Overwriting functions as private

Okay here is another question; I derived a class from QXmlDefaultHandler and overwrote the startElement function as private and made it call my own public startElement function with less parameters, like so:

Language: C++
class GeneralHandler : public QXmlDefaultHandler
{
public:
 
    virtual bool startElement(const QString& gName);
 
private:
 
    /*
     * Overides the function of the base class as private and calls the overloaded function startElement(const QString& qName), 
     * in effect hiding the function and the unnecessary parameters.
     */
    bool startElement(const QString&, const QString&, const QString& qName, const QXmlAttributes&);
 
};
 
bool GeneralHandler::startElement(const QString& I, const QString&, const QString& qName, const QXmlAttributes&)
{
    this->startElement(qName);
}

Is this a bad idea for any reason other than the obvious reduction in functionality?

It's redundant.

You gain nothing and you're ignoring parameters 2 through 4 anyway. Why would you need to make the virtual function private seeing as polymorphically, it can be run anyway.

eg.

Language: C++ (QT)
GeneralHandler handler;
 
static_cast<QXmlDefaultHandler >(handler)->startElement("arg1", "arg2", "arg3", "arg4"); // allowed

[1]

Note that access permissions exist only at compile time, not at run time.


[1] I've not tested this so there's a possibility there might be an error, in which case, either use reinterpret_cast, or static_cast<QXmlDefaultHandler *>(&handler)->. I've never really gotten the hang of the c++ cast operators.

I know it's redundant, but I disagree on the gaining nothing. When hiding unnecessary functionality you gain simplicity and enhanced readability in classes derived from GeneralHandler class.

I'm just trying to find out whether it would cause any problems. Didn't know about the compile time and runtime thing though, you learn something interesting every day though.

In this particular case, you are not hiding unnecessary functionality. From what I understand, your program should be able to read any type of XML document and output in a different format. The interface is general enough to allow for most conceivable XML document out there. You're putting in a restriction by only allowing derived classes a quarter of the possible data that could be passed. This is a reduction in usability that is not a requirement of the project.

If somebody else wants to handle namespaces but also wants to use your class' functionality, they can't. They'll have to derive directly from QXmlDefaultHandler and duplicate your algorithm.

If you don't want to process the namespace, localname or XML attributes, you don't have to[1] but don't deny any derived classes the possibility.

I don't see how it would enhance readability. All you would need to do it refer back to the Qt Documentation on how to use the other parameters if they wish to derive a class from yours:

Language: C++ (QT)
// Reimpliments QXmlDefaultHandler::startElement()
// Does nothing with namespaceURI, localName and atts.
// Does ........ with qName
bool startElement(const QString &namespaceURI, const QString &localName, const QString& qName, const QXmlAttributes &atts);

[1] QXmlDefaultHandler:: startElement() doesn't process any of the parameters, it actually does nothing at all.

Ok, what you saying does make sense. The class isn't suppose to be able to read any xml file, only one that is written to contain CD catalogue info like this one:

Language: HTML
<CATALOG>
	<CD>
		<TITLE>Empire Burlesque</TITLE>
		<ARTIST>Bob Dylan</ARTIST>
		<COUNTRY>USA</COUNTRY>
		<COMPANY>Columbia</COMPANY>
		<PRICE>10.90</PRICE>
		<YEAR>1985</YEAR>
	</CD>
	<CD>
		<TITLE>Hide your heart</TITLE>
		<ARTIST>Bonnie Tyler</ARTIST>
		<COUNTRY>UK</COUNTRY>
		<COMPANY>CBS Records</COMPANY>
		<YEAR>1988</YEAR>
		<PRICE>9.90</PRICE>
	</CD>
</CATALOG>

And the two handlers I've derived from GeneralHandler is TabHandler and ComaHandler, which as far as I can tell from the question should strictly be used for generating a coma delimited and a tab delimited file showing the CD's info. Thus, if I wanted to use an asterisk as a separator, i would create an AsteriskHandler class. The classes are so simple and how anyone can derive anything else from that I can't see.

As for readability my argument is that:

Language: C++ (QT)
bool startElement(const QString &namespaceURI, const QString &localName, const QString& qName, const QXmlAttributes &atts)
{
    //Some functionality 
}

is a lot more than just

Language: C++ (QT)
bool startElement(const QString& qName)
{
    //Some functionality
}

Someone not so experienced might at first try and figure out where the other parameters come into play. Where if is out of site then it is out of mind.

I think it more appropriate especially when you only want the class to do something very limited(I'm deliberately putting in a restriction). In the end though the whole question is actually stupid, because I can't see the point in defining separate classes in the first place for creating a tab and a coma separated files. You can just have one class and pass the separator as a parameter in the constructor, which will allow it to use any separator. But I guess its just to teach us the pattern....

Maybe I should post you the whole question? Then you'll maybe understand my frustration with it in the first place. If the classes weren't so specific, to the level were you can actually just implement it as one class with a few parameters, then I wouldn't even have considered it.

Thanks though; I'll listen to the older and wiser and not do it. Got to get my assignment done now and give it in. Deadline is tonight.