-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Dne Thu, 25 Mar 2010 11:06:06 +0100 Dieter Adriaenssens <dieter.adriaenssens@gmail.com> napsal(a):
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).
Well SQL export is used in several other places (table move/copy and I think also some synchronisation or other recently introduced feature uses it).
* 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)
Right.
The import-module can be conceived in the same way, I mean : basic functionality that uses the abstract class, with derived classes for specific types (SQL, csv, ...). 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.
They really do not share code (unless they use external library like php-excel). - -- Michal Čihař | http://cihar.com | http://blog.cihar.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkurVTcACgkQ3DVS6DbnVgR/pgCfU+ebVQdQ5Szrx8yASY2h4TQf qjYAoLoHE2j+joDsi5Erv6MwCnH0ghSm =WF4h -----END PGP SIGNATURE-----