Non riesco ad afferrare la programmazione dei modelli di progettazione

16

Ho lavorato con JavaScript per gli ultimi 4 anni. Sono molto fiducioso delle mie capacità di problem solving e vedo che la qualità del mio codice sta migliorando. Cerco di rimanere aggiornato con la community e attualmente sto lavorando con ES2015 e React.js. Tuttavia, mi sento come se non riuscissi affatto a capire i modelli di progettazione programmata. So dove trovare risorse su questo e ho già letto libri a riguardo. Mi affido ai miei colleghi senior per prendere decisioni sulla struttura del progetto, ma non ho problemi a lavorarci su.

Ogni volta che devo iniziare qualcosa da solo cerco questi due percorsi: se sto usando una grande libreria / framework come React.js, tendo a copiare ciò che la community sta facendo; Se sono su qualcosa di più piccolo userò il modello del modulo. So che una volta che avrò una migliore comprensione di questo argomento, sarò in grado di prendere decisioni migliori, ma per ora sono completamente perso.

Dovrei cercare un'istruzione superiore su questo? Ho bisogno di un mentore su questo argomento? Sono solo stupido? È davvero così difficile da capire?

design-patterns javascript

— Abensur
fonte

6

Secondo me alcune lingue sono più "indulgenti" di altre quando si tratta della necessità di utilizzare modelli di design. I linguaggi compilati fortemente tipizzati (come Java e C #) sono più influenzati dalla cattiva progettazione rispetto ai linguaggi di scripting tipicamente deboli come JavaScript e PHP. Per non dire che i modelli di progettazione non sono utili per entrambi, ovviamente.

— Matteo,

3

Anche le dimensioni del progetto svolgono un ruolo significativo.

— Matteo,

2

@Matthew nitpick Non chiamerei necessariamente Java / C # fortemente tipizzato ...

— Jared Smith

2

@JaredSmith vero, spesso dimentico la distinzione tra fortemente tipizzato e tipicamente statico.

— Matteo,

6

Se stai cercando di capire i motivi in generale , fermati ! Non c'è niente lì! Un modello è una soluzione popolare a un problema che si verifica comunemente e qualcuno gli ha dato un nome. Questo è tutto quello che c'è da fare. Potresti trovare difficile cogliere qualche modello specifico - io stesso faccio fatica a ricordare come utilizzare efficacemente il modello "visitatore" per imitare il doppio invio in Java - Ma se stai cercando la salsa segreta che collega "visitatore" a, dire "oggetto trasferimento dati", non lo troverete. Sono solo due soluzioni popolari a due problemi comuni, qualcuno ha dato loro i nomi e i nomi sono rimasti bloccati.

— Solomon Slow

34

I modelli di progettazione software sono soluzioni ben note a problemi noti. Il modo in cui li capisci è apprendendo gli schemi, capendo come funzionano e sapendo quando è appropriato applicare ciascuno alla progettazione del tuo software.

Il modo in cui apprendi i modelli di progettazione del software è studiandoli, uno alla volta. È un processo di educazione continua. Se si desidera ridurre l'impronta di apprendimento, studiare quei modelli che si riferiscono direttamente alle tecnologie che si stanno attualmente utilizzando.

Alcune cose importanti da sapere sui modelli di design:

Alcuni modelli di design sono di natura architettonica. MVC e MVVM sono esempi di tali schemi. Utilizzi tali modelli quando hai bisogno dei benefici organizzativi e strutturali che offrono.
Alcuni modelli di progettazione sono soluzioni alternative per carenze nei linguaggi di programmazione. Non avrai bisogno di questi schemi se usi un linguaggio di programmazione più espressivo, ma spesso non riesci a fare questa scelta. La maggior parte dei modelli di GoF sono in questa categoria .
Utilizzare un modello software solo quando si tenta di risolvere il problema che il modello è stato progettato appositamente per risolvere. Se stai scrivendo un'applicazione cucendo insieme modelli di software, stai sbagliando.
Non esiste un modello software esistente per ogni problema informatico esistente. In tal caso, la programmazione sarebbe semplicemente un esercizio di abbinamento dei modelli.
Alcuni schemi sono in realtà anti-schemi. L'ulteriore complessità che questi schemi introducono supera i vantaggi che essi offrono. Dovrai decidere tu stesso, su base schema per modello, quale di questi schemi eviterai.

— Robert Harvey
fonte

Buona risposta, anche se non sarei d'accordo con l'affermazione secondo cui la maggior parte dei modelli GoF è una soluzione alternativa per carenze nei linguaggi di programmazione. Spesso, alcuni schemi sono meglio applicabili ad alcune lingue, sì, perché le lingue tendono ad essere progettate tenendo conto di determinati problemi e soluzioni.

— Poligono

1

I modelli Gof hanno 20 anni. La maggior parte di questi sono stati creati per risolvere problemi con C ++, problemi che Java ha ereditato perché Java si basa su C ++.

— Robert Harvey,

Il paradosso di questa risposta è la parte del "problema ben noto". È difficile capire questi "problemi ben noti" se non li hai mai sperimentati.

— Fuhrmanator,

2

Java non è basato su C ++. La sintassi javas è ispirata al C ++, ma di certo non si basa su di esso. entrambe le lingue funzionano in modo piuttosto diverso. Dal fatto che Java abstact l'hardware, gestisce la memoria da solo, oltre a non avere modelli ma piuttosto generici ecc.

— Polygnome

4

L'approccio di ognuno all'apprendimento è un po 'diverso, e non ho idea di quale sia il tuo approccio generale, ma credo che tu ti stia comportando male e ti definisca "stupido".

Personalmente, dalle mie osservazioni su ciò che molti chiamerebbero ingegneri del software "di successo", designer ecc. Hanno tutti un tema comune per il loro apprendimento: "esperienza". Credo che questa sia la tua "educazione superiore" e imparerai più rapidamente da essa che comprare tonnellate di libri su Amazon e leggere attraverso di loro (una mia cattiva abitudine).

Quindi, ad esempio, prendi un modello GOF come il modello di comando e implementalo nella tua lingua scelta. Comprendi quali vantaggi offre a te e agli svantaggi. I vari libri sui modelli di progettazione ti spiegheranno questo, ma ritengo sia meglio applicare tale conoscenza praticamente e imparare da essa. Non scartare il materiale di lettura, hanno uno scopo, ma il mondo dell'IT non è certo un esercizio da manuale. Detto questo, questa è la mia opinione e opinione sul mondo dell'IT e in parte, rappresenta le proprie lotte all'inizio della mia carriera nell'ingegneria del software. Inoltre, un grosso problema che vedo, anche con sviluppatori di software molto esperti è l'impazienza e dimenticare di apprezzare ciò che stanno facendo. Quindi prenditi il tuo tempo con quello che stai imparando e ricorda di goderti davvero quello che stai facendo, altrimenti perché preoccuparti di investire tempo in esso?

Inoltre, fai uso dell'esperienza pratica di altre persone. Esistono moltissime soluzioni open source, sia buone che cattive, e puoi imparare da esse. Guarda come hanno applicato i modelli e pensa a come affrontarli diversamente.

Quindi, il mio consiglio generale è che se ritieni che il tuo approccio sia sbagliato, modificalo. Guarda le persone intorno a te che ritieni stiano imparando il materiale che ritieni non ti stiano afferrando e guarda cosa stanno facendo o addirittura chiedi loro.

— Pianeta Desolato
fonte

1

Penso davvero che la programmazione sia come il gioco degli scacchi. Potresti avere del talento nativo, potresti giocarci tutto il giorno, ma se non leggi alcuni libri sugli scacchi non puoi fare alcun progresso e, cosa più importante, non puoi apprezzare la bellezza del gioco.

— Adrian Iftode,

@AdrianIftode - concordato. Come accennato, non avrei scontato libri, blog o altro materiale di lettura, ma è un problema comune che ho riscontrato con le persone che lottano per la padronanza in un linguaggio di programmazione / piattaforma / framework ecc. E apparentemente hanno fatto poca codifica e / o pratica sforzo, ma ho letto tutti i libri a cui puoi agitare un bastone.

— Desolato pianeta

@AdrianIftode Bene, non proprio. Giocando a scacchi senza leggere libri, puoi ancora imparare molto sul gioco. L'unica differenza è che non stai imparando il più velocemente possibile attingendo ad alcune esperienze e pensieri di maestri di scacchi. D'altra parte, pensando a certe cose, potresti imbatterti in una soluzione o due che è stata totalmente trascurata dalle persone che imparano solo dai maestri di scacchi e che potresti usare a tuo vantaggio. Alla fine, credo che una combinazione di entrambi i tipi di apprendimento offra i migliori benefici. Negli scacchi e nella programmazione.

— cmaster - reintegra monica il

1

La risposta breve è che non hai bisogno di loro. Puoi scrivere codice senza di loro. Come ha detto Matthew nei commenti, ciò è particolarmente vero in JavaScript, dove la lingua è abbastanza flessibile e i progetti tendono ad essere più piccoli. Ma se stai programmando da 4 anni, trovo difficile credere che non ti sia imbattuto in cose che sembrano ripetitive o imbarazzanti. Sono quelle aree che stai riscoprendo o mancando i modelli di progettazione.

Esempio: il sistema di eventi JavaScript è spesso inadeguato all'attività da svolgere. Non ti ritrovi mai a voler essere in grado di combinare o trasformare flussi di eventi? O quella serie di eventi erano valori di prima classe a sé stanti? Sono necessari i modelli di mediatore e / o osservatore. Hai bisogno di un'associazione dati a 2 vie? Stessa storia.

La fragile gerarchia dei prototipi è scaduta? Mixin / Trait / Subclass Pattern di fabbrica in soccorso.

— Jared Smith
fonte

4

È praticamente impossibile scrivere qualsiasi programma non banale senza usare alcun modello di progettazione, in genere ne userai anche molti di quelli comuni. Quello che non ti serve è essere in grado di riconoscere i modelli che stai usando per nome. Puoi scrivere il codice di lavoro anche se non puoi nominare tutti i modelli di progettazione che stai usando in tutto il codice.

— Servito il

I modelli di @Servy Design sono astrazioni, le astrazioni non sono strettamente necessarie. Puoi sempre scrivere un'implementazione una tantum ad hoc del comportamento sottostante ... ancora e ancora e ancora. Ad esempio nell'esempio che ho fornito sugli eventi, è possibile collegare manualmente tutte le parti interessate e quindi modificarle tutte le volte che cambiano i requisiti, fa solo schifo rispetto all'utilizzo di pub / sub. Per le sottoclassi è possibile (se è dispendioso) codificare manualmente in ogni possibilità con un gruppo di classi una tantum, non è altrettanto buono.

— Jared Smith,

1

I modelli di progettazione possono diventare molto ampi. Spesso modelli di progettazione più ampi sono così ovvi che non li consideriamo nemmeno come modelli di progettazione (specialmente quando hanno un supporto linguistico speciale). Un loop è un modello di progettazione. Le funzioni sono un modello di progettazione. Gli oggetti sono un modello di progettazione.

— Servito il

@Servy se è così che usi il termine, quindi non sono in disaccordo, ma ho l'impressione che l'OP intendesse specificamente i modelli GOFish.

— Jared Smith,

1

I modelli di design di @JaredSmith non sono astrazioni. Anche se li implementi ancora e ancora e ancora per il problema concreto che hai, sono comunque dei modelli . Non è necessario scrivere un generico classe Observer e utilizzarla per utilizzare il modello Observer . Scrivere osservatori concreti e metodi concreti per registrarsi e notificarli sta ancora usando il modello. la cosa difficile è riconoscere il modello. A volte stai usando uno schema senza nemmeno conoscerne il nome,

— Polygnome,

1

Trova un mentore, qualcuno con un'ottima esperienza da cui imparare. Fagli una domanda guarda il suo codice, invia una recensione del codice e prova a collaborare con lui. Questo è il modo migliore per aumentare le tue capacità di programmazione.

extra:

Collabora ad alcuni semplici progetti OSS che ti piacciono
Quando esistono due modi per risolvere lo stesso problema, scegli sempre il più semplice
Crea un'esperienza extra con progetti secondari in cui sei libero di commettere ogni tipo di strano errore e imparerai il modello di progettazione "nel modo più duro" (tm)

— Motocarota
fonte