6 maneiras de fazer a mesma coisa, o que é considerado boas práticas?

As vezes tem tantas maneiras diferentes de fazer o mesmo código que nós ficamos na dúvida quanto a qual maneira usar. O que seria considerado "boa prática" pela comunidade e o que sua equipe entenderia melhor. Suponhamos que você esteja trabalhando dentro de um método de um Domain Service chamado UmDomainServiceChique(objetoDoDominio) que será chamado por uma API. Você tem uma regra de negócio chique para ser verificada que por enquanto chamarei de VerificaMinhaRegraChiqueComplexa(). Você chama UmDomainServiceChique(objetoDoDominio) e caso VerificaMinhaRegraChiqueComplexa() retorne true você vai querer que UmDomainServiceChique faça o que tem que fazer e a api retornar Ok 200, caso contrário você quer que a API responda um erro qualquer, tipo BadRequest, e retornar uma mensagem dizendo que VerificaMinhaRegraChiqueComplexa deu ruim. Eu vejo 6 maneiras de fazer isso, gostaria de saber a opinião de outrs devs sobre qual seria a maneira menos gambiarr

Delphi Prism, porque não vale a pena

Update
O Prism nunca foi da Embarcadero, ele pertence a Rem Objects, que tinha um contrato com a Embarcadero até esse ano, mas esse contrato já expirou e as duas empresas vão seguir seus caminhos.
O último Delphi Prism foi a versão XE3, se não me engano, mas o Rad Studio XE4 não virá com o Prism, como diz o Andreano Lanusse e o próprio pessoal da Rem Objects.
O Prism foi descontinuado na Embarcadero, mas continuará a evoluir na Rem Objects sob o nome de Oxygene (seu verdadeiro nome).
http://www.andreanolanusse.com/pt/delphi-xe4-conheca-as-novidades-para-ios-e-mais/
http://blogs.remobjects.com/blogs/mh/2013/04/17/p5822
http://www.itwriting.com/blog/7338-no-more-delphi-for-net-prism-removed-from-rad-studio-xe4.html
A partir desse momento a Embarcadero e a RemObjects não são mais parceiras, mas sim concorrentes, mas acredito que o Prism agora irá evoluir, implantando melhorias que não poderia antes devido às políticas da Embarcadero.
Sobre o velho assunto da "Morte do Delphi", eu acredito que o Delphi não irá morrer nunca, assim como o Cobol e o Clipper, mas está fadado à essa letargia: crescimento lerdo e muitas vezes na contra-mão. Todas as melhorias do Rad Studio 4 são tardias em comparação com outros ambientes, além de serem fortemente dependentes de aplicações / módulos de terceiros.
----------------------------------------------------


Antes de mais nada, Delphi Prism é uma excelente linguagem. Tem todos os recursos que uma linguagem moderna deve ter, é totalmente OO, tem sobrecarga de operadores, Generics, Lambda Expressions, Funções anônimas, é fortemente tipada mas permite type inference etc...

Longe de criticar a linguagem em si e quem investe nela, ou quem a concebeu, tenho algumas criticas com relação ao Delphi Prism que me levam a ponderar se vale mesmo a pena investir na linguagem, já explico o porque.

1) Você não vai economizar na curva de aprendizado. Se você acha que sendo um "Delpheiro" vai economizar na curva de aprendizado do Delphi Prism está enganado. Ao aprender, treinar e desenvolver em Delphi Prism você enfrentará os mesmos desafios que enfrentaria aprendendo C#. Isso se dá porque a maior parte desse aprendizado é referente à semântica (conjunto de bibliotecas, o como fazer) do que à sintaxe. A sintaxe você pega em um dia.

2) O Delphi Prism não é o Delphi .Net. O Delphi .Net (8, 2005, 2006 etc) morreu/foi descontinuado, uma pena. Mas este porduto ERA delphi. Não somente em termos de sintaxe e recursos da linguagem, mas em termos de semântica também. Afinal ele tinha uma "VCL", ou uma tentativa de se reimplementar a VCL no .Net Framework. Era um Framework dentro de outro. A migração do Delphi Win32 para o Delphi .Net era POUCO menos trabalhosa, e a curva de aprendizado um pouco mais suave.

