De simples relations d'objet

De simples relations d'objet

De simples relations d'objet : Plusieurs milliers de conseils pour vous faciliter la vie.

les objets comme les exposer eux-memes et de leurs relations. Dans cet article je vous montre comment faire.
Simple les Relations d'Objet
Dans le dernier article, nous avons examine la façon dont le classique des Stocks, commandes et les besoins du Client peut etre modelise comme trois business objects, chaque exposant leur etat par l'intermediaire des caracteristiques bien precises. Bien que ces objets peuvent maintenant etre utilisees en tant que-est (bien que de maniere tres limitee - nous n'avons pas encore defini de la maniere dont leurs informations persistantes!), elles n'ont aucun concept de relations. En d'autres termes, comment pouvons-nous savoir quel Client a passe une Commande, et pour qui StockItem?
Il est interessant a ce stade de faire une pause et de penser a comment ce serait normalement etre traitees dans un non-OO, centrees sur les donnees de la mode. Generalement, un enregistrement de base de donnees representant l'Ordre de s'exposer, deux champs supplementaires, un stockage d'une cle etrangere de la table Client, et l'autre a la StockItem table. L'un des defauts de cette approche a deja ete demontree: tous les champs de base de donnees sont exposes a la meme il n'y a pas de concept d'un champ plus 'prive' que l'autre. Bien sûr, il est possible de l'exprimer dans une certaine mesure, avec une vue de base de donnees, mais les donnees brutes de niveau de champs ne peuvent pas etre distingues en termes de visibilite ou le role que par le nom, et de cette façon, la folie se trouve.
nous allons maintenant examiner comment nous permettrait d'acceder a des informations sur le client ayant passe une commande donnee dans ce modele traditionnel. En supposant que nous avons eu l'information a propos de l'ordre dans une sorte de jeu de donnees (peut-etre un TQuery), nous serait d'inspecter la valeur de la clientele champ de cle etrangere, la construction d'une nouvelle requete de selection de la table des Clients basee sur cette valeur, puis inspecter les donnees renvoyees. Notez que c'est tout a fait beaucoup de code a ecrire, necessitant au moins un objet local (le client dataset) seront construits, et un tel code prolifere rapidement si nous avons besoin d'acceder a l'element de stock, ou a d'autres elements de donnees. Une alternative a cette approche est de selectionner toutes les donnees en une seule requete a l'aide d'un multi-jointure de table. Ce triomphe de la quantite de code a ecrire, mais introduit un autre probleme - le codage en dur des donnees les relations au sein de la chaîne de requete. A rien d'autre qu'une simple application de telles expressions sont reprises dans de nombreux endroits differents tout au long de la source - et il est interessant de noter que le compilateur ne peut rien faire pour l'aider dans l'exactitude de telles requetes. Si vous modifiez la base de donnees de base (peut-etre en modifiant le nom ou le type de champ de cle etrangere dans une table), alors il est necessaire de recourir a l'echelle de l'application de recherche et de remplacement des techniques pour trouver des occurrences qui pourraient avoir besoin de mise a jour. Dans cette situation, il est tres possible que certains rarement formulaire sera a l'automne a travers le net et conservera un jour de la reference a un champ qui n'existe plus. C'est une erreur d'execution en attente de se produire. Il est possible de placer ces requetes dans un systeme centralise de donnees module, mais c'est juste de la geographie, et qui necessite des soins afin que les deux parties distinctes de l'application n'essayez pas d'utiliser la meme requete en meme temps.
de Retour dans le bon monde de bien-construit business objects exposer l'equivalent d'une cle etrangere (dans le formulaire de notre TObjectID) comme un bien public est un anatheme. Listing 1 montre comment ce serait un look et un rapide coup d'œil montre que nous avons falsifie notre interface publique avec des details que l'on prefere ne pas l'exposer. Apres tout, si ces proprietes sont rendues publiques alors tout le monde peut supposer qu'ils ont le droit de les utiliser.
de le Faire avec des objets
l'orientation de l'Objet, nous offre une beaucoup plus naturel d'exprimer ces relations plutot que par le biais implicite champs de cle etrangere - nous pouvons exposer l'objet en tant que propriete. Cela nous permet d'utiliser de telles constructions de la Commande.Les clients et les commandes.StockItem pour acceder aux objets de notre ordre. Notez que cela est naturel et concis façon d'exprimer les relations et cache completement les details de mise en œuvre. Si nos secondaire objets eux-memes exposer les relations (telles que la societe pour un client) puis la recherche de l'adresse d'expedition pour une commande peut etre aussi simple que d'utiliser de l'Ordre.Client.De l'entreprise.L'adresse, un outil extremement puissant de construire. Il est interessant de souligner que si plus tard, nous avons decider de retirer la Societe de la relation (ou, en effet, de changer la façon dont il est mis en œuvre), alors le compilateur detectera tous les cas tout au long de l'application ou il est utilise de maniere incorrecte, et la compilation echouera jusqu'a ce que toutes les questions sont abordees. Deja l'orientation de l'objet nous a aide a parvenir a une plus fiable application: on peut faire des affirmations sur le fait que toutes les modifications ont ete apportees.
en Supposant que nous allons exposer nos objets lies a des proprietes, comment cela va etre mis en œuvre? De toute evidence, nous allons avoir besoin d'un prive 'reserve' sur le terrain pour stocker une reference a l'objet correspondant. Une approche naïve serait de creer cet objet dans le constructeur et simplement la propriete pointant vers le domaine prive. Cette approche a deux principaux problemes indesirables et les autres catastrophes. L'indesirable probleme, c'est que nous allons subir le fardeau de la construction de cet objet chaque fois que nous construisons le parent. En supposant que nous remplir les proprietes de l'objet du stockage persistant, nous ont un impact sur les performances d'execution de notre application avec la surcharge de la construction d'une nouvelle instance et de faire une base de donnees access. En general, il est utile de prendre quelques precautions pour garder le constructeur le plus leger possible. L'extension de cette situation, il peut etre vu que si la construction de l'objet A est a l'origine de l'instanciation de l'objet B, dont le constructeur causes de l'instanciation de l'objet meme alors que nous allons entrer dans le monde de la recursivite infinie et la premiere chose que l'utilisateur va voir, c'est un message d'erreur memoire. Cette situation n'est pas plus que le commun 1-1 entite-relation.
La solution a ce probleme est une technique connue sous le nom de construire a la demande, ou la construction paresseuse. Il utilise l'idee de retarder la construction de l'objet jusqu'a ce que juste avant de la premiere fois qu'il est necessaire. Pour les futurs accede a la deja instancie un objet est simplement retourne. Cette retards coûteux operations jusqu'au dernier moment possible, tout en restant transparent pour tous les utilisateurs de notre classe. Listing 2 montre comment cela peut etre mis en œuvre. Pour le moment, nous supposons que l'ensemble de nos TPDObjects offre une methode de Chargement qui remplit les proprietes de l'objet de certains types de stockage persistant, compte tenu d'une pertinente ID d'objet unique.
Tirant parti de la puissance des objets

