About EZForm architecture

28 04 2006

I’m wondering if I’ve made a good architecture for this library. In fact, it is not fully object oriented.

Actually, EZForm is made of one class that imbeds all the code, with some switch/case within. It’s more a functionnal approach than an object one. A really object oriented approach may use one class for each datatype supported in the XML file. Those classes may inherit from an abstract superclass “EZFormDataType”, that gives the abstract methods to be implemented in the subclasses (types).

If we compare the pros and the cons, we may have something like that :

Current architecture :

  • + : One instance of one class only – memory saving, excution time saving
  • + : Code reuse by grouped cases (for example, string/text/customtype uses the same input field) – memory saving
  • - : Source code may be a little harder to read, but I’m very displined, I comment and indent everything in a readable way

Pure object oriented architecture :

  • + : One class for each datatype – better readability
  • +/- : Some code may be reused by this way, but probably less than in the functionnal way
  • + : It’s modish :)
  • - : One instance of type class for each form field – memory consuming, execution time consuming

I don’t have an opinion if it would be interesting to migrate to a full object oriented code. Your comments are really welcome :D


Actions

Informations

Laisser un commentaire

Vous devez être connecté pour poster un commentaire




Parse error: syntax error, unexpected '/' in /mnt/106/sda/6/e/prog13/wp-content/themes/freshy/footer.php on line 18