3) Delphi Prism, ou Oxygene, é baseado em pascal, mas muito diferente se comparado com o Object Pascal. Não estou falando em termos de bibliotecas e frameworks que vem no pacote, mas sim de sintaxe. O uso da palavra method no lugar de function ou procedure na minha opinião é desnecessário. Agora, lembra do pascal? Para retornar o valor de uma função você fazia, no final do código da função, NomeFuncao := valor. Muito intuitivo, didático e inteligente. Internamente à função você pode usar o nome dela para atribuir-lhe o valor de retorno, como se ela fosse uma variável local dela mesma. Isso não impedia que se usasse chamadas recursivas ou ponteiros para função. No Delphi/Object pascal tivemos a introdução da variável artificial/implícita Result. Então se você tem uma função Soma, ela pode retornar o valor da maneira Soma := valor ou Result := valor. Result nada mais era do que um atalho, já que na época do pascal até meados do Delphi 1 todo mundo usava uma variável Result como acumulador temporário antes de retornar o valor da função. Mesmo assim Result ainda tem mais "cara" de variável do que de comando.
No Delphi Prism não existe mais a forma Soma := valor, ou método := valor. Você DEVE OBRIGATORIAMENTE usar Result. Result passou do status de "variável" para "comando". Result agora é para o prism o que o return é para as linguagens c-like. Só que sem a vantagem de abandonar imediatamente. Para isso você ainda deve forçar a saída do método. Na minha opinião tirar a sintaxe tradicional do pascal É UMA VIOLAÇÃO DO QUE É SANTO, sim, uma heresia.

4) Não existe (m) ferramentas, compiladores, alternativas gratuitas/open source para o Prism.  (o command line tools não conta, seu uso é muito restrito). Também não existem cursos/disciplinas dessa linguagem nos cursos técnicos ou tecnólogos. Logo, você não deve esperar facilidade em contratar um estagiário ou júnior nessa linguagem, muito menos um Sênior autodidata hobbista. A única maneira de ser um autodidata hobbista com Delphi Prism é com pirataria, e eu não faço apologia a pirataria.

Veja bem, continuo achando Delphi Prism demais, gosto muito mesmo, é uma iniciativa legal da Rem Objects e tem todo um histórico de coisas legais por trás disso, mas não programaria com ela se não fosse pago pra isso. Não que ela não tenha futuro, muito pelo contrário, ela pode ter um futuro promissor, mas tudo vai depender de como a dupla RemObjects Embarcadero divulgar e liberar a ferramenta. E não se iluda: Delphi Prism não é Delphi. Se você acha que pode fazer aplicações para IPhone / IPad / IPod no Delphi Prism muito mais facilmente simplesmente porque é "parecido" com Delphi está muito enganado. Utilizando C# você tem a mesma dificuldade, com a vantagem de instalar uma ferramenta a menos. (você não precisaria do prism, mas apenas do visual studio, mono develop, mono e monotouch). Mesmo assim desenvolver para IPhone / IPod / IPad é tão diferente do ambiente Delphi / Win32 que a acentuação na curva de aprendizado, ou seja, a sua dificuldade, estaria no ambiente, no sdk e nas api's da Apple, e não na linguagem. A dificuldade não mudaria muito se você escolhesse o objective-C. E não espere muita portabilidade do código feito em Prism para dentro e fora do windows/mac/linux. Isso porque as bibliotecas e apis que você usa em um não encontrará no outro. A unica coisa que dá para migrar são classes de negócio, as mais abstratas possíveis, e bibliotecas de serviços/funções feitas por você que são algoritmos puros, sem o uso de outras bibliotecas. Nada de GUI ou comunicações.

