Classe réutilisable modèles

Classe reutilisable modeles

Classe reutilisable modeles : Plusieurs milliers de conseils pour vous faciliter la vie.

je suis de la conception d'un nouveau morceau de logiciel a l'aide de l'ECO Modeler, que je mettrai en œuvre a l'aide de l'ECO 2.
Comme je l'ai ete a la modelisation de l'entreprise de classes, j'ai ete en accordant une attention particuliere a la creation de classes dans les modeles que je vais etre en mesure de la reutilisation dans des applications differentes.

MODELE 1: informations de Contact
Dans le passe, j'ai dit, et je vais le dire encore une fois! La Composition est plus puissant que l'heritage!
Mes coordonnees modele est un bon exemple de cela. Les differents types de classe necessitent souvent une sorte de coordonnees (numeros de telephone, adresses e-mail, etc). Pour gagner du temps en reproduisant des classes beaucoup de gens vont sauter directement dans et de creer un 'Contact' de la classe qui a ce de diverses informations. Puis ils descendent d'autres classes telles que [la Societe] et [Personne] a partir de cette classe.
je n'aime pas cette approche. L'heritage doit etre utilise lorsque vous voulez que votre mise en œuvre pour traiter les objets d'une maniere courante, et pas pour l'amour de la reduction de la quantite de travail que vous avez a faire lors de la conception de votre modele.
[Reservation] comme un exemple. Vous pouvez enregistrer differentes informations par rapport a une reservation. Evidemment, la reservation aurait une association a une Personne, mais si vous voulais garder l'historique des informations de contact? Les coordonnees de la personne qui peut changer dans le futur, et ensuite l'historique de l'information est perdue. Faites-vous [Reservation] [Contact] trop?
si vous souhaitez enregistrer [Stock] les emplacements? Voulez-vous descendre [Van], [Chambre], [Batiment], [VendingMachine] a partir d'une meme classe? Que faire si une [Personne] ne peut detenir des actions ainsi que la mise en attente des informations de contact? L'heritage peut etre un vrai bordel!

au Lieu de cela, je voudrais creer un ensemble de classes comme illustre ci-dessus. [ContactInformationHolder] est responsable de la tenue des informations de contact.
Quand je veux une classe specifique pour avoir une collection de [ContactInformation] il suffit de creer une association a partir de la classe (par exemple, 'Personne') [ContactInformationHolder]. En utilisant cette approche, je suis en mesure de faire [la Personne], un titulaire de [Stock] ET capable egalement de la tenue de nombreux morceaux de [ContactInformation].

MODELE 2: Les informations de Contact - Pays

j'ai essaye de penser une reutilisables pour modeliser un [PostalAddress]. Logiquement, vous devriez etre en mesure de determiner [Pays] et [PostalAddress] appartient, donc, mon premier instinct a ete de modeliser une association de [PostalAddress] directement a [Pays].
l'Un de mes clients ne veulent pas seulement savoir dans quel pays une personne qui a vecu dans, ils en voulaient a les categoriser par un certain type de region geographique. L'ajout d'un [Region] association pour le / la [Pays] et [PostalAddress] semblait mal pour moi. Il serait possible de preciser royaume-UNI comme pays, les etats-unis et un etat de la region, j'aurais d'inclure les contraintes a verifier cela. Tout semblait un peu brouillon.
Donc, je suis venu avec cette
Maintenant, au lieu d'etre associe directement a un [Pays], [PostalAddress] est en fait associe a une [GeographicLocation]. Cela signifie que [PostalAddress] peut soit appartenir directement a un [Pays] pour les clients qui ne veulent pas les regions, ou un [GeographicArea] pour ceux qui ne.
Dans le modele ci-dessus, il est possible de creer un pays qui a de nombreuses regions, et chacune de ces regions peut egalement avoir des sous-regions. Si un client voulait qu'ils pourraient categorisation a un niveau aussi eleve que les Pays / Etat / Ville / Ville.
Le 'Chemin' est derive de l'association ne fait que retourner une collection de [GeographicLocation], de sorte qu'il est possible d'afficher l'ensemble de la zone comme une chaîne de caracteres. Ainsi, au lieu de 'Acocks Green' (ou je vis), vous pourriez determiner la zone 'royaume-Uni / Angleterre / West Midlands / Birmingham / Acocks Green'.
Afin que je puisse facilement determiner le [Pays] [GeographicLocation] appartient, j'ai ajoute un autre derive de l'association. Dans la classe de base il est derive comme le 'Pays.emptyList'. Dans le [Pays] de la classe il est derive en tant que 'soi', et dans le 'GeographicArea' classe il est derive en tant que 'soi.parentArea.pays'.

MODELE 3: Adresse
Enfin, j'ai ete en mesure de creer une [Adresse] de la classe a ma satisfaction. Je n'aurais pas besoin d'un ancetre commun pour mes cours pour avoir l'information de contact, et mes clients peuvent se referer directement a un pays, ou a n'importe quel niveau de la repartition geographique ils le souhaitent.

Mon [Adresse] classe a simplement un code postal attribut, un ou plusieurs [AddressLine] les objets, et une association a une GeographicLocation.

CONCLUSION

1. Esperons que ces motifs sont generiques, mais suffisamment souple pour une utilisation dans n'importe quelle application.