You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
UblReader and UblWriter do lots of heavy lifting and are nicely split into specific methods for specific parts, however, it is practically very difficult to extend these classes.
This would be easier, if:
methods were 'protected' instead of 'private';
UblReader had Invoice and Invoice Line factory methods (i.e., createInvoice() and createInvoiceLine()) instead of creating these objects with 'new' inside some huge method. That would allow easy use subclasses of Invoice and InvoiceLine.
The reasoning is real systems wander off standards and this improvement in extensibility would help with cases when something additional or something differently must be parsed in XML. In my particular case I am dealing with government system which is somewhat lax with rounding and totals, and so I have requirement to get some values 'as-is' from XML rather than rely on them being derivable.
The text was updated successfully, but these errors were encountered:
UblReader and UblWriter do lots of heavy lifting and are nicely split into specific methods for specific parts, however, it is practically very difficult to extend these classes.
This would be easier, if:
The reasoning is real systems wander off standards and this improvement in extensibility would help with cases when something additional or something differently must be parsed in XML. In my particular case I am dealing with government system which is somewhat lax with rounding and totals, and so I have requirement to get some values 'as-is' from XML rather than rely on them being derivable.
The text was updated successfully, but these errors were encountered: