Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Proper Encapsulation Techniques?
Message
De
31/08/1998 14:47:45
 
Information générale
Forum:
Visual FoxPro
Catégorie:
Classes - VCX
Divers
Thread ID:
00131613
Message ID:
00131619
Vues:
19
I think the premise, that "modifying a bizobjs data from outside the bizobj is bad behavior for a properly encapsulated class", is questionable.

The real question is why does the client need access to the particular data, and shouldn't the class be providing this service.

Anyway, in the two scenarios described below, Example two is not recommendable because of the rather shitty interface. As for example 1, and _Access or _Assign method, if you are using VFP6, is probably better.

But the best way to go may be something like
  SELECT Customer
  SCATTER NAME oCustomer
  ...
  loCustomer.Update( oCustomer)
*---------------------------------------


>When using business objects accessing and modifying a bizobjs data from outside the bizobj is bad behavior for a properly encapsulated class. In order to maintain class integrity the developer has two options, each with its own drawbacks.
>
>One option is to create a method for each field that needs to be replaced. For example, a developer might create a SetCustomerName() method which would replace the customer name field with a passed parameter. This is an excellent way of divorcing the data from the implimentation. The controlling object doesn't need to know from which table customername is being pulled or how it is formatted. However, this can become awkward if there are many fields that need to be replaced.
>
>The other approach is to create a generic method that will accept a view, a field and a value, select that indicated table and replace the indicated field. For example, oCustomer.Replace('lv_customer', 'name', 'John Smith'). This allows the class to maintain some data integrity and a single method is all that is needed. However, with this implimentation object-oriented encapsualtion rules are violated. Specifically, the calling class needs to know details about the table and field the data is to be placed in.
>
>To illustrate the two appraches:
>
>LOCAL loCustomer
>
>*-- Create the customer bizobj
>loCustomer = CREATEOBJECT('bizCustomer')
>
>*-- Bring in some data just for testing
>loCustomer.Requery()
>
>*-- Illustrate two different ways of replacing the
>*-- customer name.
>*--Example 1
>loCustomer.SetCustomerName('Michael G. Emmons')
>
>*-- Example 2
>loCustomer.Replace('lv_customer', 'name', 'Michael G. Emmons')
>
>loCustomer.Save()
>

>
>I'd be curious to hear how other people deal with situations like this.
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform