Comecei a aprender Java EE 7 e frequentemente encontro esse termo "padrão" e não entendo o que isso significa.
Então, por exemplo, aqui está uma citação deste livro:
Ao contrário do SOAP e da pilha WS- *, que dependem dos padrões W3C, o REST não possui padrão e é apenas um estilo de arquitetura com princípios de design. Os aplicativos REST dependem muito de muitos outros padrões: HTTP, URI, URL ...
Eu tenho uma idéia do que isso pode significar, mas não tenho certeza.
A melhor explicação que me deparei é a definição daqui .
coding-standards
standards
Djole Pi
fonte
fonte
Respostas:
O termo "padrões" na programação geralmente se refere a uma tecnologia / documento que é governado por um grupo ou comunidade. Os membros desse grupo geralmente compartilham objetivos comuns, são usuários ativos dessa tecnologia e desejam garantir que a tecnologia continue.
Existem muitas "coisas" na programação que têm uma comunidade que as governa. Esses membros podem variar de programadores a representação corporativa (por exemplo, Apple, Microsoft, IBM, etc. etc.)
O W3C é um grupo muito grande que trabalha em conjunto para definir muitos padrões.
Aqui está uma lista de membros.
http://www.w3.org/Consortium/Member/List
O REST é um exemplo de tecnologia, por sua popularidade é usado por muitas pessoas, mas não há grupo ou comunidade que o governe. Portanto, não há um lugar para apontar o dedo e dizer "é assim que os padrões dizem que isso deve ser feito" .
Empresas como IBM, Microsoft e outras pessoas publicaram documentação de como implementar o REST. Pode-se dizer que existe uma "maneira comum" de implementar o REST. Você pode escolher uma fonte autorizada que descreva uma implementação do REST e reivindicar seguir essa referência. O uso de fontes autorizadas é uma maneira de lidar com os problemas de compatibilidade nos navegadores da web.
fonte
Um padrão é um documento técnico que especifica como uma tecnologia se comporta. (Para algumas tecnologias, pode ser algum outro tipo de padrão técnico .) Isso é tudo o que são e por que eles existem: são documentos, e eles descrevem a tecnologia.
Esses documentos são de autoria de um corpo diretivo que possui a autoridade e a confiança necessárias para que eles possam decidir como essa tecnologia funciona e para que as pessoas se importem quando lançam um documento de especificação como padrão. Um corpo diretivo pode produzir muitos padrões, para diferentes tecnologias ou diferentes versões de uma tecnologia. O corpo diretivo também pode ser conhecido como mantenedores, autores, guardiões, etc. das normas.
(Ao contrário do que Mathew descreve, um padrão não é o órgão de governo nem a própria tecnologia. É um documento que descreve a tecnologia, ou uma versão específica dela.)
Alguns exemplos de padrões para as tecnologias que você mencionou (e outros):
O HTML é um bom exemplo do fato de que versões diferentes de uma linguagem geralmente têm padrões diferentes. As várias versões têm documentos diferentes que descrevem como as várias versões do idioma devem ser tratadas.
Enquanto isso, o HTTP é um dos muitos exemplos de um movimento padrão entre grupos: primeiro pelo Grupo de Trabalho em Rede, depois para o Grupo de Trabalho HTTP, embora ambos os grupos fizessem parte da IETF. Outras tecnologias foram movidas entre empresas, como HTML (novamente), versão 2 da qual foi criada pelo IETF no RFC1866 .
Por que existem padrões?
Eles existem para nos dar uma garantia de como as coisas vão funcionar.
A especificação HTML5 me diz como os vários navegadores manipularão e exibirão a marcação HTML5 que eu escrevo, assumindo que eles implementem o padrão corretamente (o que historicamente tem sido um problema). O padrão C ++ 11 me dirá coisas sobre o que vários códigos C ++ 11 que eu escrevo farão ou não farão.
Da mesma forma, se eu estiver escrevendo um navegador, o padrão HTML5 me dirá como preciso lidar com várias partes da marcação HTML5 para que as pessoas obtenham o que esperam. Se eu estiver escrevendo um compilador C ++ 11, o padrão C ++ 11 me dirá o que preciso fazer para implementar a linguagem corretamente e fazer com que o código das pessoas funcione da maneira que eles esperam.
Por exemplo, os autores da Microsoft C #. Você pode baixar a especificação de idioma C # 5.0 para si mesmo. Este documento é uma promessa de que o código C # que você escreve deve se comportar da maneira como é descrito na especificação, em qualquer compilador que realmente implemente a especificação corretamente.
( Se você fizer coisas fora da especificação , estará em um território indefinido e não há garantia alguma sobre o que acontecerá ou não.)
Historicamente, os padrões remontam a roscas de rosca , para que eu possa ter alguma garantia de que, se eu pedir um parafuso do tipo X, ele se encaixará no orifício que fiz e será intercambiável com outros parafusos do tipo X.
O que nos leva de volta à definição da palavra "padrão" :
ou seja, a coisa com a qual você compara suas coisas, para garantir o que espera.
fonte
Um padrão de tecnologia é uma especificação de tal forma que se espera que duas implementações do mesmo padrão sejam interoperáveis ou intercambiáveis. Exemplos: USB, Bluetooth, Java EE7, HTTP.
Depois, existem padrões "de fato": convenções que permitem a interoperabilidade, mas sem uma especificação explícita e acordada. Exemplo: O formato Microsoft DOC tem sido historicamente um padrão de fato, pois muitos produtos podiam ler e escrever DOC, mas as especificações canônicas não estavam disponíveis (até muito mais tarde). Os documentos ainda eram comumente distribuídos no formato DOC, com a expectativa de que qualquer receptor pudesse lê-lo, tornando-se um padrão de fato.
Para abordar seu exemplo específico, o REST não possui uma especificação acordada explícita e, portanto, não é um padrão verdadeiro e apenas um padrão de fato, pois possui uma ambiguidade considerável de como deve ser feito corretamente e não existem implementações dominantes que resolve essas ambiguidades. (Eu não sou contra o REST. É uma maneira muito boa de criar serviços da web)
fonte
Um padrão é uma convenção padronizada - por uma especificação formal ou simplesmente porque uma convenção comum ganhou popularidade suficiente para ser dominante.
A
de jure standardé uma especificação publicada por um comitê padrão. Alguns comitês padrão são ISO, ECMA, DIN, ANSI e W3C.Alguns exemplos
de jure standardssão o tamanho do papel A4 (padrão ISO 219), o idioma c # (ECMA-334) etc.O termo 'de jure' raramente é usado, e um 'padrão de jure' é frequentemente chamado de padrão.
(fonte: wikipedia - Eu não poderia escrever melhor)
Um padrão de fato não segue necessariamente nenhuma especificação formal.
Como Gudmundur Orn escreveu nesta resposta , o formato DOC do Microsoft Office era um padrão de fato. Tinha uma posição dominante e normalmente se supunha que as pessoas podiam ler documentos do MS Word.
JSON é um animal engraçado, pois começou como um padrão de fato. No entanto, desde que foi formalizado como ECMA-404 , agora é um "padrão de jure".
No entanto, é também o formato predominante para a troca de dados com APIs baseadas em HTTP (que eu saiba), tornando-o também o 'padrão de fato' desse objetivo.
fonte
Para responsabilidade legal do produto, o defeito é classificado como design, fabricação ou documentação. Um projeto não está com defeito se for baseado em um padrão, independentemente de esse padrão estar ou não. O padrão que se aplica é aquele em vigor quando o produto foi criado. Um padrão pode ser um padrão publicado (ISO) ou um padrão aceito do setor que não seja publicado pela associação de padrões. Portanto, o TCP / IP com todos os seus defeitos inerentes, como a falsificação, é um padrão; se você criar uma nova tecnologia como VOIP e não fizer nada para proteger o usuário de problemas conhecidos com a tecnologia subjacente, estará seguro para continuar o caos. Ou posso estar errado e ter um defeito de documentação aqui ...
fonte