Usine de modèles pour les opérations de menu

Usine de modeles pour les operations de menu

Usine de modeles pour les operations de menu : Plusieurs milliers de conseils pour vous faciliter la vie.

Dans cet article, j'appuie sur le modele de Fabrique en service pour des operations de menu.
Etes-Vous Servi?
Dans cet article, nous allons prendre une courte pause dans les rigueurs de la mise en oeuvre de business objects pour faire face a quelque chose que presque chaque application necessite: un menu. Pas un menu dans le sens d'une TMainMenu derives, mais plutot une sorte de front-end qui montre un certain nombre d'options disponibles, et il faut etre selectionne par l'utilisateur. Un exemple typique serait une liste des options presentees a l'utilisateur lorsqu'une application est lancee: ils sont tenus de choisir de lancer l'application principale, ou peut-etre la serie de rapports, les services d'utilite generale ou l'administrateur de systemes. Ces options sont generalement presentes a l'utilisateur dans assez brut de moyens, peut-etre un petit formulaire avec un nombre de boutons de chaque avec une legende decrivant l'application a executer, ou une zone de liste avec un nombre d'entrees. Le plus souvent, ces menu-type de formes sont codes en dur et intrinsequement 'savoir' comment lancer l'option selectionnee. De telles solutions ont deux proprietes: ils sont rigides et peu attrayant. Ce mois-ci, nous utilisons le modele de Fabrique (et le choix judicieux des composants visuels) pour fournir une meilleure solution.
Allez
Une usine modele doit etre utilise lors de la 'une classe ne peut pas anticiper la classe des objets qu'il doit creer'. Essentiellement un objet client utilise les proprietes et methodes d'un resume ancetre de l'objet, alors qu'en realite, c'est la manipulation de beton descendants qui ont ete fournis par la fabrique de classe. La cle de la conception est que le client n'a pas besoin de connaître les details specifiques sur les objets qu'il manipule, a l'exception de ceux qu'ils partagent dans leur ancetre commun. Cette decouple efficacement ces classes au moment de la compilation. A l'egard de nos menus de l'ecran en Delphi, cela signifie que le menu n'a pas besoin d'utiliser les unites qui contiennent les formulaires a afficher lorsqu'un particulier element de menu est selectionne. Cette elegance nous offre la possibilite de placer ces formes a l'interieur de la DLL, qui sont charges dynamiquement lors de l'utilisation selectionne l'option de menu appropriee. Cela a des avantages evidents de la consommation de memoire (uniquement le menu option activee par l'utilisateur a l'execution consomme de la memoire), et que l'application peut etre etendu par le simple apport d'une nouvelle DLL - menu de l'ecran peut simplement detecter la presence et l'ajouter a la liste presentee a l'utilisateur.
d'Abord, nous allons considerer le cas d'un statiquement lie ensemble des operations de menu qui est, toutes les operations seront compilees au sein de l'application. Notez, cependant, que c'est tout simplement l'ecran du menu lui-meme n'a pas encore de connaissances explicites les operations, ou comment ils sont lies a l'application. Au lieu de cela, chaque operation de menu s'enregistre lui-meme avec l'usine et le menu formulaire interroge l'usine pour les entrees disponibles. Le menu est alors libre de presenter ces entrees comme il l'entend. Lorsque l'utilisateur selectionne une entree de menu, le reglage d'usine est demande de construire un exemple concret de ce type et de ce qui est alors affichee.
L'usine elle-meme a une interface tres simple. Il a une methode appelee Registre qui est utilise par le menu les entrees elles-memes de notifier a l'entreprise de leur existence (j'ai utilise le Registre comme il imite la nomenclature utilisee par d'autres usines au sein de Delphes lui-meme, tels que l'enregistrement des composants pour l'affichage de la palette de composants). En outre, l'usine possede deux proprietes qui permettent a un autre de la classe d'observer le nombre de membres au sein de l'usine, et vous donne acces a chacun. Listing 1 montre une mise en œuvre complete de cette usine.
maintenant, Nous devons ajouter un menu operations de l'usine. C'est tres simple: creer des formes nouvelles, ajoutez le MenuActionFactory unite a la clause uses dans la mise en œuvre de l'article, et ajoutez le code suivant au pied de chaque forme de l'unite:
initialisation
& nbsp & nbsp MenuActions.Registre (TMyNewForm)
Le TMyNewForm de reference doit etre remplace par le nom de classe de la forme particuliere de l'unite en question. Maintenant que notre de classe de l'usine a ete initialise, nous pouvons tourner notre esprit a la façon de l'appliquer.
menus a la carte
Comme precedemment observe, beaucoup de 'evident' façons de demander a l'utilisateur de selectionner un choix de nombreux sont visuellement attrayant. Une liste verticale de l'echelle de boutons (avec de longues legendes), il est particulierement inesthetique mais etonnamment solution commune. Examiner comment Windows resout une interface utilisateur semblable question: le Panneau de Controle est un bon exemple d'une liste d'operations disparates. Ce n'est rien de plus qu'une liste, mais un ensemble bien conçu icones et mise en page coherente va un long chemin a fournir une interface attrayante. Ajoutez a cela la capacite d'une vue de liste pour reorganiser les icones comme il est redimensionne, et pour afficher les icones de differentes tailles ou d'un rapport descriptif de vue, et vous avez a peu pres l'ideal de l'outil de selection.
Pour creer un nouveau menu de l'ecran, deposer une vue de liste sur un formulaire vierge et l'aligner sur l'espace client. Je tiens a deposer un TCoolBar alignee en haut sur le formulaire et ajoutez un peu de plat boutons (a l'aide d'images d'extraction a partir de l'Explorateur) pour permettre a l'utilisateur de changer la ViewStyle de la vue de liste. Pour faire de l'affichage de la liste d'auto-arranger les icones, ajoutez le code suivant a la FormResize de l'evenement:
lvwForms.Organiser (arDefault)
Enfin, nous devons ajouter une liste d'images a la forme et a la relier a l'affichage de la liste LargeImages bien.
Nous avons maintenant besoin d'afficher le menu des options disponibles au sein de l'usine dans la vue de liste. Cela implique de velo grace au regime enregistre d'options de menu et de la creation d'un nouvel element de liste pour chaque. Chaque element de la liste doivent etre affectees d'un indice d'image pour leur icone, et une legende vont etre prises directement a partir de la meme nomme proprietes de la forme nominative. Il est possible d'ajouter des informations supplementaires pour les elements de menu pour l'exemple lors de l'affichage de liste est en vsReport mode, il peut etre une bonne idee d'ajouter une description longue affiche comme une deuxieme colonne, de sorte que les utilisateurs novices peuvent avoir une meilleure comprehension de ce que chaque action. Un bon exemple de ceci peut etre vu dans la Console de Gestion Windows 2000.
La cle de ce processus est que la presentation du menu formulaire lui-meme doit utiliser uniquement les MenuActionFactory de l'unite de lui-meme et aucun specifiques de l'option de menu formes. Ces specialisations sont completement caches a l'interieur de l'usine comme son nom l'indique, il va creer une classe concrete du type correct, sans que le client ne jamais avoir besoin de connaître les details exacts.