Basicamente é isso. Se por um acaso a linguagem ganhasse uma implementação open-source (GPL de preferência) e talvez um plugin para integrar sua sintaxe no Eclipse, Sharp Develop ou Mono Develop tudo bem. Enquanto esse dia não chega o Prism não passará de mais uma linguagem .Net entre tantas, com a desvantagem de ser para minorias e de ser só mais uma linguagem fechada e cara dentre tantas abertas e/ou gratuitas.

Críticas? Serão bem vindas. Trollagem? Dê-me audiência.

Comentários

  1. Concordo contigo... já tentou usar WPF com Prism? Carroça....

    ResponderExcluir
  2. É amigo, eu também concordo com muita coisa, mas para voce poder aproveitar boa parte de uma servidor DataSnap no Delphi, o Prism pode lhe ajudar. Eu achava que seria a melhor opção agora com o XE. Mas estou gostando muito de trabalhar com o C# e o criador do C# foi o criador do Delphi. Acho que a Embarcadero nunca vai chegar no mesmo nível do Visual Studio, pois vai sempre depender deles. Ainda estamos precisando de desenvolvimento para 64 bits que é uma coisa que está muito longe de acontgecer no Delphi ainda e no C# já é realidade e com a nova versão .Net 5.0 que já estão fazendo, teremos muitas novidades.
    Um abraço e parabéns pela iniciativa.
    Maurício Rocha

    ResponderExcluir
  3. Então Maurício. O Prism tem uma integração "legalzinha" com o DataSnap, mas para aproveitar o DataSnap 100% mesmo você usa o Delphi, não precisa do Delphi Prism. "Ah, mas o servidor está em Delphi Win32 + DataSnap e eu quero migrar o client para .net". Nada impede, mas nada impede também de se usar o C# com o datasnap, de se usar as bibliotecas do prism para datasnap no C#, já que é só importar os namespaces corretos, e nada impede de criar uma camada intermediaria com prism e consumi-la com C#. Mas é ter 2 trabalhos. Integração com projetos legados ou de base instalada é uma coisa. Começar um projeto do zero é outra.

    Na minha opinião o Delphi Prism é bom ... mas ele só seria "ótimo" se fosse de graça.

    ResponderExcluir
  4. A única coisa para acrescentar é que na versão "XE", o Delphi Prism já tem integração com a plataforma MONO e a IDE MONO Develop e, discordo em parte porque, mesmo que a "semântica" seja diferente, é muito melhor para aqueles que se dão bem com a sintaxe do Delphi (Object Pascal) e do FreePascal, programar em algo parecido, mesmo que pague a mais por isso... se não liga para ficar preso numa linguagem, aí vale a pena economizar e aprender C# ou VB.NET (até mesmo o C++). Bem que poderiam lançar algo parecido no mundo OpenSource mas, com tantos projetos e linguagens gratuitas de qualidade e já evoluídas não acho que alcançaria sucesso. Delphi já fez sucesso mas, hoje em dia é muito complicado com a competição do .NET, Java, Ruby on Rails, PHP, e muitos outros.

    ResponderExcluir
  5. Vitor, você falou muito bem. Estou trabalhando em um projeto à 5 meses utilizando o Delphi Prism, e como você colocou "Só trabalho porque me pagam pra isso". Sobre a integração com DataSnap, sim ela existe. Mas sinceramente, na hora do "vamos ver" ela deixa muito a desejar.

    Outro grande problema é que inevitavelmente o ambiente se torna mais lento, e a integração com componentes de terceiros (Estou usando os componentes da DevExpress para .Net) não é tão boa quanto seria no C#.

    Aqui em Goiânia sou instrutor Delphi,C# então assim como você não sou contra a ferramenta, mas como dica para quem deseja uma implementação rápida na plataforma .Net, recomendo o C#.

    O Prism é uma excelente proposta, ainda não tive a oportunidade de testar o Prism XE 2 logo espero que tudo que disse já tenha sido sanado nesta nova versão.

    Parabéns pelo blog, e espero lhe encontrar no DelphiCon.

    Abraço.

    ResponderExcluir
  6. Fala Alexandre! Como eu disse, eu gosto do .Net framework e do C#, mas não vejo diferença entre programar em C# e programar em Prism. Prefiro o C# já que o prism não oferece um ganho muito grande em termos de curva de aprendizado ou velocidade de desenvolvimento. O prism seria uma ótima ferramenta se fosse de graça, essa que é a verdade.

    ResponderExcluir
  7. Só tem um detalhe... Não tem como Delphi Prism ser GPL, porque a Embarcadero trabalha com softwares comerciais e pagos e ninguém está interessado em desenvolver programa gratuito e fornecer seus fontes! Entrariam todos os desenvolvedores na questão de pagar para não ter que fornecer seus projetos de graça, daria no mesmo! De resto, vou ver o Prism... Acredito que você esteja correto, mas preciso ver com meus próprios olhos pra chegar aqui e dizer que concordo ou não. Vou ver antes e analisar tudo o que você postou, mas já adianto que foi ótimo ler teu post aqui no teu blog. Já vou vendo e observando o que tu falou!

    Abraço!!!

    ResponderExcluir
    Respostas
    1. Alex, na verdade eu não critiquei o Prism por não ser GPL, eu disse que existem soluções GPL melhores.
      Entenda, eu aceito pagar por algo que eu poderia obter de graça contanto que esse "algo" seja muito melhor, tenha algum diferencial.
      Você se engana quando coloca o Prism debaixo do guarda-chuva da Embarcadero. O Prism nunca foi da Embarcadero, ele pertence a Rem Objects, que tinha um contrato com a Embarcadero até esse ano, mas esse contrato já expirou e as duas empresas vão seguir seus caminhos.
      O último Delphi Prism foi a versão XE3, se não me engano, mas o Rad Studio XE4 não virá com o Prism, como diz o Andreano Lanusse e o próprio pessoal da Rem Objects.
      O Prism foi descontinuado na Embarcadero, mas continuará a evoluir na Rem Objects sob o nome de Oxygene (seu verdadeiro nome).
      http://www.andreanolanusse.com/pt/delphi-xe4-conheca-as-novidades-para-ios-e-mais/
      http://blogs.remobjects.com/blogs/mh/2013/04/17/p5822
      http://www.itwriting.com/blog/7338-no-more-delphi-for-net-prism-removed-from-rad-studio-xe4.html

      A partir desse momento a Embarcadero e a RemObjects não são mais parceiras, mas sim concorrentes, mas acredito que o Prism agora irá evoluir, implantando melhorias que não poderia antes devido às políticas da Embarcadero.
      Sobre o velho assunto da "Morte do Delphi", eu acredito que o Delphi não irá morrer nunca, assim como o Cobol e o Clipper, mas está fadado à essa letargia: crescimento lerdo e muitas vezes na contra-mão. Todas as melhorias do Rad Studio 4 são tardias em comparação com outros ambientes, além de serem fortemente dependentes de aplicações / módulos de terceiros.

      Excluir
  8. Obrigado pelo esclarecimento (y)
    Considerando um servidor DataSnap REST (Delphi XE3 ) qual será a melhor maneira de consumir os métodos desse servidor numa aplicação Windows Mobile 5.0 ( c# VS2008 ) ?
    ( há os DataSnap Mobile connectores, mas apenas para windows phone... ).
    Obrigado ;)

    ResponderExcluir
  9. Se é uma aplicação REST então significa que é um webservie, e como tal ele tem um http server que responde a uma requisição http.
    Não sei como você programa para o windows mobile 5.0, mas em qualquer linguagem que você tenha um objeto tipo httpRequest. Você tem algo parecido no Delphi, no C++ e no C#. Terá de fazer as coisas meio que "no dedo".

    Se o prism tem alguma coisa que te facilite muito nisso, recomendo continuar a usar o prism, porque seu ambiente é meio específico. Mas mesmo assim eu recomendo você a fazer sem a biblioteca, como preparação para o futuro.

    ResponderExcluir

Postar um comentário

Postagens mais visitadas deste blog

Uso de memória no SQL Server

Busca de CEP com o Lazarus - Parte 1 - UrlEncode

Botão Add This para adicionar seu post em qualquer rede