2010-08-24 12 views
11

Hace muchos años, cuando no sabía mucho sobre diseño orientado a objetos, escuché a un chico decir algo como "¿Cómo se puede escribir un editor de texto sin polimorfismo?" No sabía mucho sobre OOP y por eso no pude juzgar qué tan sabio fue o hacer preguntas específicas en ese momento.¿Qué tan esencial es el polimorfismo para escribir un editor de texto?

Ahora, después de muchos años de desarrollo de software (principalmente C++), he usado el polimorfismo muchas veces para resolver diversos problemas al diseñar software. Sin embargo, nunca he creado editores de texto. Así que todavía no puedo evaluar la idea de ese tipo.

¿Es el uso del polimorfismo tan esencial para implementar un editor de texto en lenguajes orientados a objetos y por qué?

+2

+1 para esa humildad – Chubsdad

+0

La pregunta parece indicar que el polimorfismo y la POO están inevitablemente vinculados, lo que por supuesto no es así. Muchos lenguajes de programación usan polimorfismo, sin ser OO (por vago que sea ese término). – Svend

+0

@chubsdad +1 por humildad! :) –

Respuesta

2

El otro punto acerca de que el polimorfismo es solo una herramienta es acertado.

Sin embargo, si "el chico" tenía alguna experiencia con la redacción de editores de texto, bien podría haber estado hablando sobre el uso de polimorfismo en la implementación de una jerarquía de composición de documentos.

Básicamente, este es solo un árbol de objetos que representa la estructura de su documento, incluyendo detalles como el formateo (negrita, cursiva, etc.) para colorear, etc.

(La mayoría de los navegadores web implementar algo similar en la forma del modelo de navegador de objetos de documento (DOM), aunque ciertamente no hay requisito de que utilizan polimorfismo.)

Cada uno de estos objetos hereda de una clase base común (a menudo abstracto) que define un método como Compose().

Luego, cuando es el momento de mostrar o actualizar la estructura del documento, el código simplemente atraviesa el árbol que llama al concreto Compose() en cada objeto. Cada objeto es responsable de componer y representarse en el lugar apropiado del documento.

Este es un uso clásico del polimorfismo porque permite agregar o cambiar los nuevos "componentes" del documento sin ningún cambio (o mínimo) en el código de la aplicación principal.

Una vez más, hay muchas maneras de construir un programa de manipulación de texto, el polimorfismo definitivamente no es requerido para construir uno.

+0

(No tan) recuerdos gratos de [Interleaf] (http://en.wikipedia.org/wiki/Interleaf) –

3

Muchos de los patrones de diseño como Memento, peso mosca, etc., que pueden pueden utilizar para diseñar/implementar Editor de texto requieren la herencia y polimorfismo.

+0

Creo que esa fue la aplicación de ejemplo en el libro de patrones de diseño de la pandilla de cuatro. – Steve314

+0

+1; @Steve ¡sí! "El Capítulo 2 es un estudio de caso paso a paso sobre" el diseño de un editor de documentos 'Lo que ves' Lo que recibes '(o' WYSIWYG ') llamado Lexi. " –

+0

y esos patrones de diseño fueron creados * para que * podamos hacer editores de texto usando OOP. En todo caso, su existencia muestra que OOP * no * es adecuado para OOP (ya que si lo fuera, no necesitaríamos un libro de patrones de diseño para llevarlo a cabo)););) – jalf

12

El polimorfismo para escribir un editor de texto no es esencial. De hecho, el polimorfismo para resolver cualquier problema de programación no es esencial. Es solo una forma de hacerlo. A veces, facilita la resolución de ciertos tipos de problemas y, a veces, se interpone en el camino.

La evidencia de esto es que hay editores de texto perfectamente utilizables desarrollados mucho antes de que "OOP" se hiciera popular.

+3

Al igual que las máquinas de escribir mecánicas :) – Schedler

+2

El hecho de que emacs se implementó en un dialecto Lisp podría considerarse evidencia de que NO DEBERÍA usar un lenguaje que admita polimorfismo para crear editores de texto :) – mjfgates

+0

@mjfgates: ¿Desde cuándo Lisp no es polimórfico? ? Los lenguajes funcionales también usan polimorfismo. Simplemente no lo implementan a través de la herencia y las funciones virtuales. – jalf

9

Yo diría "no", porque es muy posible escribir perfectamente buenos editores de texto en lenguajes no orientados a objetos, por lo que no puede ser tan esencial.

El polimorfismo es una gran técnica para los problemas que aborda, pero de ninguna manera es el martillo dorado para todo lo que aflige a un desarrollador de software.

+2

C tiene un polimorfismo en forma de indicadores de función – doron

+0

+1. En 30 años, aprendí que la mayoría de las personas que dicen "no se puede implementar x sin y" son los que se aferraron a algo y se mueren por aplicarlo a cada problema que encuentran, apropiado o no. – Blrfl

+1

@deus: he visto personas escribir editores de texto en FORTRAN, sin punteros, sin polimorfismo. No es esencial. – duffymo

5

Este es un término que se utilizaba mucho cuando la programación de OO era la furia. Este tipo probablemente intentaba intimidarte con palabras grandes, dudo que entendiera completamente lo que decía, aunque es un concepto simple cuando se lo explica.

Cualquiera aquí radica en el quid del argumento - cuántas veces tendrías que escribir, mantener o extender un editor de texto - ninguno - por lo tanto, un paradigma de OO es de poca utilidad en un para qué es una pieza relativamente simple de código que necesita ser altamente eficiente.

+1

+1 por "tratar de intimidarte" - parece ser el tipo de tonterías que a la gente le encanta sonar inteligente. – duffymo

+1

