Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Encapsulation problems
Message
 
To
03/06/1998 01:18:40
David Moreau
Iglesia Ni Cristo - Dnm
Quezon, Philippines
General information
Forum:
Visual FoxPro
Category:
Classes - VCX
Miscellaneous
Thread ID:
00104274
Message ID:
00104471
Views:
23
>My first difficulty is using protected methods and properties. I find myself unable to access these functions and properties from instantiations of the class. Is this correct behavior? Is this reaasonable behavior? I often find myself declaring properties and methods public, even when they should not be.

Yes, this is the correct and reasonable behavior, David. Protected properties are normally used for internal processing inside an object. Anything that contains sensitive information or would break the functionality of the object if some outside process changes it's value. For those properties which need this level of protection, but still need to be accessed outside of the object, the standard OOP course of action is to define methods in the class which would allow access to the protected property, such as AccessProtProperty() or AssignProtProperty(). If your property needs to be visible everywhere AND does not need this level of protection from things outside the object, then is should not be defined as protected.

On a related note, stay tuned for VFP6. MS finally added automatic Access and Assign methods to all class properties. What this means is that every property in every class automatically gets an Access and Assign method. For instance, if you try to programatically assign a value to a property, it will automatically trigger the property's Assign method, or if you try to read a property's value, it will automatically trigger the property's Access method. Not many developers realize the value or impact this will have. Let me give a couple of brief examples...

Here is an example of a property which holds a calculated value which is calculated on-the-fly. You have an object property called nTotalCharge. This property's Access method could be something like...

THIS.nTotalCharge = (THIS.nProp1 + THIS.nProp2) / THIS.nProp3
RETURN THIS.nTotalCharge

Then, whenever this property is used somewhere, such as...

? oInvoice.nTotalCharge

...it would automatically recalculate. Here is another example. You have another property in the same object called nDiscount. This property has the following Assign method...

LPARAM nDisc
IF oAppSecurity.SecurityLevel(cUserName) >= 5
THIS.nDiscount = nDisc
ELSE
= MessageBox("Insufficient security rights to give the customer a discount.")
ENDIF

Then, if you you have code such as...

oInvoice.nDiscount = 0.15

... it will not "stick" unless the user has a security level of 5 or higher. The point is you will be able to do cool stuff such as create read-only properties or display calculated values on forms or reports with ease! All this stuff will be encapsulated within the object, where it should be. This also help make you code more modular and reusable.


>My second difficulty concerns using an array in a class. In my case, this array is a hash table to the data in the ComboBox. Since there may be multiple instances of the class, and since the hash table is specific to the particular instance, the class should contain the array. What is an elegant way of hiding an array inside a class such that each instance of the class has its own distinct instance of the array.

Easy, David. Just define an array property in the class such as aArray[1]. You can redimension it or do anything with it in method code, such as DIMENSION THIS.aArray[100] or THIS.aArray[i] = cAnyValue.

Now, you can create as many objects as you need and access each specific array independently. I think you are getting confused by the concept of classes. Remember, you define a single class and then create as many objects based on that class as you need. The class this the blueprint, the object is the actual thing based on that blueprint (and you access each object by the object name you gave it). Here's how it works in code...

oObject1 = CREATEOBJECT("MyClassWithArray")
oObject2 = CREATEOBJECT("MyClassWithArray")
oObject3 = CREATEOBJECT("MyClassWithArray")
oObject1.aArray[1] = "This is one value"
oObject2.aArray[1] = "This is another value"
oObject3.aArray[1] = "This is even still another value"

>This is my first day in Universal Thread and I am still learning how to better navigate my way. Please forgive me if these questions are already answered in some area that I have not yet found.

Welcome! I hope this all helps.
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform