Pouvez-vous vraiment créer un traitement de texte rapide avec les modèles de conception GoF ?

Question

La bande des quatre Modèles de conception utilise un traitement de texte comme exemple pour au moins quelques-uns de leurs modèles, en particulier Composite et Flyweight.

Autrement qu’en utilisant C ou C++, pourriez-vous vraiment utiliser ces modèles et la surcharge orientée objet qu’ils impliquent pour écrire un traitement de texte complet et performant ?

Je sais qu'Eclipse est écrit en Java mais je ne l'ai pas beaucoup utilisé, donc je ne sais pas si c'est aussi rapide ou aussi raffiné que quelque chose comme Visual Studio, qui dispose d'un système d'édition de texte basé sur C++.

---

Je n'ai utilisé que C++ et Java comme exemples.La question a davantage à voir avec la surcharge liée à la présence d'un grand nombre d'objets en mémoire, comme vous le feriez dans une application telle qu'un traitement de texte ou même un jeu.

Les modèles de conception favorisent l'abstraction au détriment de la parcimonie, même s'ils indiquent généralement quand vous pourriez subir une sorte de baisse de performances.Les traitements de texte et en particulier les jeux tirent le meilleur parti d'être aussi proches que possible du métal.

Je me demandais simplement si quelqu'un connaissait un traitement de texte ou un éditeur de texte rapide orienté objet qui n'était pas écrit en C++, et s'il en construirait un en utilisant des modèles ou s'il renoncerait à une grande partie de l'abstraction des choses ?

Answer 1

Flyweight n'est en réalité qu'un moyen de conserver les ressources dans des situations où il existe des milliers d'objets avec un état intrinsèque partagé, il pourrait donc être utile dans des langages de niveau supérieur à C/C++.Peut-être que l'exemple du GoF utilisant des glyphes dans un document n'était pas le meilleur choix pour illustrer ce modèle.

Je pense qu'il y a bien plus à construire un traitement de texte hautes performances que ces modèles de base - je ne sais pas s'il y a quelque chose dans GoF qui exclut la possibilité de le faire avec succès.

Généralement, Visual Studio (VS) est plus avancé et fonctionne nettement mieux qu'Eclipse - du moins les versions de VS que j'ai vues.Eclipse est l'une des applications Java les plus impressionnantes du marché, mais elle fonctionne plutôt bien sur les machines plus récentes avec beaucoup de RAM.

Answer 2

Bien, poids mouche est un modèle ridicule à utiliser dans un traitement de texte.IIRC, chaque personnage était référencé comme un objet [note :c'était pour chacun glyphe, ce qui est quand même fou car votre système d'exploitation se fera un plaisir de le dessiner pour vous].Avec un pointeur plus large qu'un caractère et tout le traitement associé à l'indirection, vous seriez fou d'utiliser ce modèle particulier de cette façon dans un traitement de texte.

Si vous êtes intéressé par la conception de traitements de texte, j'ai trouvé un article qui ne traite pas des modèles mais examine certains des structures de données sous-jacentes à la conception d'un traitement de texte et considérations de conception.

Essayez de vous rappeler que les modèles de conception sont là pour vous faciliter la vie, pas pour que vous soyez pur.Il doit y avoir une raison pour utiliser un modèle, il doit offrir un certain avantage.

Answer 3

Le but du GoF et des modèles en général est de parler de la façon de faire les choses « bien » comme étant correctes, pas nécessairement « bien » comme étant juste selon les circonstances.Lorsque les performances constituent un problème et que vous constatez qu'aucun modèle nommé ne donne des performances adéquates, vous pouvez peut-être justifier de suivre votre propre voie.Mais une bonne connaissance des modèles vous donne un « défaut raisonnable » et signifiera probablement que vous ne sacrifierez la clarté / SoC / etc que dans la mesure nécessaire pour donner des performances adéquates.

Le sentiment que vous « vous écartez » de la norme vous encourage à a) réfléchir à deux fois, et b) bien commenter le code non idiomatique.

Les modèles sont une connaissance vitale, mais rien n’est un évangile et vous devez toujours faire preuve de jugement.

Cela dit, je ne vois aucune raison pour laquelle vous ne pourriez pas écrire un éditeur de texte décent en utilisant des modèles et un JDK moderne.

Answer 4

L'une des choses dont vous devez vous rappeler est que le livre du GoF a été écrit au début des années 90, lorsque les systèmes d'exploitation les plus répandus ne disposaient pas de bibliothèques graphiques étendues.Même Windows n’était pas encore un système d’exploitation à cette époque.

IIRC GoF a été publié en 1994.Même en 1994, Windows 95 bêta était disponible (et fonctionnait sur mon 486DX33) et Windows 3.x existait depuis environ 1990.

Answer 5

Eclipse + netbeans + IntelliJ sont tous écrits à peu près tous en Java ou quelque chose qui s'exécute sur la JVM (pas en C++).Dans au moins 2 de ces IDE, j'ai passé du temps avec le code de l'éditeur, je peux donc vous assurer que c'est entièrement Java (et ce n'est pas facile non plus).

VS 2005 a été ma dernière expérience de Visual Studio, et même alors, je pensais qu'Eclipse était beaucoup plus réactif (intelliJ doublement, donc il avait le temps de s'échauffer et d'indexer).

Je ne sais pas en quoi c'est pertinent, mais c'est mon expérience.Mais je suis surpris que Visual Studio soit encore aujourd'hui écrit en C++ - je pense qu'il serait dans l'intérêt de Microsoft d'utiliser C# - à tout le moins, cela augmenterait vraiment ses performances, rien de tel que de manger sa propre nourriture pour chien !

Answer 6

Oui, les machines actuelles sont suffisamment rapides et disposent de suffisamment de mémoire pour que cela soit possible.Si vous jetez un œil à Squeak, vous voyez un IDE Smalltalk écrit en Smalltalk, nettement plus lent que Java, mais toujours assez rapide.En revanche, le montage vidéo HD nécessite actuellement un support de niveau inférieur.

Answer 7

Cette question semble en fait concerner Java vs.Performances C++, et ce n'est pas tant l'orientation objet que l'exécution sur une machine virtuelle avec garbage collection et autres.

Ce livre blanc sur Java contre.Les performances C++ méritent peut-être d'être lues.