Puoi davvero creare un elaboratore di testi veloce con GoF Design Patterns?

Question

La banda dei quattro Modelli di progettazione utilizza un elaboratore di testi come esempio per almeno alcuni dei loro modelli, in particolare Composite e Flyweight.

Oltre a utilizzare C o C++, potresti davvero utilizzare questi modelli e il sovraccarico orientato agli oggetti che comportano per scrivere un elaboratore di testi completo e ad alte prestazioni?

So che Eclipse è scritto in Java ma non l'ho usato molto, quindi non so se è così veloce o raffinato come qualcosa come Visual Studio, che ha un sistema di editing di testo basato su C++.

---

Ho usato solo C++ e Java come esempi.La domanda ha più a che fare con il sovraccarico derivante dalla presenza di molti oggetti in memoria come faresti in un'applicazione come un elaboratore di testi o anche un gioco.

I modelli di progettazione promuovono l'astrazione a scapito della parsimonia, anche se di solito sottolineano quando potresti subire un qualche tipo di calo delle prestazioni.Gli elaboratori di testi e soprattutto i giochi traggono il massimo vantaggio dall'essere il più vicino possibile al metallo.

Mi stavo solo chiedendo se qualcuno conoscesse un veloce elaboratore di testi o un editor di testo orientato agli oggetti che non fosse scritto in C++, e se ne avrebbero costruito uno utilizzando modelli o avrebbero rinunciato a gran parte dell'astrazione delle cose?

Answer 1

Flyweight è in realtà solo un modo per conservare le risorse in situazioni in cui sono presenti migliaia di oggetti con stato condiviso intrinseco, quindi potrebbe essere utile in linguaggi di livello superiore rispetto a C/C++.Forse l'esempio di GoF che utilizza glifi in un documento non è stata la scelta migliore per illustrare questo modello.

Penso che ci sia molto di più nella costruzione di un elaboratore di testi ad alte prestazioni oltre a questi semplici modelli di base, non sono sicuro che ci sia qualcosa in GoF che esclude la possibilità di farlo con successo.

In generale, Visual Studio (VS) è più avanzato e funziona significativamente meglio di Eclipse, almeno delle versioni di VS che ho visto.Eclipse è una delle applicazioni Java più impressionanti in circolazione, funziona abbastanza bene su macchine più recenti con molta RAM.

Answer 2

BENE, peso mosca è uno schema ridicolo da utilizzare in un elaboratore di testi.IIRC, facevano riferimento a ciascun personaggio come oggetto [nota:era per ciascuno glifo, il che è comunque pazzesco perché il tuo sistema operativo lo disegnerà felicemente per te].Con un puntatore più largo di un carattere e tutta l'elaborazione associata all'indirizzamento indiretto, saresti un pazzo a utilizzare quel particolare modello in questo modo in un elaboratore di testi.

Se sei interessato alla progettazione di elaboratori di testi, ho trovato un articolo che non affronta i modelli ma esamina alcuni dei strutture di dati alla base della progettazione di un elaboratore di testi e considerazioni sulla progettazione.

Cerca di ricordare che i design pattern esistono per semplificarti la vita, non per essere puro.Ci deve essere un motivo per utilizzare un modello, deve offrire qualche vantaggio.

Answer 3

Lo scopo di GoF e dei pattern in generale è parlare di come fare le cose "giuste" nel senso di corretto, non necessariamente "giuste" nel senso di giuste per le circostanze.Laddove le prestazioni sono un problema e scopri che nessun modello con nome fornisce prestazioni adeguate, forse puoi giustificare di andare per la tua strada.Ma una buona conoscenza dei modelli ti dà un "default ragionevole" e probabilmente significherà sacrificare chiarezza / SoC / ecc. solo quanto necessario per fornire prestazioni adeguate.

La sensazione che stai "deviando" dalla norma ti incoraggia a a) pensarci due volte e b) commentare bene il codice non idiomatico.

I modelli sono conoscenze vitali, ma nulla è vangelo e devi sempre applicare il giudizio.

Detto questo, non riesco a pensare a nessun motivo per cui non potresti scrivere un editor di testo decente utilizzando pattern e un moderno JDK

Answer 4

Una delle cose che devi ricordare è che il libro GoF è stato scritto all'inizio degli anni '90, quando i sistemi operativi prevalenti non disponevano di librerie grafiche estese.Anche Windows a quel tempo non era ancora un sistema operativo.

IIRC GoF è stato rilasciato nel 1994.Anche nel 1994 era disponibile Windows 95 Beta (e funzionava sul mio 486DX33) e Windows 3.x era in circolazione dal 1990 circa.

Answer 5

Eclipse + netbeans + IntelliJ sono tutti scritti praticamente tutti in Java o qualcosa che gira su JVM (non C++).In almeno 2 di questi IDE ho trascorso un po' di tempo con il codice dell'editor, quindi posso assicurarti che è tutto Java (e non è nemmeno facile).

VS 2005 è stata la mia ultima esperienza di visual studio, e anche allora pensavo che Eclipse fosse molto più reattivo (intelliJ doppiamente dato il tempo di riscaldamento e indicizzazione).

Non sono sicuro di quanto sia rilevante, ma questa è la mia esperienza.Ma sono sorpreso che Visual Studio sia ancora oggi scritto in C++ - penso che sarebbe nell'interesse di Microsoft usare C# - se non altro spingerebbe davvero al massimo le sue prestazioni, niente come mangiare il cibo del tuo cane!

Answer 6

Sì, le macchine attuali sono abbastanza veloci e hanno abbastanza memoria per renderlo possibile.Se dai un'occhiata a Squeak, vedi un IDE Smalltalk scritto in Smalltalk, significativamente più lento di Java, ma comunque abbastanza veloce.D'altra parte, l'editing video HD è qualcosa che attualmente necessita di un supporto di livello inferiore.

Answer 7

Questa domanda in realtà sembra riguardare Java vs.Prestazioni C++, e questo non è tanto l'orientamento agli oggetti quanto l'esecuzione su una macchina virtuale con garbage collection e simili.

Questo white paper su Java vs.Potrebbe valere la pena leggere le prestazioni del C++.