L'importanza dei modelli di progettazione con Javascript, NodeJs et al

Do you as a Javascript developer consider the traditional Design Patterns as important or less important than they have been with other languages / environments?.

Gli schemi di design classici non si applicano a JavaScript.

Ciò che è applicabile è scrivere codice modulare e funzionale.

Dovresti utilizzare una combinazione di costruttori e funzioni di prima classe.

Come sviluppatore JavaScript, personalmente spingo verso il trattamento di JavaScript come LISP piuttosto che Java. Quindi cerca di emulare monadi e codice di stile funzionale di alto livello piuttosto che provare a emulare il codice OOP classico.

Please name the top three design patterns you, as a Javascript developer use regularly and give an example of how they have helped in your Javascript development.

Anche in questo caso i pattern di design non si applicano molto ma sotto ci sono tre costrutti importanti.

1. Uso delle chiusure
2. Uso di funzioni di prima classe
3. Uso di fabbriche oggetto con o senza new

Per favore lascia un qualche tipo di contesto per il quale posso mostrare esempi di questo tipo di tecniche rispetto a fare lo stesso tipo di codice usando schemi di design tradizionali.

Diamo un'occhiata ad alcuni dei classici Design Patterns e a come implementarli in js, nonché a modelli alternativi più adatti a js stesso:

Pattern osservatore:

In node.js questo è semplicemente events.EventEmitter . In jQuery questo è $.fn.bind & & %codice%. In $.fn.trigger questo è backbone e Backbone.Events.trigger . Questo è un modello molto comune utilizzato nel codice giorno per giorno.

Non mi fermo mai e penso "Hey sto usando uno schema di osservatori qui!". No, questo è solo un modo di livello basso per trasmettere messaggi in giro o un modo per cambiare a cascata.

Ad esempio in backbone tutte le viste MVC si associano ai modelli Backbone.Events.bind event, quindi la modifica del modello comporta la sovrapposizione automatica di eventuali modifiche alla vista. Sì, questo è uno schema potente, ma il suo uso è così comune nella programmazione guidata dagli eventi che non si stavano rendendo conto di averlo utilizzato ovunque.

