los Términos implícitos y explícitos tardan en acostumbrarse cuando los escucha por primera vez. Cuando los escuchas en términos de programación, ¿qué significa eso exactamente para ti? ¿Es una manera mejor que otra? Aquí repasaremos cada una de estas ideas y proporcionaremos ejemplos con algunos beneficios de patrones de diseño que pueden provenir de ellos.
los Términos
en programación, implicit se usan a menudo para referirse a algo que otro código hace por ti detrás de escena., Explícito es el enfoque manual para lograr el cambio que desea tener escribiendo las instrucciones que se deben hacer explícitamente. En la imagen más pequeña, implícito y explícito son a menudo los términos utilizados para los tipos de fundición en el tipo que tendría que ser. En el cuadro más grande, usted puede estar hablando de Convención sobre la configuración donde convención es lo que se hace implícitamente por usted por una base de código o marco de trabajo y la configuración es simplemente ajustes explícitos.,
también hay diferencias de adecuación o beneficio para cualquier uso dependiendo del lenguaje de programación en cuestión y si el lenguaje está tipeado estáticamente o dinámicamente. También depende de si las cosas se pueden inferir de un tiempo de ejecución o durante la compilación. Debido a estos factores, hacer una afirmación de que una metodología es mejor que otra solo puede ser cierto dentro de contextos estrechos, ya que hay que tener en cuenta el diseño de los lenguajes de programación y programas en cuestión.,
Un ejemplo de implícitos y explícitos de conversión de tipos en C es la siguiente:
int implicit;implicit = 4.5;int explicit;explicit = (int)4.5;
Aquí los nombres de variable implicit y explicit se define como de tipo int. Una vez dado un valor 4.5 la versión implícita hace que el compilador convierta lo que normalmente sería un tipo flotante o doble a un entero, mientras que la versión explícita lo ha convertido explícitamente a un entero con el uso de (int) siendo lo que castea el tipo.,
lenguajes de tipo estático
en lenguajes de tipo estático como Rust, una gran mayoría de la creación y asignación de valor tendrá requisitos explícitos de anotación de tipo con una excepción para donde el compilador pueda inferir el tipo. El siguiente es un ejemplo que muestra tipos explícitos e implícitos en Rust.
fn add_one(input: u8) -> u8 { input + 1}let four = add_one(3);
Aquí el método de add_one es explícita sobre el tipo de entrada y el tipo de salida., El número 1 que se agrega aquí se convierte implícitamente en un número u8 en el momento de la compilación, ya que el contexto ayuda a inferir el tipo y la adición de u8 solo se implementa para trabajar con números u8. La última línea se escribe implícitamente como u8 ya que el método en sí define el tipo que se devolverá.
lo que se puede inferir en Rust es bastante impresionante con el uso de genéricos. Pero el uso de la inferencia se limita a cosas que se pueden conocer en tiempo de compilación., Si no se puede conocer en tiempo de compilación, debe definir explícitamente el tipo en cualquier punto de asignación. Tomar la siguiente definición de método:
use std::ops::Add;fn add_both<T: Add>(a: T, b: T) -> T::Output { a + b}
Aquí T puede ser cualquier tipo que implementa el rasgo Add. El tipo T::Output se define cuando el atributo Add se define para su tipo específico y generalmente es el mismo tipo que T en este caso. Ahora si proporcionamos dos números como parámetros el compilador inferirá el tipo a él.,
let x = add_both(3 , 4 ); // implicit typelet y: u8 = add_both(3u8 , 4u8 ); // explicit typelet z: u32 = add_both(3u32, 4u32); // explicit type
Cuando ejecuto el código de arriba x se infiere que el tipo i32. Los ejemplos y y z requieren que se conozcan los tipos de parámetros de entrada cuando se proporcionan a la función, ya que la inferencia para T::Output no es necesariamente lo mismo que lo que T puede inferirse como. Se tendría el valor predeterminado i32 y, a continuación, asignar un i32 como u8 o u32 es simplemente incorrecto.,
lenguajes dinámicamente tipeados
ahora con lenguajes dinámicamente tipeados, tiene que preocuparse menos por los tipos, per se, y más por los objetos implícitos o explícitos o el comportamiento. Modelar código alrededor de objetos que tienen el mismo comportamiento es lo que se conoce como duck typing, que es un dominio superior del pensamiento en la programación orientada a objetos donde el manejo de esos objetos está implícito. Mientras que modelar el código alrededor de clases de objetos específicas es muy parecido a usar tipado explícito o implícito., Pero cuando acepta cualquier tipo de objeto como entrada, entonces el código en esa sección debe manejar diferentes objetos explícitamente o entregar esa responsabilidad en otro lugar.
para una aclaración, cuando escribes código para manejar diferentes tipos de cosas, entonces escribes código explícito. Sin embargo, cuando este mismo código ya ha sido escrito y lo está reutilizando con una simple llamada al método, entonces el comportamiento en este nuevo contexto es implícito. Implícitamente son cosas hechas como si fueran automáticas y manejadas fuera de su alcance actual.,
en Ruby, la mayoría de los tipos tienen un diseño para conversión explícita o implícita. La idea es que los métodos de conversión implícitos están destinados a ser utilizados en contextos implícitos y las conversiones explícitas están destinadas a que los desarrolladores escriban en línea en muchos más contextos. Permítanme demostrarlo con el ejemplo.
# explicit"4".to_i + "5".to_i# => 9# implicitclass Seven def to_int 7 endendArray.new(Seven.new)# =>
Aquí el ejemplo explícito hace muy obvio para el lector que estamos convirtiendo Stringobjetos a un objeto Integer y realizando la adición entre los dos., Y el ejemplo implícito no es tan obvio para el lector ya que el método Array.new llama implícitamente al método to_int en cualquier parámetro que se le dé. La clase Integer tiene el método to_int definido en cada instancia de la misma que simplemente devuelve self. Si usted escribe 42.to_int simplemente volver 42. Este uso de usar la conversión implícita como un protector de entrada para llamadas a métodos es un gran diseño para la seguridad de tipos por diseño. Esto es lo que sucede si le das el tipo incorrecto de objeto como entrada que no define to_int.,
Array.new("32")# TypeError (no implicit conversion of String into Integer)
no solo falla, sino que nos da un mensaje útil de que se intentó una conversión implícita y nos dice la clase de objeto dada y la clase de objeto que espera. Los métodos de conversión implícitos en Ruby son una forma de decir que este objeto es realmente lo que esperas. Y la conversión explícita es simplemente hacer la conversión al tipo esperado.
Ruby tiene opciones implícitas y explícitas para muchos de sus objetos principales.,
Ruby también tiene algunas clases con métodos de clase que harán una conversión implícita o devolverán nil y ese nombre de método es try_convert.
podemos seguir el ejemplo de Ruby con Array.new y tener una buena guardia para el tipo de parámetros de entrada que se nos da al diseñar conversiones implícitas para nuestros propios tipos personalizados. Para este ejemplo, dado que to_fes una conversión explícita a un número flotante en Ruby, usaremos as_como prefijo en lugar de to_., Aquí hay un ejemplo básico de implicitud como patrón de seguridad.
ahora esto ayudará a otros desarrolladores que usan la clase Bar a no pasarla como un parámetro incompatible. Sigue una convención dentro del lenguaje Ruby y debería ser mucho más fácil de entender para los desarrolladores con errores más útiles. Cuando tenga otros objetos que desee convertir en un objeto Foo, puede definir un método as_f para una conversión explícita y el desarrollador que use ese nuevo objeto será explícito en su uso Bar.new(Baz.new.as_f)., Esto asegura que el código funcionará tanto como Bar y Foo ya están funcionando.
resumen
el acto de codificación implícita y explícita, y código implícito y explícito, se define por el contexto de ejecución de comportamiento adicional o configuración de tipo / fundición. Específicamente, los métodos implícitos o explícitos se definen por los contextos en los que están destinados a ser utilizados. El código implícito puede ser una experiencia muy agradable si las cosas están bien nombradas, ya que mantiene las cosas simples.,
sin embargo, el código implícito, el código haciendo cosas detrás de escena para usted, también puede ser un problema difícil de resolver cuando se hace mal. El código explícito hace que el código sea claro cuando lo miras, ya que los detalles de lo que se está haciendo ya están expuestos ante ti y no tienes que rastrear problemas en otros lugares, pero generalmente significa mucho más trabajo escribiéndolo. Por sí solo puede llegar a ser abrumador, por lo que encontrar un equilibrio adecuado entre los dos es a menudo la mejor solución. Sea explícito cuando debe, e implícito cuando los conceptos de diseño y nomenclatura son fáciles de entender., Esto hará que la experiencia de desarrollo sea más conveniente.