I can just add few thoughts:
First of all - this sceencast recommends to subclass existing class, but i thing there asre some cases when it is better to tweak existing class. The most often case - when existing class has bad structure (for example LedgerJournalCheckPost in 3.0 - i don't know about 4.0 so much). If you have one large method which does all you can not just overide it to add some functionality - you often have to copy all it's body to the child and tweak it. I you do so you will have more problems when upgrading to the next version: you have not only to upgrade method of existing parent, but to modify all copied parts of the child and there is no obvious clues to find what parts to modify.
Second, what can be done to make upgrades less painful:
- Interfaces - there havte to be more documented interfaces - so Ax devs will know what they can change and what cannot to make Ax backward compatible.
- Unit tests as part of Ax package - all unit tests developed by Ax team have to be shipped with Ax to enable partner or customer developers ensure they haven't breaked anything
- Events - SAP R/3, as i know, have concept of events - you have not to modify existing code to be informed about some thing ocuured in system - you just subscribe, say, to journal posting and can make extra transaction if you want. So your customisation code isn't mixed with the existing code.
- Better code structure - i think there is no excure for very big methods for example. Better code structure can be easy reused by customer programmers and can be seft documented and testable.
No comments:
Post a Comment