Nel prototco onchange abbiamo WebSocket che usiamo per associare agli eventi .on . Di nuovo questo è molto comune ma è un osservatore su uno stream piuttosto che il tuo classico OOP basato su on("message", ... .

Questi sono tutti usi potenti del modello di Osservatore. Ma questo non è uno schema che usi. Questa è una parte semplice della lingua. Questo è solo codice.

Memento Pattern:

Questo è semplicemente JSON. Permette di serializzare lo stato di un oggetto in modo da poter annullare un'azione.

function SomeObject() {
    var internalState;

    this.toJSON = function() {
        return internalState;
    }

    this.set = function(data) {
        internalState = data;
    }

    this.restore = function(json) {
        internalState = JSON.parse(json);
    }
}

var o = new SomeObject();
o.set("foo"); // foo
var memento = JSON.stringify(o);
o.set("bar"); // bar
o.restore(memento);

In JavaScript supportiamo nativamente un'API per i ricordi. Basta definire un metodo chiamato while (byte b = Stream.ReadNextByte()) su qualsiasi oggetto. Quando chiami toJSON chiamerà internamente JSON.stringify sul tuo oggetto per ottenere i dati reali che desideri serializzare su JSON.

Questo ti permette di creare istantaneamente il tuo codice.

Ancora una volta non mi rendo conto che questo è un modello di memento. Questo è semplicemente utilizzando lo strumento di serializzazione che è JSON.

Pattern stato / modello di stato:

Non hai bisogno di uno schema di stato. Hai funzioni di prima classe e tipi dinamici. Basta iniettare funzioni o modificare le proprietà al volo.

Prendi questa risposta come opinione soggettiva.

Do you as a Javascript developer consider the traditional Design Patterns as important or less important than they have been with other languages / environments?

Se intendi modelli di design tradizionali come Gang of Four , la maggior parte delle tecniche sono indipendenti dalla lingua e dalla piattaforma come " Programmare un'interfaccia, non un'implementazione "o" Favorire la composizione di un oggetto sull'ereditarietà della classe "e sono ugualmente importanti anche per gli sviluppatori di JavaScript.

È possibile o meno dover utilizzare pattern più specifici, come creatività, struttura e comportamento, nello stesso modo o con frequenza come in altre lingue, poiché le funzionalità linguistiche possono influire in larga misura sul loro utilizzo. Alcune lingue (JavaScript incluso) hanno quindi i loro modelli di progettazione basati sulla funzionalità o sullo zucchero sintattico che offrono.

In generale, direi che i modelli di design tradizionali sono tanto importanti quanto lo sono in altri linguaggi, ma i pattern specifici di JavaScript sono più importanti di quelli tradizionali.

name the top three design patterns you, as a Javascript developer use regularly and give an example of how they have helped in your Javascript development

Tra i Modelli di progettazione JavaScript essenziali utilizzo principalmente questi:

1. Modello di costruzione (con prototipi)

Specialmente sul lato server durante la scrittura di roba node.js, perché è adatto per scrivere moduli anche se manca l'incapsulamento nativo. Inoltre è popolare per molti altri sviluppatori se si esplorano i repository su GitHub, quindi la familiarità con questo modello può aiutarti a comprendere meglio altri codici.

2. Modello del modulo rivelatore

Offre modularità con l'incapsulamento.

3. Pattern DRY

Questo è piuttosto specifico per lo scenario, anche se ogni sviluppatore dovrebbe usarlo il più (im) possibile.

I modelli di progettazione vengono insegnati nelle classi di progettazione per CS. Non sono essenziali, ma davvero utili se riesci a trovare situazioni analoghe per avere una soluzione che è stata pensata.

Consente inoltre ai programmatori di comunicare più facilmente. Puoi parlare anche con il tuo collega in termini di modelli. Se tu dici qui ho il mio Observer, quindi è abbastanza ben capito cosa sta succedendo.

Le persone troveranno naturalmente soluzioni che si adattano a un modello di progettazione per conto proprio, ma i modelli di progettazione aiutano a definire la terminologia e le idee standard che possono essere utili.

Non c'è niente di straordinario nei modelli, la cosa più bella è che sono idee canonizzate e definite in modi che sono ripetutamente utili.

Do you as a Javascript developer consider the traditional Design Patterns as important or less important

Sono vitali.

Questo perché i concetti per le soluzioni riutilizzabili possono trascendere il linguaggio.   - modifiche alla sintassi   - cambiamenti di implementazione   - La nozione per il modello esiste ancora.

Gli sviluppatori di qualsiasi lingua possono apprendere JS avanzati mediante modelli di apprendimento, non di sintassi.   Coloro che non lo sanno, mancano.

Please name the top three design patterns you, as a Javascript developer use regularly

Ci sono modelli usati frequentemente a cui alcuni "controbatterebbero". Tuttavia, sono utili perché sono estremamente comuni e potenti nel JS avanzato.

1- Namespace: avvolgi il tuo codice in un oggetto.

var x = (function () {}) ();

2- ObjectConfiguration, modello simile alla fabbrica. -Passare un oggetto a una funzione, non un gruppo di vars.

var product = factory ({});

3- Funzione di richiamata. - Passa una funzione come parametro, da chiamare quando l'attività è completata.

function longTask (function () {// mi chiama quando finito});

Come ho detto, alcuni potrebbero obiettare che questi non sono schemi, ma sono molto comuni e molto potenti, e dovrebbero essere menzionati perché sono davvero utili solutoni riutilizzabili ai problemi comuni. Qual è la definizione di Design Pattern.

Ottima domanda.

Spero che ti aiuti.