D
dbeavon
Guest
Your quote - "Avoid inheritance, polymorphism..." - seems out of context. Check your link again and look for the very first section (4.3.1) under "general principals" which says the exact opposite: -> Avoid duplication and manual tasks, so necessary changes are not forgotten (DRY - the main reason inheritance exists) ->Use polymorphism instead of repeated switch statements IMHO, object oriented patterns are a great tool to have in your toolbox as a software developer. A person who doesn't have OO in their toolbox will be averse to it altogether, and will claim that it is too complex. Most languages which are used for business programming (ABL included) allow for the standard OO patterns to be used -- even if it meant that that the OO portions had to be introduced at a later time in the evolution of the programming language. OO is not a just a fad anymore. 
Further, I can't imagine *not* using OO for programming in the business layer. There is potentially a data layer *below* that (locking a single record and updating a field) which perhaps benefits less from OO than the logic does, but that is the exception. Nowadays if I see business layer programming which is written without OO patterns, I assume it is because the developer has not been properly introduced to OO programming yet.
Continue reading...
Further, I can't imagine *not* using OO for programming in the business layer. There is potentially a data layer *below* that (locking a single record and updating a field) which perhaps benefits less from OO than the logic does, but that is the exception. Nowadays if I see business layer programming which is written without OO patterns, I assume it is because the developer has not been properly introduced to OO programming yet.Continue reading...