¿Realmente puedes construir un procesador de textos rápido con GoF Design Patterns?

Question

La banda de los cuatro Patrones de diseño utiliza un procesador de textos como ejemplo para al menos algunos de sus patrones, particularmente Composite y Flyweight.

Aparte de usar C o C++, ¿podrías realmente usar esos patrones y la sobrecarga orientada a objetos que implican para escribir un procesador de textos de alto rendimiento y con todas las funciones?

Sé que Eclipse está escrito en Java, pero no lo he usado mucho, así que no sé si es tan rápido o tan pulido como algo como Visual Studio, que tiene un sistema de edición de texto basado en C++.

---

Sólo utilicé C++ y Java como ejemplos.La pregunta tiene más que ver con la sobrecarga de tener muchos objetos en memoria como lo haría en una aplicación como un procesador de textos o incluso un juego.

Los patrones de diseño promueven la abstracción a expensas de la parsimonia, aunque normalmente señalan cuándo podría verse afectado algún tipo de rendimiento.Los procesadores de texto y especialmente los juegos obtienen el mayor beneficio al estar lo más cerca posible del metal.

Me preguntaba si alguien conocía un procesador de texto o editor de texto rápido orientado a objetos que no estuviera escrito en C++, y si construirían uno usando patrones o renunciarían a gran parte de la abstracción de las cosas.

Answer 1

Flyweight realmente es solo una forma de conservar recursos en situaciones donde hay miles de objetos con estado compartido intrínseco, por lo que podría ser útil en lenguajes de nivel superior a C/C++.Quizás el ejemplo del GoF usando glifos en un documento no fue la mejor opción para ilustrar este patrón.

Sin embargo, creo que construir un procesador de textos de alto rendimiento implica mucho más que solo estos patrones básicos; no estoy seguro de si hay algo en GoF que descarte poder hacer esto con éxito.

Generalmente, Visual Studio (VS) es más avanzado y funciona significativamente mejor que Eclipse, al menos las versiones de VS que he visto.Eclipse es una de las aplicaciones Java más impresionantes que existen; funciona bastante bien en máquinas más recientes con mucha RAM.

Answer 2

Bien, peso mosca Es un patrón ridículo para usar en un procesador de textos.IIRC, hacían referencia a cada personaje como un objeto [nota:era para cada uno glifo, lo cual sigue siendo una locura porque su sistema operativo lo dibujará felizmente por usted].Dado que un puntero es más ancho que un carácter y todo el procesamiento asociado con la dirección indirecta, sería una locura usar ese patrón particular de esa manera en un procesador de textos.

Si está interesado en el diseño de procesadores de texto, encontré un artículo que no aborda los patrones pero sí analiza algunos de los Estructuras de datos subyacentes al diseño del procesador de textos y consideraciones de diseño..

Trate de recordar que los patrones de diseño están ahí para hacerle la vida más fácil, no para que usted sea puro.Tiene que haber una razón para utilizar un patrón, tiene que ofrecer algún beneficio.

Answer 3

El objetivo de GoF y los patrones en general es hablar de cómo hacer las cosas "bien" como correctas, no necesariamente "correctas" como correctas para las circunstancias.Cuando el rendimiento es un problema y descubre que ningún patrón con nombre proporciona un rendimiento adecuado, entonces tal vez pueda justificar seguir su propio camino.Pero un buen conocimiento de los patrones le proporciona un "valor predeterminado sensato" y probablemente signifique que sacrifique la claridad/SoC/etc. sólo en la medida necesaria para ofrecer un rendimiento adecuado.

Sentir que te estás "desviando" de la norma te anima a a) pensarlo dos veces yb) comentar bien el código no idiomático.

Los patrones son conocimientos vitales, pero nada es evangelio y siempre debes aplicar el criterio.

Habiendo dicho todo eso, no se me ocurre ninguna razón por la que no puedas escribir un editor de texto decente usando patrones y un JDK moderno.

Answer 4

Una de las cosas que debes recordar es que el libro de GoF se escribió a principios de los 90, cuando los sistemas operativos predominantes no tenían bibliotecas gráficas extensas.En aquella época ni siquiera Windows era todavía un sistema operativo.

IIRC GoF fue lanzado en 1994.Incluso en 1994, Windows 95 Beta estaba disponible (y ejecutándose en mi 486DX33) y Windows 3.x existía aproximadamente desde 1990.

Answer 5

Eclipse + netbeans + IntelliJ están escritos prácticamente todos en java o algo que se ejecuta en la JVM (no en C++).En al menos 2 de esos IDE he pasado algún tiempo con el código del editor, así que puedo asegurarles que es todo java (y tampoco es fácil).

VS 2005 fue mi última experiencia con Visual Studio, e incluso entonces pensé que eclipse respondía mucho más (intelliJ tenía el doble de tiempo para calentarse e indexarse).

No estoy seguro de cómo eso es relevante, pero esa es mi experiencia.Pero me sorprende que Visual Studio todavía esté escrito en C++. Creo que sería de interés para Microsoft usar C#. Al menos, realmente mejoraría su rendimiento, ¡nada como comer tu propia comida para perros!

Answer 6

Sí, las máquinas actuales son lo suficientemente rápidas y tienen suficiente memoria para que eso sea posible.Si echas un vistazo a Squeak, verás un IDE de Smalltalk escrito en Smalltalk, significativamente más lento que Java, pero aún lo suficientemente rápido.La edición de vídeo HD, por otro lado, es algo que actualmente necesita soporte de nivel inferior.

Answer 7

Esta pregunta en realidad parece ser sobre Java vs.Rendimiento de C++, y eso no es tanto la orientación a objetos como la ejecución en una máquina virtual con recolección de basura y demás.

Este documento técnico en Java vs.Puede que valga la pena leer el rendimiento de C++.