Cela semble resoudre notre probleme d'une cascade de la construction, et est une technique qui peut etre utilisee a bon escient, avec toute la propriete (et pas seulement de business objects), qui est potentiellement coûteux a construire. Toutefois, permettez-nous de penser a ce qui arrivera si nous appliquons cette technique a d'autres objets. Quel sera le code de la fonction d'acces de la Commande.StockItem ressembler, ou en effet le cas general de X. Y? Le resultat sera tres similaire a la Liste 2, substituer de nouvelles references pour les champs prives et, surtout, le type de la classe en cours de construction. Plutot que de repeter le meme code (et courir le risque de ne pas mettre en œuvre toutes ces fonctions d'accesseur a l'identique), est-il une maniere dont nous pouvons utiliser le pouvoir de notre hierarchie d'objets pour reduire ce fardeau de codage? Sans surprise, la reponse est un grand oui.
Ce que nous aimerions faire est de fournir une sorte de fonction d'utilite dans notre base TPDObject classe (partie de notre programme-cadre independant) qui effectue la meme fonction, mais peut etre parametre en quelque sorte. Le detail que nous aurons besoin de passer comme parametres sont l'espace reserve pour l'objet en cours de construction, l'ID doit etre charge, et une certaine façon de construire la classe correcte. Pour atteindre ce dernier parametre, nous allons utiliser une construction appelee une classe de reference, qui est une variable qui contient un type specifique dans le cadre d'une hierarchie de classe. En Delphi, il est defini avec la classe de mot-cle. Le Listing 3 montre l'evolution de notre Cadre de l'unite de fournir une telle fonctionnalite. Notez que l'objet de l'instance seront effectivement mis a jour dans la routine et c'est donc l'une des rares occasions ou un objet ne doit etre passe en parametre var.
Un autre element a noter est que le constructeur de TPDObject a ete defini comme virtuel. Sans cela, notre routine generique ne serait pas en mesure d'appeler un constructeur de la classe, et serait toujours construire des classes de type TPDObject. C'est la meme approche que celle utilisee pour les composants a l'interieur de Delphes, et la consequence est la meme: tous nos constructeurs pour notre TPDObject les descendants doivent maintenant utiliser le remplacer mot cle.
Comment nos fonctions d'accesseur sur notre business objects maintenant utiliser cette methode? Leurs interfaces doivent rester les memes, sans parametre. Cependant, nous pouvons mettre en œuvre l'appel a une seule ligne de code comme indique dans le Listing 4. Deux facteurs doivent etre mis en evidence: le resultat de l'appel doit etre transtype a TCustomer car il renvoie a un type de TPDObject, bien que le veritable instance sera du type correct. Deuxiemement, le secteur prive FCustomer champ doit etre change de type de TPDObject. C'est parce que Delphi insiste sur le fait que var parametres sont exactement le type attendu. Dans les deux cas, il s'agit de la securite des activites comme les details sont privees et nous sont garantis d'etre retourne une classe du type attendu, meme si la classe ancetre n'en a pas connaissance. Nous sommes maintenant en mesure de mettre en œuvre toutes ces relations dans une ligne de code, a l'aide d'un centralisee independante des applications de routine. Les avantages d'un vrai OO developpement commencent a se faire connaître. Ayant construit ces affaires liees a des objets, nous devons nous assurer qu'ils sont detruits. Une approche simple consiste a placer des appels Gratuit dans le destructeur: la protection autour de la Libre volonte de s'assurer que rien de facheux ne se fera si l'objet n'a pas ete effectivement construit (Gratuit sur un nul objet est deductible au titre de l'operation).
Dernier article du probleme
Auparavant, j'ai fait allusion a l'ensemble de classes qui ne doit pas etre utilise dans un 'vrai' OO application. La Figure 1 de l'article du mois dernier montre que les elements de l'interface ne peut pas interagir avec la couche de persistance, seulement le domaine du probleme. Bases de donnees des composants de briser cette regle, l'envoi des modifications directement a la connexion de base de donnees, et donc (controversee) ne doit pas etre utilise. Il y a beaucoup, mieux, des alternatives seront etudiees dans l'avenir colonnes.
((( Listing 1 - Falsifier une classe avec des proprietes a l'appui des relations)))
type
& nbsp & nbsp TOrder = classe (TMyAppPDObject)
& nbsp & nbsp prive
& ! & ! & ! & nbsp FCustomerID: TObjectID
& nbsp & nbsp public
& ! & ! & ! & nbsp propriete CustomerID: TObjectID lire FCustomerID
& ! & ! & ! & nbsp ... // Autres proprietes de suivre...
& nbsp & nbsp fin
((( Fin Listing 1 )))
((( Listing 2 - a l'Aide de la construction paresseuse pour les objets lies)))
type
& nbsp & nbsp TOrder = classe (TMyAppPDObject)
& nbsp & nbsp prive
& ! & ! & ! & nbsp FCustomerID: TObjectID
& ! & ! & ! & nbsp FCustomer: TCustomer
& ! & ! & ! & nbsp fonction GetCustomer: TCustomer
& nbsp & nbsp public
& ! & ! & ! & nbsp propriete de la Clientele: TCustomer lire GetCustomer
& ! & ! & ! & nbsp ... // Autres proprietes de suivre...
& nbsp & nbsp fin
fonction de TOrder.GetCustomer: TCustomer
begin
& nbsp & nbsp si FCustomer = nil alors commencer
& ! & ! & ! & nbsp FCustomer := TCustomer.Creer
& ! & ! & ! & nbsp FCustomer.Charge (FCustomerID)
& nbsp & nbsp fin
& nbsp & nbsp Resultat := FCustomer
fin
((( Fin de Liste 2 )))
((( Listing 3 - Generique paresseux de la construction d'objets lies)))
type
& nbsp & nbsp TPDClass = classe de TPDObject
& nbsp & nbsp TPDObject = classe
& nbsp & nbsp protege
& ! & ! & ! & nbsp fonction GetObject (const ClassType: TPDClass var PDObject: TPDObject const ID: TObjectID): TPDObject
& nbsp & nbsp public
& ! & ! & ! & nbsp constructeur Creer virtuel
& ! & ! & ! & nbsp procedure de Charge (ID: TObjectID)
& nbsp & nbsp fin
fonction de TPDObject.GetObject (const ClassType: TPDClass var PDObject: TPDObject const ID: TObjectID): TPDObject
begin
& nbsp & nbsp si PDObject = nil alors commencer
& ! & ! & ! & nbsp PDObject := ClassType.Creer
& ! & ! & ! & nbsp si l'ID <> NotAssigned puis PDObject.Charge (ID)
& nbsp & nbsp fin
& nbsp & nbsp Resultat := PDObject
fin
& nbsp ((( Fin Listing 3 )))
((( Listing 4 - Notre nouveau TOrder.Client fonction d'acces)))
fonction de TOrder.GetCustomer: TCustomer
begin
& nbsp & nbsp Resultat := TCustomer (GetObject (TCustomer, FCustomer, FCustomerID))
fin
((( Fin de Liste 4 )))
Suivant dans la serie