FiveTech Software tech support forums

... programming (OOP), especially regarding modularity and encapsulation. However, it lacks classical OOP elements like inheritance and polymorphism. The use of multiple levels of patchers and preprocessors for composing components resembles the OOP principle of composition. This enhances ...

Antonio, It was me that requested the End() method. The reason was to conform to polymorphism with this class. Every other class has an End() method but TDatabase only had a Close() method. There is a new Procedure called TD_Destroy() that was also added in ver ...

... Yes, I know it has a Close() method, and that is consistent with the CLOSE statement. However, as an object, the Close() method name violates the polymorphism concept. Most of the other classes have an End() method. So if you just add this line: METHOD End() inline ::Close() We can then use oDBF:End() ...

... business objects are the most important advance one can make in programming. As I have said before, the main concepts used in OOP are granularity, polymorphism, encapsulation, and inheritance. I am using all of these here. Inheritance: This class is inheriting from my TRecord class which inherits ...

... (the object) to get access to all the data and methods of the object. Encapsulation is one of the doctrines of OOP. Another doctrine of OOP is polymorphism (same naming). So it would be better to name the method "Print" and use the same name for other classes too. This way you can ...

... should be the last statement after specifying all settings. Thanks. Obviously, I didn't know that. It is now in my notes. This is one reason that polymorphism (like naming) is important and useful in OOP. If the syntax for the browse was: DEFINE XBROWSE oBrw...ACTIVATE BROWSE oBrw Then there would ...

... the database class already does this in it's Close method so you can just do this: oDBF:close() Actually, to be consistent with standard naming (polymorphism) it technically should be: oDBF:end() But our TDatabase class doesn't have an End() method so we have to use the Close() method. The advantage ...

It would seem that it would make sense to have a different class for each data source. Each class should follow polymorphism so each is syntax compatible. Then you just link-in the class you need. Making separate classes makes each one simpler, with less code, and easier to read ...

James,

thank you very much for this tip, how to use inheritance and subtyping, polymorphism or overriding. How easy OOP can be

... we have and what to expect from it. So far I am getting the impression that you believe in OOP, but not in inheritance, encapsulation, or polymorphism. So, I am still left with my original impression that you don't really understand OOP. Regards, James

... have a TData class for DBF access, a TRecordset class for SQL recordset access, and a TArray class for array access. These all were written using polymorphism, so they all have the same methods and data. Any class can be substituted for the other so you can access data in all those formats. I ...

... dbfPATIENT ) Is there a reason you used Create() as your constructor method rather than the standard New()? This is a violation of the polymorphism principle. >This means that any class can access the currently selected patient, for example, without having to pass the patient object ...

... reading and writing only certain fields means that you have to have different load and save methods for each situation. This violates the polymorphism rule of OOP. You can't just call oObject:load() you have to use oObject:load1(), oObject:load2(), etc. depending on the situation. So you ...

... reading and writing only certain fields means that you have to have different load and save methods for each situation. This violates the polymorphism rule of OOP. You can't just call oObject:load() you have to use oObject:load1(), oObject:load2(), etc. depending on the situation. So you ...

... reading and writing only certain fields means that you have to have different load and save methods for each situation. This violates the polymorphism rule of OOP. You can't just call oObject:load() you have to use oObject:load1(), oObject:load2(), etc. depending on the situation. So you ...