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.
It comes down to standards and practices. Using a common methodology in a system means you learn how it works, and then rely on that design. The design Christian outlines is quite common in VFP code that derived from FPW, FPD, or FoxBASE+. I have seen it at several companies.
Précédent
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