Está usando a tipagem estática da solução para design orientado a domínio e diminuindo o número de erros?

5

Estamos usando PHP (uma linguagem tipada dinamicamente) em nosso projeto. No entanto, encontrei meus colegas fazendo perguntas como link .

Sinto que temos uma paranóia de que receberemos erros inesperados (por exemplo, se você observar essa pergunta de exemplo, verá que o pôster está perguntando como garantir que like não seja inicializado para um Person ), e estamos usando tipagem estática (algo que não existe no PHP) junto com testes de unidade para nos ajudar a ficar tranquilos à noite. : -)

Agora, o que me diz que nossa abordagem está errada é o número de grandes sites escritos usando linguagens dinamicamente tipificadas: o Google usa Python extensivamente, o Facebook é escrito usando PHP, Twitter e GoodReads são escritos usando Ruby. Então, o que eu sinto é que aplicativos da web - no mínimo - estão se movendo em direção a linguagens dinamicamente tipadas.

No entanto, não importa o quanto eu tente compreender isso, não posso. Esses caras não têm dificuldade em compreender o domínio? Eles não têm problemas que surgem ao usar idiomas com digitação dinâmica (por exemplo, "Propriedade whatever não está definida neste objeto")? Se eles fazem isso, como eles lidam com eles enquanto mantêm a agilidade que vem com o uso de linguagens dinamicamente tipadas?

    
por Parham Doustdar 07.12.2013 / 07:42
fonte

2 respostas

2

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

Muitas pessoas argumentam que, se você realmente deseja ser ágil (ou seja, alterar confortavelmente seu código com frequência), é necessário um teste de unidade .

Confiando no compilador para ter certeza: 2 + 2 = O número é apenas uma falsa sensação de segurança. Então, se você vai se dar ao trabalho de escrever um teste unitário, por que não ser um pouco mais preciso e testar: 2 + 2 = 4?

Com o Domain Driven Design, você está lidando com problemas e objetos muito mais complicados (normalmente é por isso que é usado.) que mal serão gerenciados apenas pela verificação de tipos. Considere escrever alguns testes.

    
por 07.12.2013 / 12:53
fonte
1

Você está pensando demais nas diferenças entre linguagens interpretadas e compiladas e não está realmente percebendo os benefícios da criação de objetos dinâmicos e do design orientado a objetos.

Supondo que você teve uma situação semelhante à pergunta vinculada, em que um usuário poderia like a Business mas não Person , seria melhor não permitir uma instanciação direta de um objeto Like distinto mas, em vez disso, tornar o ponto de execução um método no objeto Business .

Isto é, em vez de:

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

Você poderia ter:

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

Se um último programador tentar chamar um método de um objeto que não o possui, ele receberá um erro de runtime, e um bom IDE também o detectará em tempo de design. O que é exatamente o que acontece em uma linguagem compilada com tipos estáticos.

O poder real da digitação dinâmica é quando você quer fazer uma alteração em como as coisas funcionam. Se Like for um objeto que usa um business como parâmetro e você quiser permitir que outras pessoas também sejam apreciadas, talvez seja necessário criar um segundo Like construtor, ou até mesmo uma classe separada, ou até mesmo redefini-lo para aceitar um Thing pai que tanto Businesss como Person podem ser CAST para. Ou você pode simplesmente adicionar o método à classe Person e acabar com isso.

    
por 07.12.2013 / 09:17
fonte