¿Está sugiriendo que cada editor de texto se acaba de escribir una vez, quizá de la noche a la mañana, y luego nunca requirió nuevas características o mantenimiento? Pista - Estoy usando v5.7 de Notepad ++. Como ya se ha señalado aquí, mucho depende de qué tan sofisticado quieras que sea tu editor de texto. – Steve314

+0

@ Steve314: la sofisticación se puede lograr con otros paradigmas que OO. – jalf

1

¿Está utilizando un polimorfismo tan esencial para implementar un editor de texto en lenguajes orientados a objetos y por qué?

Depende del tipo de editor de texto del que se trate.

Puede escribir bloc de notas sin OOP. Pero lo más probable es que necesite OOP para algo como MS Word u OpenOffice.

Design Patterns: Elements of Reusable Object-Oriented Software usa el editor de texto para ejemplos (es decir, "caso de estudio") de la aplicación Design Pattern. Es posible que desee consultar el libro.

+1

entonces, ¿cuál sería exactamente el problema si traté de escribir algo como MS Word en un lenguaje que no sea de OOP? – jalf

+0

+1 principalmente porque no veo por qué esto se revocó y no hubo ningún comentario para explicar. – Steve314

+0

@jalf - Supongo que la "necesidad" no está destinada a tomarse literalmente. – Steve314

2

Una vez escribí un editor de texto en Basic. No fue un sofisticado editor de texto de ninguna manera, lo más destacado fue una ventana en modo texto utilizada para algunos menús y cuadros de diálogo, pero aún así era su trabajo en ese momento, es decir, demostró que podía escribir un editor de texto en Básico. Incluso lo usé a veces. No mostraré la fuente en público, ¡es demasiado embarazoso!

Cuando su editor de texto consiste principalmente en insertar/eliminar caracteres en una gran variedad de cadenas y visualizarlos, se necesita poca o ninguna abstracción aparte de las abstracciones habituales proporcionadas como estándar de matrices y cadenas.

Por otro lado, la cantidad de texto que un editor de texto en una PC debe soportar ha aumentado mucho en los últimos 20 años, a veces en la medida en que incluso una PC moderna con múltiples gigabytes puede no ser capaz de mantener todo el archivo en RAM Además de eso, hay problemas de conjunto de caracteres y codificación. Se espera que un buen editor de texto recuerde un número (potencialmente grande) de marcadores en múltiples archivos, y que los mantenga para que se refieran al mismo punto a pesar de las ediciones. Y luego está el resaltado de sintaxis, la capacidad de grabar/reproducir macros, y más.

En resumen, los editores de texto modernos son mucho más complejos que los que se usan en DOS y en otros micros hace veinte años. Esa complejidad es sin duda mucho más fácil de manejar con un buen conjunto de herramientas para manejar abstracciones.

2

Si bien un editor de texto simple (debajo de edit.com desde MS-DOS) se puede realizar más fácilmente en una clase estática solamente (porque la funcionalidad es muy limitada), tan pronto como llegue a menús y cuadros de diálogo, encontrará usted mismo en extrema necesidad de características de lenguaje orientado a objetos.

Personalmente, frunzo el ceño sobre el código de procedimiento de todos modos, prefiero una mezcla de OOP (estructura de programa, separación de funcionalidad, etc.) y programación funcional (implementación).

Esto puede sonar como un argumento religioso de algún tipo, pero considero que mi estilo personal es bastante recomendable. Por lo general, necesito muchas menos líneas de código (que son mucho más fáciles de entender) que la mayoría de los desarrolladores con los que trabajo y mi código se siente mucho más "ágil" y "flexible".

Pruébalo.:-)

Ah, y la polimorfa no es difícil de entender. Simplemente imagine que usted (como persona) puede ser manejado como:

a) El hombre o la mujer b) de Europa, Asia, América, África, Oceanía (espero que esto es correcto), etc ... c) Por su nombre d) Por su ocupación

Pero aún así usted es una persona, y un ser vivo, y una parte del universo ... y USTED.

Así que para alguien que le pregunte por razones estadísticas algunas preguntas, puede ser tratado como, por ejemplo, mujer de oceanía (no sé de dónde viene, pero supongamos) que es, hm, 42 años y vivió en, hm, Suiza durante 23 años (jajaja).

Para su empleador, puede ser competente en programar y hablar con sus colegas.

Sin embargo, CÓMO llenar esos roles depende de su implementación. Este Eres tu.

+0

En la forma común de OOP donde los métodos son miembros de su clase, los métodos son básicamente solo funciones, pero con una parámetro (this/self/whatever) tratado como especial. Funciona bien para el polimorfismo de envío único, pero para el despacho múltiple no hay una razón particular para designar un parámetro como uno especial. Un enfoque muy lógico para el despacho múltiple es que todavía tiene clases y herencia, pero las funciones no son miembros, por lo que el código parece muy procesal. Es OOP, pero no como lo conocemos. El patrón de visitante es más difícil de lo que debe ser sin despacho múltiple. – Steve314

+0

Lo único que realmente no he visto en un lenguaje de propósito general. Lo he usado en un AST-handling DSL (treecc) y he escrito mi propia DSL con un modelo heredado más sofisticado (pero aún no lanzado), pero eso es todo. Creo que CLOS puede seguir un modelo similar, pero no estoy seguro. – Steve314

+0

Ceñir el código de procedimiento (y obligar a que todo sea un objeto) es una de las mayores barreras para escribir código sensible que encuentro todos los días. ¿Qué pasa con el código de procedimiento cuando tienes una secuencia de pasos a seguir? (Me parece que muchas personas escriben el código de procedimiento dentro de las clases, de todos modos, y piensan que su secuencia de pasos de alguna manera ahora es mágicamente OO). –

Cuestiones relacionadas