Você pode realmente construir um processador de texto rápido com GoF Design Patterns?

Question

A Gangue dos Quatro Padrões de design usa um processador de texto como exemplo para pelo menos alguns de seus padrões, particularmente Composite e Flyweight.

Além de usar C ou C++, você poderia realmente usar esses padrões e a sobrecarga orientada a objetos que eles acarretam para escrever um processador de texto completo e de alto desempenho?

Eu sei que o Eclipse é escrito em Java, mas não o uso muito, então não sei se é tão rápido ou tão sofisticado quanto algo como o Visual Studio, que possui um sistema de edição de texto baseado em C++.

---

Usei apenas C++ e Java como exemplos.A questão tem mais a ver com a sobrecarga de ter muitos objetos na memória, como você faria em um aplicativo como um processador de texto ou até mesmo um jogo.

Os padrões de design promovem a abstração em detrimento da parcimônia, embora geralmente apontem quando você poderá sofrer algum tipo de impacto no desempenho.Os processadores de texto e especialmente os jogos obtêm o máximo benefício por estarem o mais próximo possível do metal.

Eu só estava me perguntando se alguém conhecia um processador de texto ou editor de texto orientado a objetos rápido que não fosse escrito em C++, e se eles construiriam um usando padrões ou abririam mão de grande parte da abstração das coisas?

Answer 1

Flyweight é realmente apenas uma forma de conservar recursos em situações onde existem milhares de objetos com estado compartilhado intrínseco, portanto pode ser útil em linguagens de nível superior que C/C++.Talvez o exemplo do GoF usando glifos em um documento não tenha sido a melhor escolha para ilustrar esse padrão.

Eu acho que há muito mais na construção de um processador de texto de alto desempenho do que apenas esses padrões básicos - não tenho certeza se há algo no GoF que exclua a capacidade de fazer isso com sucesso.

Geralmente, o Visual Studio (VS) é mais avançado e tem um desempenho significativamente melhor que o Eclipse - pelo menos as versões do VS que eu vi.Eclipse é um dos aplicativos Java mais impressionantes que existem, mas funciona muito bem em máquinas mais recentes com muita RAM.

Answer 2

Bem, peso mosca é um padrão ridículo para usar em um processador de texto.IIRC, eles tinham cada personagem sendo referenciado como um objeto [nota:era para cada um glifo, o que ainda é uma loucura porque seu sistema operacional terá prazer em desenhar isso para você].Com um ponteiro sendo mais largo que um caractere e todo o processamento associado à indireção, você ficaria louco se usasse esse padrão específico dessa maneira em um processador de texto.

Se você estiver interessado no design de processadores de texto, encontrei um artigo que não aborda padrões, mas analisa alguns dos estruturas de dados subjacentes ao design do processador de texto e às considerações de design.

Tente lembrar que os padrões de design existem para facilitar sua vida, não para você ser puro.Tem que haver uma razão para usar um padrão, ele tem que oferecer algum benefício.

Answer 3

O objetivo do GoF e dos padrões em geral é falar sobre como fazer as coisas "certas" como corretas, não necessariamente "certas" como certas para as circunstâncias.Quando o desempenho é um problema e você descobre que nenhum padrão nomeado oferece desempenho adequado, talvez você possa justificar seguir seu próprio caminho.Mas um bom conhecimento dos padrões fornece um "padrão sensato" e provavelmente significará que você sacrificará a clareza/SoC/etc apenas o necessário para fornecer um desempenho adequado.

Sentir que você está "se desviando" da norma o incentiva a a) pensar duas vezes eb) comentar bem o código não idiomático.

Os padrões são um conhecimento vital, mas nada é evangelho e você deve sempre julgar.

Dito tudo isso - não consigo pensar em nenhuma razão pela qual você não poderia escrever um editor de texto decente usando padrões e um JDK moderno

Answer 4

Uma das coisas que você deve lembrar é que o livro GoF foi escrito no início dos anos 90, quando os sistemas operacionais predominantes não tinham extensas bibliotecas gráficas.Mesmo o Windows ainda não era um sistema operacional naquela época.

IIRC GoF foi lançado em 1994.Mesmo em 1994, o Windows 95 Beta estava disponível (e rodando no meu 486DX33) e o Windows 3.x já existia desde aproximadamente 1990.

Answer 5

Eclipse + netbeans + IntelliJ são todos escritos praticamente em java ou algo que roda na JVM (não em C++).Em pelo menos dois desses IDEs passei algum tempo com o código do editor, então posso garantir que é tudo java (e também não é fácil).

O VS 2005 foi minha última experiência no Visual Studio, e mesmo assim achei que o Eclipse era muito mais responsivo (intelliJ duplamente, dado tempo para aquecimento e indexação).

Não tenho certeza de como isso é relevante, mas essa é a minha experiência.Mas estou surpreso que o visual studio ainda hoje seja escrito em C++ - eu acho que seria do interesse da Microsoft usar C # - pelo menos, ele realmente aumentaria seu desempenho, nada como comer sua própria comida de cachorro!

Answer 6

Sim, as máquinas atuais são rápidas e possuem memória suficiente para que isso seja possível.Se você der uma olhada no Squeak, verá um IDE Smalltalk escrito em Smalltalk, significativamente mais lento que Java, mas ainda rápido o suficiente.A edição de vídeo HD, por outro lado, é algo que atualmente precisa de algum suporte de nível inferior.

Answer 7

Esta questão realmente parece ser sobre Java vs.Desempenho C++, e isso não é tanto a orientação a objetos, mas a execução em uma máquina virtual com coleta de lixo e coisas assim.

Este artigo em Java vs.O desempenho do C++ pode valer a pena ler.