FiveTech Support Forums

Marc,

I see you are using Harbour and I use xHarbour. Try putting double colons in front of super.

::super():New(...

James

Nages,

1) What are the important features of TData which we can not get with TDataBase?
2) What is that TRecord can do what TDataRow can not do?

I will have to get back to you on that when I am at my office. I have never looked at TDataRow so I don't know about that one. I wrote the code for TData and TRecord about 15 years ago when there was no TDataRow. An TDatabase was missing a number of capabilities that I needed at that time.

We would be very much glad if you can show some illustrations of using TRecord to create single objects.

See the TCustomer object in a previous post in this thread for an example. It is completely encapsulated and has a method of its own. It can lookup and save it's own data. No table has to be opened before you can use that class.

James

Here are two sample single-item objects reflecting real-world objects. None are database objects. They all inherit from TRecord, not TData. However, they may use an internal data table object to lookup the data that they contain and/or save it.



I'm sure you can figure out the code without even any comments.

Here is the method to finalize an invoice object. It updates two fields, one in the invoice object and one in the customer object. Simple--only four lines of code! Note that the invoice object contains it's own customer object.


This is just an example of the types of things you can do with single item objects.

James

I understand and like it.

Can you please give a small sample one class deriving from TRecord. Then I like to see if I can do the same thing using TDataRow.

Marc,

Were you able to get the Customer class example to compile after changing SELF to ::SELF?

James

Were you able to get the Customer class example to compile after changing SELF to ::SELF?

Yes, and it works. Thanks

oCustomers:seek( cCustNo )
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?

Maybe you can confirm some items.

CLASS TCustomers from TDatabase

Maening that I create a new class Tcustomer and ALL actions insite Tdatabase will become available.
Then you create your own methods.

METHOD printCustList()

Method printCustList() Class TCustomers
Code for printing the report
RETURN NIL

Then from everywhere I can use : oCustomer:printCustList()

Also : oCustomers:seek( invoice->client ) can be done everywhere without thinking of alias..

I just mis 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)

I agree that with OOp everithing is located in the class Tcustomer, and maintaining the code is better, since It stays togetter.
I confess, that in a larger project with many functions, we loose time because we don't always know where they are ....

General question :

I looked into some code and see :


if ValType( bRedefineControls ) == "B"
Eval( bRedefineControls, oDlg )
endif
::Default()
oDlg:Hide()
::SetOption( Len( ::aDialogs ) )
::Refresh()

1. Why do you use the :: and what does it stand for.
2. Every class you make has to be a single prg right ? or do you do this for better maintenance options ?
3. They have to linked in into the program (have to look where and how)

Marc Venken wrote:1. Why do you use the :: and what does it stand for.
2. Every class you make has to be a single prg right ? or do you do this for better maintenance options ?
3. They have to linked in into the program (have to look where and how)

1. :: stands for "self" that is the current object.
2. No, you can put any class you want in a single PRG.
3. I didn't understand the question, sorry.

EMG

Enrico Maria Giordano wrote:

Marc Venken wrote:1. Why do you use the :: and what does it stand for.
2. Every class you make has to be a single prg right ? or do you do this for better maintenance options ?
3. They have to linked in into the program (have to look where and how)

1. :: stands for "self" that is the current object.
2. No, you can put any class you want in a single PRG.
3. I didn't understand the question, sorry.

EMG

3. Since it can be all in 1 prg, I can compile it with the samples buildh

Marc,

At James urging, I took a huge project and converted it to OOP ... and the code reduction was about 35-40%. I also found that when I had everything as functions, I often wrote new functions for specific tasks, and in doing so, I sometimes had 5 or 6 ways ( functions ) to handle essentially the same tasks. That was hard to keep debugged.

I started with a chart. I looked at all of the major processes I would have, then set a .prg for each. Each file may have several classes. I would create a class for each database ( inheriting from tData, and using tRecord also ), and would have the methods for the database, ie. add, edit, delete, browse, and saving the records. Then I created a class for processing the records with associated methods. These, of course, called the database classes as appropriate.

In the end, everything was organized in easy to track .prg files, it was easy to document, and using meaningful names, the code was easy to view and understand.

The reason you use this instead of Functions is simple. A class can inherit from another class which gives it all the capability in the original class plus what you wish to add. You eliminate a lot of redundant code.

Tim

Marc,

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?

Yes, just look at the class definition section of TDatabase.

CLASS TCustomers from TDatabase

Meaning that I create a new class Tcustomer and ALL actions inside Tdatabase will become available.

Yes, that is inheritance. Likewise when start to design objects, look for common code and move it up the hierarchy.

Then you create your own methods.

METHOD printCustList()

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.

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)

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.

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 ....

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

Marc,

If you post a small section of your code that uses the customer table, I will show how you can do the same with a customer table object. Or, any other table if you prefer.

James