Marc,
[quote:3vy1ntrk]I suppose that I have to look into the source of Tdatabase to see what actions (like seek..) are possible? Or is there a manual for this?[/quote:3vy1ntrk]
Yes, just look at the class definition section of TDatabase.
[quote:3vy1ntrk]CLASS TCustomers from TDatabase
Meaning that I create a new class Tcustomer and ALL actions inside Tdatabase will become available.[/quote:3vy1ntrk]
Yes, that is inheritance. Likewise when start to design objects, look for common code and move it up the hierarchy.
[quote:3vy1ntrk]Then you create your own methods.
METHOD printCustList()
[/quote:3vy1ntrk]Yes, but not with that type of name. One of the great features of objects is that you can pass them around. Since they are encapsulated you only have to pass one item (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 pass any object to a routine (like a menu) and just do oObject:print(). Since you might want to have a number of reports using the customer table object then it would be better to create a document class and subclass all your documents from that. This way each document object can have it's own Print() method which it might inherit from the parent Document class.
Also : oCustomers:seek( invoice->client ) can be done everywhere without thinking of alias..
Yes, but it is a lot more than just the alias, depending on circumstances you may have to save and restore the state of the database (current pointer, filters, sort order, etc.). This should be built into your class structure at a higher level so you don't have to do that each time you access the database.
Also consider that the invoice object could contain it's own customer object, so you probably wouldn't have to do that seek.
[quote:3vy1ntrk]I just miss the point of using this instead of a function.
Function printCustlist(cNum)
Code for printing report
Return NIL
I also can say : printcustlist(Cust->CNo)[/quote:3vy1ntrk]
One reason is database state as I just mentioned. Inheritance, encapsulation, polymorphism, and granularity are the four doctrines of OOP. Using inheritance you attempt to write each bit of code only once, encapsulation keeps your code from breaking, polymorphism allows you to access many objects with the same code, and granularity (breaking code into smaller chunks) makes it easier to understand and maintain. These concepts do take some time to get your head around, but there will come a time when you get to the "Ah Ha" moment. Guaranteed! Then you will never go back.
As Tim mentioned you can get large reductions in your code by using granularity and inheritance. For instance you may be using the same header and footer in every report and you are writing that same code every time. By moving that code to a parent class you only have to write it once. I have reduced old code over 50% using OOP.
[quote:3vy1ntrk]I agree that with OOp everything is located in the class Tcustomer, and maintaining the code is better, since It stays together. I confess, that in a larger project with many functions, we loose time because we don't always know where they are ....[/quote:3vy1ntrk]
Yes, these are also good points. See you are already beginning to see some benefits.
Now that you have a working TCustomer table class, try writing a small program to test it. Then maybe try using it in your existing code.
Regards,
James
↧