Quels modèles de conception implémentez-vous dans Programmation de Delphi commun ? Quels motifs sont Je serais heureux, si vous pouviez parler de quelques modifications dans les modèles de conception Il existe de nombreux articles dans l'Internet sauvage, mais ils ne discutent pas de la convivialité quotidienne et des changements de schémas. (La plupart d'entre eux discutent simplement de changements dans des spécificités de langue, de l'architecture).
6 Réponses :
Seule une minorité des développeurs Delphi sait que chaque développeur Delphi utilise un modèle usine ( delphi.about.com a un exemple dans "régulier" Delphi ) , puis mis en œuvre à l'aide virtuelle Créer des constructeurs
: le temps de faire la lumière sur ce point: -.). p>
constructeurs virtuels à des classes comme des méthodes virtuelles sont comme des instances d'objet p>
l'idée du modèle d'usine est que vous découpler la logique qui détermine quel genre (dans ce cas, « classe ») de chose (dans ce cas, « instance d'objet ») pour créer de la création réelle. p>
Il fonctionne comme ceci en utilisant Créer des constructeurs virtuels: p>
dommage que je puisse éteindre une seule fois, excellent post, merci
@Tom merci pour la modification; Être un peu wordblind, ces choses sont exactement ce que je néglige toujours.
Excellent exemple. Une chose à noter. Modèles d'usine Les implémentations dans d'autres langues utilisent des fonctions statiques ordinaires (ou Classe Fonctions pour Pascalites). En tant que tels, ils sont capables de renvoyer NULL ( nil ). Un constructeur Delphi, comme les constructeurs sans nom dans d'autres langues, retournera toujours une référence d'objet, sauf si vous soulevez une exception. Bien sûr, vous êtes libre d'utiliser une fonction de classe aussi facilement si le besoin se pose.
J'utilise fréquemment les modèles suivants:
Il y a une réponse sur des singletons et dit qu'il s'agit d'un pur mal. Variables mondiales déguisées :)
Les deux ne sont que du mal si vous les abusez. Les singletons peuvent être très utiles dans certaines situations.
J'utilise fréquemment des modèles suivants:
Vous pouvez trouver Un excellent article de Marco Cantu sur l'équivalence des modèles GOF et Delphi expressions idiomatiques. Je me souviens d'assister à sa session de Borcon sur le sujet, c'était excellent.
Une idée principale à retenir est que des modèles de conception sont nécessaires pour compléter les lacunes de la langue / du cadre. Et si vous avez un idiome natif, vous n'avez pas besoin de réinventer la roue et de mettre en œuvre tout le gof Shebang, apprenez simplement à le reconnaître et à le nommer (comme Jeroen l'a fait avec son Superbe explication sur l'usine ).
Programmation non-OOP (certains appeler la programmation structurée) est très fréquente avec les programmeurs Delphes. C'est très simple: vous créez une fonction qui fait quelque chose, et ce n'est pas lié à une structure de données d'enregistrement / de type objet. Exemple: inttostr ()
Delphi le fait très bien, car l'encapsulation est livrée à l'aide de sections d'interface / de mise en œuvre et, car le code de la machine résultant est extrêmement efficace. Lors de la compilation, il prend également en charge les optimisations pour cela, par exemple, si vous avez une constante dactylographiée dans votre section d'interface, et le programme est complètement compilé - si vous modifiez ensuite la valeur de cette constante, l'appareil n'est pas recompilé, seule la constante changements. Ce n'est pas vraiment nécessaire dans un travail quotidien, mais c'est un exemple de la façon dont Delphi fonctionne.
Qu'est-ce que cette réponse a à voir avec l'un des sujets mentionnés dans la question?
Non-OOP n'est pas nécessairement "programmation structurée". Il existe également une programmation fonctionnelle, par exemple, un sujet très intéressant pour les programmeurs de Delphes cherchant à apprendre quelque chose "Alien". Découvrez Delphifeeds.com/go/s/44177 pour une introduction à Delphi Devs .
-1 Pas du tout sur les modèles de conception
+1: "Non-OOP" est un modèle de conception très important. C'est sur un baiser. Même si le baiser n'est pas mentionné comme tel dans le livre Gof, le modèle Kiss est l'un des modèles les plus importants disponibles: cela vous aide à ne pas "sur-ingénieur" ce que vous produisez. Peut-être que ce n'est pas mentionné dans le livre Gof car il s'applique à tellement plus que des logiciels.
@Jeen: Kiss n'est pas dans le livre Gof car il n'est tout simplement pas un modèle reconnaissable en tant que tel. C'est une bonne idée, oui, mais un motif est quelque chose comme une poignée pour une solution commune et éprouvée à une classe de problèmes. Les modèles sont destinés à aider les gens à résoudre des problèmes et à communiquer à ce sujet, je viens de jeter "Kiss" ne le fait ni.
@ GGHIE: Le baiser est beaucoup plus un motif méta que comme un modèle de béton (le livre Gof est plus d'une référence «Contrete Motif»). Je suis d'accord avec vous qu'il est très important de pratiquer.
Il est possible de refroidir une procédure avec de nombreux paramètres dans une classe et inversement. C'est certainement un motif évident qui peut être décrit et bien défini, mais je ne me soucie pas de ce qu'on appelle - je n'ai pas le livre Gof à proximité et au sérieux, il n'a pas de monopole sur la nommée.
Lars, tout comme «une programmation non orientée vers l'objet» et «la garder simple» ne sont pas des motifs, ni refactoring. Et vous devriez vraiment vous souciez de savoir ce que quelque chose est appelé - tout le point de motifs est qu'ils nous donnent un vocabulaire commun à utiliser lors de la réflexion et de la discussion de problèmes. Utilisation d'un nom Différent de ce que le livre de modèles le plus populaire au monde utilise n'aime que personne. Vous avez fait plusieurs véritables déclarations - c'est est possible de refacturer une procédure comme votre décrire et non-oop est très courant - mais comment sont-ils pertinents à la question à la main?
Un «code> ordinaire se comporte comme un singleton. Vous ne pouvez pas utiliser les techniques de OOP comme héritage et polymorfisme, mais cela pourrait être une bonne chose :)
Je pense généralement que Delphi le rend trop facile à éviter la conception du SONO OOP. C'est bien pour RAD, mais vous devez savoir quels pièts à éviter si vous voulez un code flixable et maintenu. Par exemple, la visibilité publique des composants que vous ajoutez aux formulaires, la variable globale de type Tform1 (au lieu de la durée de vie gérée manuellement et une classe de base en tant que type) et le manque de séparation entre interface graphique et logique professionnelle. Juste pour mentionner des problèmes.
Peut-être que cela devrait être une question de wiki communautaire
Puis-je demander pourquoi? Je pose une question spécifique, traitant des modèles de conception pour Delphes et qu'ils ont changé depuis des changements dans la langue de Delphi (2009, 2010).
Eh bien, non, Juraj, vous ne posez pas une question spécifique. Je compte au moins trois questions , et ils sont tous plutôt ouverts. Je ne sais pas si cela est le motif de faire quelque chose de wiki communautaire, cependant.
Déplacé à CW, je voulais juste savoir, s'il y a quelqu'un qui connaît des modifications de modèle dans Delphi 2009/2010