-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi
Dne Thu, 25 Mar 2010 11:06:06 +0100
Dieter Adriaenssens <dieter.adriaenssens(a)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-----