25 Mar
2010
25 Mar
'10
12:53 p.m.
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