os termos implícitos e explícitos levam algum tempo a habituar-se quando os ouve pela primeira vez. Quando os ouves em termos de programação, o que significa isso para ti? Uma coisa é melhor do que outra? Aqui vamos rever cada uma dessas ideias e fornecer exemplos com alguns benefícios padrão de design que podem vir deles.
os Termos
na programação, implícito é muitas vezes usado para se referir a algo que é feito para você por outro código nos bastidores., Explícito é a abordagem manual para realizar a mudança que você deseja ter, escrevendo as instruções a serem feitas explicitamente. Na imagem menor, implícitos e explícitos são muitas vezes termos usados para os tipos de vazamento para o tipo que você teria que ser. Na imagem maior, você pode estar falando sobre Convenção sobre configuração onde convenção é o que é implicitamente feito para você por uma base de código ou framework e configuração é simplesmente configurações explícitas.,
Existem também diferenças de adequação ou benefício para o uso dependendo da linguagem de programação em questão e se a linguagem é estaticamente tipada ou dinamicamente tipada. Também depende se as coisas podem ser inferidas a partir de um tempo de execução ou durante a compilação. Por causa destes fatores, fazer uma alegação de que uma metodologia é melhor do que outra só pode ser verdade dentro de contextos estreitos como você tem que levar em consideração o design para linguagens de programação e programas em questão.,
Um exemplo de implícito e explícito tipo de carcaça em C é o seguinte:
int implicit;implicit = 4.5;int explicit;explicit = (int)4.5;
Aqui os nomes de variável implicit e explicit foram definidos para ser do tipo int. Uma vez dado um valor 4.5 a versão implícita tem o compilador converter o que seria normalmente um float ou tipo duplo para um inteiro, enquanto que a versão explícita o lançou explicitamente para um inteiro com o uso de (int) sendo o que lança o tipo.,
línguas de tipo estático
em línguas de tipo estático, tais como ferrugem, uma grande maioria da criação de valor e atribuição terá requisitos explícitos de anotação de tipo, com uma exceção para onde o compilador pode inferir o tipo. O seguinte é um exemplo mostrando tipos explícitos e implícitos em ferrugem.
fn add_one(input: u8) -> u8 { input + 1}let four = add_one(3);
Aqui o método add_one é explícito sobre o tipo de entrada e tipo de saída., O número de 1 ser adicionado aqui é feito implicitamente uma u8 número de tempo de compilação como o contexto ajuda a inferir o tipo e a adição de u8 só é implementada para trabalhar com u8 números. A última linha é implicitamente digitada para ser um u8 uma vez que o método em si define o tipo que será devolvido.
O que pode ser inferido na Ferrugem é bastante impressionante com o uso de genéricos. Mas o uso de inferência é limitado a coisas que podem ser conhecidas no tempo de compilação., Se não puder ser conhecido no tempo de compilação, então você deve definir explicitamente o tipo em qualquer ponto de atribuição. Tome o seguinte método de definição:
use std::ops::Add;fn add_both<T: Add>(a: T, b: T) -> T::Output { a + b}
Aqui T pode ser qualquer tipo que implementa o traço Add. T::Output tipo é definido quando o Suplemento traço é definido para o seu tipo específico, e geralmente é o mesmo tipo T si, neste caso. Agora, se nós fornecermos dois números como parâmetros o compilador irá inferir o tipo para ele.,
let x = add_both(3 , 4 ); // implicit typelet y: u8 = add_both(3u8 , 4u8 ); // explicit typelet z: u32 = add_both(3u32, 4u32); // explicit type
Ao executar o código acima x é inferida a ser o tipo de i32. y e z exemplos requerem a introdução tipos de parâmetro para ser conhecido quando fornecido para a função como a de inferência para T::Output não é necessariamente o mesmo que T pode ser inferida como. Ele seria padrão para i32 e, em seguida, atribuir um i32 u8 ou u32 é simplesmente errado.,
línguas dinamicamente tipadas
Agora com linguagens dinamicamente tipadas, você tem que se preocupar menos com tipos, por si só, e mais sobre objetos implícitos ou explícitos ou comportamento. Modelagem de código em torno de objetos que têm o mesmo comportamento é o que é conhecido como datilografia de pato, que é um domínio maior de pensamento em programação orientada a objetos, onde lidar com esses objetos é implícito. Enquanto Modelagem do código em torno de classes de objetos específicos é muito parecido com o uso de escrita explícita ou implícita., Mas quando você aceita qualquer tipo de objeto como entrada, então o código nessa seção deve lidar com diferentes objetos explicitamente ou entregar essa responsabilidade em outro lugar.
para clarificação, quando você está escrevendo código para lidar com diferentes tipos de coisas, então você está escrevendo código explícito. No entanto, quando este mesmo código já foi escrito e você está reutilizando-o com uma simples chamada de método, então o comportamento neste novo contexto é então implícito. Ser implícito coisas feitas como se automaticamente e tratadas fora do seu escopo atual.,
em Ruby, a maioria dos tipos tem um design para conversão explícita ou implícita. A ideia é que os métodos de conversão implícitos são usados em contextos implícitos e as conversões explícitas são feitas para que os desenvolvedores escrevam em linha em muito mais contextos. Permitam-me que o demonstre por exemplo.
# explicit"4".to_i + "5".to_i# => 9# implicitclass Seven def to_int 7 endendArray.new(Seven.new)# =>
Aqui o exemplo explícito torna muito óbvio para o leitor que estamos convertendo String objetos para uma Integer objeto e a execução de adição entre os dois., E o exemplo implícito não é tão óbvio para o leitor como o método Array.new implicitamente chama o método to_int em qualquer parâmetro que é dado. A classe inteira tem o método to_int definido em cada instância dela que simplesmente retornam a si mesma. Se você escrever 42.to_int você simplesmente obter de volta 42. Este uso de usar a conversão implícita como uma guarda de entrada para chamadas de método é um grande projeto para a segurança do tipo por projeto. Aqui está o que acontece se você lhe der o tipo errado de objeto como entrada que não define to_int.,
Array.new("32")# TypeError (no implicit conversion of String into Integer)
não só falha como nos dá uma mensagem útil de que uma conversão implícita foi tentada e diz a classe do objecto dado e a classe do objecto que espera. Métodos de conversão implícitos em Ruby é uma maneira de dizer que este objeto realmente é o que você está esperando. E conversão explícita é simplesmente fazer a conversão para o tipo esperado.
Ruby tem opções implícitas e explícitas para muitos de seus objetos principais.,
Ruby também tem algumas classes com métodos de classe que irão fazer uma conversão implícita ou retornar zero e que o nome do método é try_convert.
Podemos seguir o exemplo de Ruby com Array.new e ter uma boa guarda para o tipo de Parâmetros de entrada que nos são dados ao projetar conversões implícitas para os nossos próprios tipos personalizados. For this example, since to_f is an explicit conversion to a Float number in Ruby we’ll use as_ as a prefix instead of to_., Aqui está um exemplo básico de implicação como um padrão de segurança.
agora Isto irá ajudar outros desenvolvedores que usam a classe Bar a não passá-la como um parâmetro incompatível. Ele segue uma convenção dentro da linguagem Ruby e deve ser muito mais fácil para os desenvolvedores de entender com erros mais úteis. Quando você tem outros objetos que você gostaria de converter-se em um objeto Foo, em seguida, você pode definir um as_f método para uma conversão explícita e o desenvolvedor que utiliza esse novo objeto vai ser explícito em seu uso Bar.new(Baz.new.as_f)., Isto garante que o código irá funcionar tanto quanto Bar e Foo já estão a funcionar.
resumo
o ato de codificação implícita e explícita, e Código implícito e Explícito, é definido pelo contexto de execução de comportamento adicional ou definição de tipo/vazamento. Especificamente, métodos implícitos ou explícitos são definidos pelos contextos em que se destinam a ser usados. Código implícito pode ser uma experiência muito agradável se as coisas são bem nomeadas como ele mantém as coisas simples.,
no entanto, código implícito, fazer coisas nos bastidores para você, também pode ser um problema difícil de resolver quando feito errado. Código explícito torna o código claro quando você olha para ele como as especificações do que está sendo feito já está estabelecido antes de você e você não tem que rastrear questões em outro lugar, mas geralmente significa muito mais trabalho Escrevendo-o. Por si só, pode tornar-se esmagadora, de modo que encontrar um equilíbrio adequado entre os dois é muitas vezes a melhor solução. Seja explícito quando você deve, e implícito quando os conceitos de design e nomeação são fáceis de entender., Será uma experiência de desenvolvimento mais conveniente.