Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Create VS Define Classes
Message
From
16/03/1999 01:49:33
Mark Austen
Schooner Software Limited
Msida, Malta
 
 
To
15/03/1999 23:01:29
General information
Forum:
Visual FoxPro
Category:
Classes - VCX
Miscellaneous
Thread ID:
00196090
Message ID:
00197941
Views:
24
Bonnie,

It is true to say that you cannot reap the benefits of OOP unless you design your application at the start of the project rather than in the middle, at the end or not at all. One of the things you design is the class heirarchy and after a few projects your class heirarchy will start to form the basis for your application framework.

So, your utility objects are all palced in a class library called something like cUtility.vcx, the data handling in cData, special forms in cForms, security in cSecurity and so on.

As for the code, it now resides in the various methods and event methods of the classes and you're right, these are all separate places in which code may be placed. However, we are much better off than in the FP26 days since we are able to get at the code much more easily. You can select the method from the properties box or double click on an object to bring up the code window. Once in this code window you can use the two combo boxes at the top of the window to select the object and the method or you can simply page up or down to the top or bottom of the current code and page up or down again.

Now none of this is any use to you unless you organise your method code and, in the case of new methods, name them correctly. It is much like the argument about the naming of procedures and functions except that there is no practical limit to the length of a method name. Obviously there is a limit but you shouldn't be assigning names longer than about 30 characters anyway!

So, you carefully design your classes as well as the heirarchy. Unfortunately, this is where it gets tricky. The first thing that most newbies do is to put code directly into the method and quite a lot of the time it doesn't belong there, but should pass the action to another object. The example that is usually used here is that of navigation buttons. The temptation is to put 'go top' in the click event mehtod of the 'First' button and so on, but this is contrary to the principles of OOP since you can't reuse these buttons. Instead you'd create an object whose responsibility is to navigate around a table and the code in your click event method would call the appropriate method of the navigation object.

It is fairly essential that you comment your code one way or another since delagation actions to other objects can really make things look like spaghetti, only look like, mind, since if your classes are well designed this doesn't happen. I usually put the name of the class and class library in the comment so that I know where to look for the method called at that point!

However, the main advantage of this delagation, especially if you name your methods correctly, is improved understanding due to data hiding, that is, you don't need to know what's happening in the black box as long as it does what the documentation says it does. Going back to our navigation button, the code in the click event method of the 'Next' button would read something like:

ThisForm.oNavigator.MoveNext()

The MoveNext method does a load of checking to make sure that there is a next record or an open table in the current work area or that after the skip command it hasn't gone beyond the last record, all this is hidden away and you don't need to bother about it.

Now, in the good old days of procedural programming, you did the same thing by calling the MoveNext function instead. It's just that in OOP, all the actions associated with navigating through a record set are put into a single class and kept together.

Does this help at all?

>You know one thing that really bothers me is this .... years ago someone, I think it may have been Drew Speedie, had made a case for not putting things in screen code snippets (FPW 2.6), but just calling the functions from the code snippets and the functions were all in the prg that did the calling of the .SPR. I heartily latched onto this concept because all the code for a particular screen was all contained in one prg and not spread out in a gazillion code snippets. It seemed to me a much better way of doing things. Now, with OOP, we're back to putting stuff in a gazillion different places, and this is why I think I may be misunderstanding some basic concepts and I may not be doing things correctly. It seems like a step backward to me.
Regards,

MarkA
Previous
Reply
Map
View

Click here to load this message in the networking platform