Hello Dieter,
Le 25 mars 2010 à 11:06, Dieter Adriaenssens a écrit :
I agree that Export is a good candidate to rewrite in OO, for several reasons :
- It's a stand alone module, nothing major depends on it (I think).
- It's well suited for an OO approach, as you can create an abstract
export class, and then create specific classes (for PDF, SQL, ...) that derive from that class. The export functionality then uses the (abstract) export class, and depending on the instance, the right output is generated. (The concept is called polymorphism if I'm not mistaken)
Yes, that's the point!
But I'm wondering if it might be useful to combine the export/import classes into one class? To keep a better overview it's maybe better to keep the import and export classes separate.
I agree with you, it's better to have a clear separation between both : Basically : - Export : Export class > Rowset > export plugin - Import : import plugin > Dataset > Import class > DB
Rewriting the entire project to use the PMA_Table class as an object, is a bit too big for one GSoC project, I think.
Absolutely. For my project I consider writing and using a PMA_Table class that meet my needs. But following the SOLID principle (http://en.wikipedia.org/wiki/Solid_%28Object_Oriented_Design%29), the PMA_Table class should be open to extension and future development (rewriting in our case), and closed to modification.
Maybe you could convert the PMA_Table class to something that can be instanciated, but still works when used static. Or maybe a new Table (together with a Database, Rowset, ...) class should be created, to start using as an object in your export/import module (and later in the rest of the project.
PMA_Table is already 1149,I fear that adding the needed non static methods inside will grow the number of lines ... I'll look into the problem and find a "compromise".
Thanks for your advices Dieter !
Regards, Edouard