Quanto dipende l'architettura software dalla lingua?

Mentre mi istruisco sull'architettura del software e sui modelli di progettazione, ho notato che nella maggior parte dei casi alcune caratteristiche del linguaggio e specifiche di progettazione sono implicite nella spiegazione.

Ad esempio praticamente qualsiasi articolo o libro che illustrerà le idee usando classi e interfacce. Tutto ciò che si può facilmente trovare su questo argomento menzionerebbe oggetti e concetti OOP.

E se la lingua in cui è scritto il sistema non avesse tali concetti? Ad esempio, se uso Python o Node, che sono tipizzati in modo dinamico e non hanno una nozione di interfaccia? Cosa succede se uso TypeScript in cui un'interfaccia è un costrutto effimero, che non esiste in fase di esecuzione? E se sto cercando di abbracciare la programmazione funzionale? Devo ignorare ad esempio SOLID e cercare altri concetti, adatti alla mia lingua?

Se sì, quali sono quelli? Sfortunatamente tutti i paradigmi ben adottati (per quanto ne so) si riferiscono in qualche modo a concetti e tipi di OOP. In caso negativo, quali regole devo seguire per adattare l'architettura generale e i principi di progettazione al mio linguaggio specifico e al mio caso d'uso?

Come descriveresti in generale la dipendenza tra architettura e linguaggio?

Un'architettura software è molto simile all'architettura di una casa o di un ponte. Un ponte deve contenere il peso di se stesso e dei veicoli che lo percorrono o delle persone che lo percorrono. Deve resistere alle intemperie. I materiali che usi per costruirlo devono essere sia resistenti che relativamente leggeri.

Ci sono molti materiali che puoi usare per costruire una casa. Puoi usare mattoni o stucchi. Puoi usare travi di legno o di metallo. Ogni materiale ha le sue caratteristiche, in termini di peso, resistenza e così via. Tutte queste caratteristiche influenzano l'architettura.

Allo stesso modo, il linguaggio di programmazione che usi influenza il modo in cui costruisci la tua architettura. La tua architettura avrà un aspetto diverso in un linguaggio di programmazione che ha classi come C ++ rispetto a un linguaggio di programmazione che non lo è, come C.

I principi SOLID riguardano principalmente le lingue orientate agli oggetti (ovvero le lingue che hanno classi).

L'architettura dipende dalle capacità per raggiungere i suoi obiettivi. Le scelte linguistiche possono limitare le capacità. Qualsiasi linguaggio completo Turing ha la capacità di completare qualsiasi attività di programmazione. Dopodiché si parla di quanto sia leggibile la lingua umana che la soluzione sia.

Molti schemi di architettura software richiedono di rimuovere tutte le conoscenze sulle scelte tecnologiche dalle regole aziendali del dominio principale. L'unica scelta tecnica di cui non puoi mai rimuovere la conoscenza dal nucleo è la lingua in cui scegli di esprimerla.

Quando i libri di Architettura si limitano a parlarti dei loro obiettivi, la lingua non ha importanza finché è in grado di raggiungere l'obiettivo. Quando i libri ti dicono come raggiungere questi obiettivi, la lingua inizia a diventare materna.

L'architettura come termine ha un significato davvero specifico che è molto legato all'architettura nel mondo fisico e al suo centro riguarda l'arte e la pratica della costruzione delle cose, il modo in cui le cose sono fatte e messe insieme. In questo modo, quando l'architettura è fatta bene, penso che il linguaggio sia molto legato all'architettura, proprio come un edificio ben progettato dovrebbe essere intimamente informato dal materiale con cui è stato costruito.

Nel software, le scelte architettoniche dovrebbero essere fatte in modo congruente con le proprietà del linguaggio. Se stai costruendo un sistema con un linguaggio orientato agli oggetti, mi aspetterei che anche l'architettura del sistema sia orientata agli oggetti. Se stai costruendo un sistema con un linguaggio funzionale, mi aspetto che anche l'architettura di quel sistema sia funzionale.

Ha senso?

Direi, per cominciare, che anche la lingua in cui pensi ha una profonda influenza in ciò che puoi concepire. C'è una ragione per cui PASCAL è stato creato da Niklaus Wirth e C da Brian Kernighan e Dennis Ritchie.

A un livello superiore, la capacità di esprimere determinati concetti (e la mancanza di altri) indirizzerà il tuo pensiero e ti farà arrivare a certe soluzioni che non sarebbero necessariamente la stessa altra persona, con un background diverso, verrebbero fuori.

Infine, i concetti citati possono essere tutti implementati in qualsiasi linguaggio di uso generale. È solo che potrebbero non avere supporto sintattico e l'implementazione potrebbe essere ingombrante. Puoi scrivere codice assembly x86 orientato agli oggetti se sei sufficientemente impegnato (o abbastanza folle) proprio come potresti fare con C. In effetti, le prime implementazioni di C ++ erano preprocessori che compilarono il tuo codice C ++ in C (e i nomi dei simboli alterati fatti debugging molto più divertente).