Listing 2 presente le code necessaire pour remplir la liste. Notez qu'il parcourt chaque enregistre le menu action, l'usine cree la classe requise. Le menu formulaire, puis cree un nouvel element de liste avec les details pertinents avant de detruire l'objet. Notez que pour que cela fonctionne correctement, les constructeurs sur le regime enregistre d'classes doivent etre virtuel c'est deja vrai pour les composants visuels tels que des formulaires (parce que Delphi utilise une usine a creer eux comme ils sont diffuses dans de .DFM de fichiers et de ressources), mais pour les classes personnalisees, il sera necessaire d'introduire un constructeur virtuel dans leur hierarchie de classe.
si ce formulaire est presente a l'utilisateur et un element est selectionne par un double-clic, puis nous pouvons de nouveau nous demander notre usine pour creer la forme specifique requis, qui peuvent ensuite etre affichees. Il n'y a absolument aucune restriction sur la nature de ces formes peut le faire, mais l'elegance du modele de fabrique, c'est que le client de l'usine peut rester dans l'ignorance du detail. Outre les options de menu peuvent etre ajoutes dans un systeme evolutif simplement en creant une nouvelle forme et de leur enregistrement a l'usine, elles seront immediatement ajoutes dans le systeme de menu la prochaine fois que l'application est executee. Cette absence de couplage entre les elements du systeme facilite grandement la maintenance des applications pour de grands projets, - il suffit de s'inscrire classes avec une usine le developpeur sait qu'une partie de l'application qui a un interet dans ce genre de choses va etre mis a jour.
Il est facile de voir comment ce menu solution est, en soi, generique et peut etre appliquee a un certain nombre d'applications ou meme l'application d'un certain nombre de fois. Dans la plupart de mes applications, j'ai un menu principal qui affiche tous les modules majeurs dans la suite, deux de ces modules de reporting et de services d'utilite generale. Lorsque ces modules sont selectionnes, ils presentent en outre menu des rapports et des utilitaires presents dans le systeme respectivement. Toutes ces formes de partage de code par le biais de visual forme d'heritage, qui ne different que dans l'usine qu'ils utilisent (il y a des usines differentes pour les modules, les rapports et les services publics). La forme visuelle ancetre partagee par tous les trois peuvent etre tout a fait fonctionnelle, l'ajout dynamique de TMenuItem entrees a la demande pour chaque option du menu. Le mot cle ici est la reutilisation du code par le biais de couplage lache - un des principaux avantages de l'orientee objet principes. Par comparaison, l'approche traditionnelle de pres de couplage le menu unique, les formes de leurs actions de menu semble rigide et lourd.
Dernier article du probleme
Dernier article, nous avons discute de la façon dont un delegue de l'objet peut etre fourni a persister objet de gestion de l'information, et la question a ete posee, d'ou pourrait-cette disposition? La reponse evidente a cette question est de creer de la gestion des donnees d'objet dans le constructeur de l'objet de l'entreprise:
constructeur TMyPDObject.Creer
begin
& nbsp & nbsp herite
& nbsp & nbsp // Passer les informations requises pour le constructeur
& nbsp & nbsp DMObject := TMyDMObject.Creer
fin
Le probleme avec cette approche est que chaque objet metier nous a creer la surcharge de la construction d'une gestion des donnees de l'objet. En fonction de votre base de donnees, cela peut etre une operation coûteuse, et donc extremement indesirable, surtout quand il est considere que plusieurs objets vont etre construits et detruits lorsque l'application s'execute. En examinant l'interface de la classe, il peut etre vu que de l'ouvrir et Enregistrer les methodes sont apatrides - tous les travaux sont realises dans le seul appel de methode. Par consequent, a condition que l'application ne necessite pas de multi-thread de la base de donnees de l'activite dans les parties du domaine du probleme, une seule des donnees de gestion de l'objet peut etre partagee entre le nombre d'occurrences de l'entreprise les objets qu'il peut gerer. Mieux encore, cette une gestion des donnees de l'objet peut etre cree au demarrage de l'application temps (ou la premiere fois qu'il est requis). Ces donnees de gestion des objets peuvent etre crees en tant que prive des objets globaux dans la section mise en œuvre du domaine du probleme, ou, plus elegamment, une usine peut etre utilise pour associer des donnees de gestion des classes avec les entreprises des classes d'objets et de creer de façon appropriee.
((( Listing 1 - Une mise en œuvre d'une usine pour les operations de menu )))
unite de MenuActionFactory
interface

& nbsp & nbsp Classes, Les formulaires
type
& nbsp & nbsp TMenuAction = TForm
& nbsp & nbsp TMenuActionClass = classe de TMenuAction
& nbsp & nbsp TMenuActionFactory = classe
& nbsp & nbsp prive
& ! & ! & ! & nbsp MenuActionList: TList
& ! & ! & ! & nbsp fonction GetCount: Integer
& ! & ! & ! & nbsp fonction GetMenuAction (Index: Integer): TMenuAction
& nbsp & nbsp public
& ! & ! & ! & nbsp constructeur Creer
& ! & ! & ! & nbsp destructeur de Detruire remplacer
& ! & ! & ! & nbsp procedure Register (MenuActionClass: TMenuActionClass)
& ! & ! & ! & nbsp propriete Count: Integer lire GetCount
& ! & ! & ! & nbsp propriete MenuAction[Index: Integer]: TMenuAction lire GetMenuAction par defaut
& nbsp & nbsp fin
var
& nbsp & nbsp MenuActions: TMenuActionFactory
application
constructeur TMenuActionFactory.Creer
begin
& nbsp & nbsp herite
& nbsp & nbsp MenuActionList := TList.Creer
fin
destructeur TMenuActionFactory.Detruire
begin
& nbsp & nbsp MenuActionList.Gratuit
& nbsp & nbsp herite
fin
fonction de TMenuActionFactory.GetCount: Integer
begin
& nbsp & nbsp Resultat := MenuActionList.Le comte
fin
fonction de TMenuActionFactory.GetMenuAction (Index: Integer): TMenuAction
begin
& nbsp & nbsp Assert ((Index >= 0) et (Index < Count), 'Index out of range.')
& nbsp & nbsp // Construire et de retourner le bulletin de participation selectionne
& nbsp & nbsp Resultat := TMenuActionClass (MenuActionList[Index]).Create (nil)
fin
procedure TMenuActionFactory.Registre (MenuActionClass: TMenuActionClass)
begin
& nbsp & nbsp MenuActionList.Ajouter (MenuActionClass)
fin
initialisation
& nbsp & nbsp MenuActions := TMenuActionFactory.Creer
finalisation
& nbsp & nbsp MenuActions.Gratuit
a la fin.
((( Fin Listing 1 )))
((( Listing 2 - a l'Aide d'une usine pour remplir une vue de liste)))
procedure PopulateListView (lvwMenu: TlistView Usine: TMenuActionFactory)
var
& nbsp & nbsp Index: Integer
& nbsp & nbsp MenuAction: TForm
begin
& nbsp & nbsp pour Index := 0 a l'Usine.Count - 1 do begin
& ! & ! & ! & nbsp MenuAction := Factory.MenuAction[Index]
& ! & ! & ! & nbsp avec lvwMenu.Elements.Ajouter do begin
& ! & ! & ! & ! & ! & nbsp Caption := MenuAction.Legende
& ! & ! & ! & ! & ! & nbsp ImageIndex := lvwMenu.LargeImages.AddIcon (MenuAction.Icone)
& ! & ! & ! & ! & ! & nbsp Points.Ajouter (MenuAction.L'astuce)
& ! & ! & ! & nbsp fin
& nbsp & nbsp fin
fin
((( Fin de Liste 2 )))
Suivant dans la serie