Sta usando la tipizzazione statica della soluzione per progettare il dominio e ridurre il numero di errori?

Question

Sta usando la tipizzazione statica della soluzione per progettare il dominio e ridurre il numero di errori?

#1 da (2 voti)
#2 da (1 voti)

5

Stiamo usando PHP (un linguaggio tipizzato dinamicamente) nel nostro progetto. Tuttavia, ho trovato i miei colleghi che facevano domande come link .

Mi sento come se avessimo una paranoia che avremmo degli errori inattesi (ad esempio, se osservi la domanda di esempio, vedrai che il poster sta chiedendo come assicurarsi che un like non venga inizializzato per un Person ), e stiamo usando la tipizzazione statica (qualcosa che non esiste in PHP) insieme ai test unitari per aiutarci a riposarci facilmente di notte. : -)

Ora, la cosa che mi dice che il nostro approccio è sbagliato è il numero di grandi siti web scritti usando linguaggi tipizzati dinamicamente: Google usa estensivamente Python, Facebook è scritto usando PHP, Twitter e GoodReads sono scritti usando Ruby. Quindi quello che sento è che le applicazioni web, per lo meno, si stanno spostando verso linguaggi tipizzati dinamicamente.

Tuttavia, non importa quanto cerco di comprenderlo, non posso. Questi ragazzi non hanno problemi a comprendere il dominio? Non hanno problemi che sorgono quando si usano linguaggi tipizzati dinamicamente (E.G. "La proprietà whatever non è definita su questo oggetto.")? Se lo fanno, come si comportano con quelli mantenendo l'agilità che deriva dall'uso di linguaggi tipizzati dinamicamente?

php python static-typing dynamic-typing ruby

posta Parham Doustdar 07.12.2013 - 07:42

fonte

2 risposte

1

Stai pensando troppo alle differenze tra linguaggi interpretati e compilati e non realizzi realmente il vantaggio della creazione dinamica di oggetti e della progettazione orientata agli oggetti.

Supponendo di avere una situazione simile alla domanda collegata, in cui un utente potrebbe like a Business ma non a Person , sarebbe meglio non consentire un'istanza diretta di un oggetto Like distinto , ma invece di eseguire l'esecuzione puntare a un metodo sull'oggetto Business .

Cioè, invece di:

//Like a business
$thisBiz = ...;
$myLike = new Like[$thisBiz];

Potresti avere:

//Like a business
$thisBiz = ...;
$myLike = $thisBiz.Like();

Se un altro programmatore cerca di chiamare un metodo di un oggetto che non lo possiede, otterrà un errore di runtime, e un buon IDE lo catturerà in fase di progettazione. Che è esattamente ciò che accade in un linguaggio compilato con tipi statici.

Il vero potere della digitazione dinamica è quando vuoi cambiare il modo in cui funzionano le cose. Se Like è un oggetto che accetta un business come parametro e vuoi consentire anche alle persone di essere apprezzate, potresti dover fare un secondo Like costruttore, o anche una classe separata, o addirittura ridefinirlo per accettare un genitore Thing che sia Businesss che Person possano essere CAST. Oppure puoi semplicemente aggiungere il metodo alla classe Person e farlo con esso.

risposta data 07.12.2013 - 09:17

fonte

Leggi altre domande sui tag php python static-typing dynamic-typing ruby

Come posso integrare gli ambienti di sviluppo web locali con una soluzione SSO centrale? Best practice per l'utilizzo di sessioni HTTP (Java)

score 2 · Accepted Answer

how do they deal with those while keeping the agility that comes with using dynamically-typed languages?

Molte persone sostengono che se vuoi davvero essere agile (ovvero modificare comodamente il tuo codice spesso), hai bisogno di test delle unità .

Affidarsi al compilatore per essere sicuri che: 2 + 2 = Number è in realtà solo un falso senso di sicurezza. Quindi, se hai intenzione di prendere la briga di scrivere un test unitario, perché non essere un po 'più accurato e test: 2 + 2 = 4?

Con Domain Driven Design, hai a che fare con problemi e oggetti molto più complicati (è tipicamente il motivo per cui viene utilizzato) che a malapena sarà gestito dal solo controllo dei tipi. Considera di scrivere alcuni test.