Information générale
Catégorie:
Codage, syntaxe et commandes
Versions des environnements
OS:
Windows Server 2012 R2
Network:
Windows Server 2012 R2
Virtual environment:
VMWare
>There is only one strong reason for doing this (bundling multiple functions into one PRG), and it would be to implement abstraction / polymorphism.
>
>You would create the same function in two different PRGs:
>EmployeeProgs.PRG -> FUNCTION Save
>CompanyProgs.PRG -> FUNCTION Save
>
>If you are in the Employee.SCX, you set procedure to EmployeeProgs.PRG
>If you are in the Company.SCX, logically set procedure to CompanyProgs.PRG
>
>Both screens can be generically calling SAVE(), while obviously the actual actions are different from each other.
>
>So if someone were to create a procedural code, that would be the way to go. Of course it does not make sense because with OOP you have much better ways to accomplish this, but in theory that is the one case where you cannot work with separate PRG's.
Boy, would that make debugging hard. In an OOP world, where those are methods and thus context is clear, sure. But for procedural code, I'd consider that bad practice.
Tamar
Précédent
Suivant
Répondre
Voir le fil de ce thread
Voir le fil de ce thread à partir de ce message seulement
Voir tous les messages de ce thread
Voir tous les messages de ce thread à partir de ce message seulement