Translate

sábado, 1 de agosto de 2020

Piratería y desarrollo: discursos, historias y política de un amor negado

Cuando vi este video pensé en situaciones que suceden en el mundo del software y en general en todas las industrias. 

Me paso en el blog que por algunos comentarios gente me acusaba de utilizar por ejemplo imágenes que tenían copyright, y en realidad esas imágenes no agregaban mayor valor al post en sí, sino que eran decorativas. Copyright tiene libros enteros de los que los apoyan y los que lo condenan, pero por ejemplo con las imágenes que les contaba, mucha gente podría conocer esas imagenes a partir de un post que nada que ver. Y la rueda puede seguir rodando... En general pienso que es más lo que se pierde de lo que se gana, en fin les dejo el video : 


Contador de palabras ...


Me gustaría hacer un conjunto de post de contadores de palabras, en diferentes tecnologías. Ya se lo que piensan : 

String[] palabras = getPalabras()
int contador = 0
for (String p : palabras) contador++
return contador

o los que piensan de forma más funcional : 

String[] palabras = getPalabras()
int contador = palabras.fold(0, (c, a) => c++)

Pero la idea de esta actividad es hacerla en paralelo, por ejemplo utilizar 3 hilos. y contar el 1/3 en un hilo, y así...

Empiezo mi tarea haciendo un github : https://github.com/emanuelpeg/contador

Por algo se empieza, quien me ayuda??  

Conectarse a un servidor FTP con Python


Para conectarse a un servidor FTP desde Pythos debemos utilizar el módulo ftplib y la clase FTP (que original). 

El constructor de FTP, recibe como parámetros al host, usuario, clave. A la vez, esta librería nos provee un monton de funcionalidad, veamos un ejemplo : 


from ftplib import FTP
ftp = FTP()
ftp.connect('0.0.0.1', 21, -999)
ftp.login('user', 'pass')
print ftp.getwelcome()
ftp.mkd('nuevo-dir')
ftp.cwd('nuevo-dir')
print ftp.pwd()
ftp.storlines('STOR example.txt', open('ftp_examples.py', 'r'))
ftp.rename('example.txt', 'example.py')
ftp.dir()
archivo = ftp.retrlines('RETR example.py')
print archivo
ftp.close()

Y listo!! 

miércoles, 29 de julio de 2020

The RedMonk Programming Language Rankings: June 2020

Media tarde la noticia, estamos a fines de Julio :S

Pero bueno, no quería dejar pasar este gráfico sobre los lenguajes más utilizados. Al parecer Python toma la delantera pero javasctipt sigue adelante. 

En fin, hay varios rankings y algunos dan a ganador a Java o a Python o Javascript. Que se yo? Den su opinión!!  

martes, 28 de julio de 2020

viernes, 24 de julio de 2020

Enviando e-mails desde Python

Para poder enviar e-mail desde un servidor (u ordenador local), en primer lugar, es necesario contar con un MTA (Mail Transpor Agent o “Agente de transporte de correo”). Uno de los MTA más populares para sistemas linux, es sendmail. Por lo tanto debemos instalarlo:

sudo apt-get install sendmail

Para enviar e-mails desde Python, éste nos provee smtplib, otro módulo de la librería estándar de Python, quien nos permitirá enviar mensajes de correo electrónico, incluso, en formato HTML.

Solo necesitaremos:
  • Crear un objeto smtplib.SMTP el cuál recibirá como parámetro de su método constructor, el host (localhost)
  • Crear un mensaje de correo: Enviar el mensaje mediante una llamada al método sendmail del objeto SMTP.
Veamos el código : 


import smtplib

remitente = "ElmachodelPirulin <emanuel@blog.com.ar>"
destinatario = "Ella <ella@gmail.com>"
asunto = "E-mail enviado desde Python"
mensaje = """Hola!<br/> <br/>
Este es un <b>e-mail</b> enviando desde <b>Python</b>
"""
email = """From: %s
To: %s
MIME-Version: 1.0
Content-type: text/html
Subject: %s
%s""" % (remitente, destinatario, asunto, mensaje)
try:
  smtp = smtplib.SMTP('localhost')
  smtp.sendmail(remitente, destinatario, email)
  print "Correo enviado"
except:
  print """Error: el mensaje no pudo enviarse.
  Compruebe que sendmail se encuentra instalado en su sistema"""

Así de simple, enviamos un e-mail con Python!

Conceptos que debemos tener claros cuando hablamos de lenguajes informáticos...

Cuando se habla de lenguajes no se tiene bien en claro muchos conceptos, por eso voy a tratar de dejar algo de luz aquí : 

Lenguaje informático: es un lenguaje artificial, utilizado por ordenadores y personas para comunicarse. Los lenguajes informáticos, pueden clasificarse en: 
  • lenguajes de programación (Python, PHP, Pearl, C, etc.); b) 
  • lenguajes de especificación (UML)
  • lenguajes de consulta (SQL)
  • lenguajes de marcas (HTML, XML)
  • lenguajes de transformación (XSLT)
  • protocolos de comunicaciones (HTTP, FTP)
  • entre otros... 

Lenguaje de programación: es un lenguaje informático, diseñado para expresar órdenes e instrucciones precisas, que deben ser llevadas a cabo por una computadora. El mismo puede utilizarse para crear programas que controlen el comportamiento físico o lógico de un ordenador. Está compuesto por una serie de símbolos, reglas sintácticas y semánticas que definen la estructura del lenguaje.

Lenguajes de alto nivel: son aquellos cuya característica principal, consiste en una estructura sintáctica y semántica legible, acorde a las capacidades cognitivas humanas. A diferencia de los lenguajes de bajo nivel, son independientes de la arquitectura del hardware, motivo por el cual, asumen mayor portabilidad y son mucho más abstractos. Se acercan al humano y se alejan de la maquina. 

Lenguajes interpretados: a diferencia de los compilados, no requieren de un compilador para ser ejecutados sino de un intérprete. Un intérprete, actúa de manera casi idéntica a un compilador, con la salvedad de que ejecuta el programa directamente, sin necesidad de generar previamente un ejecutable. Ejemplo de lenguajes de programación interpretado son Python, PHP, Ruby, Lisp, entre otros.

Tipado dinámico: un lenguaje de tipado dinámico es aquel cuyas variables, no requieren ser definidas asignando su tipo de datos, sino que éste, se auto-asigna en tiempo de ejecución, según el valor declarado.

Multiplataforma: significa que puede ser interpretado en diversos Sistemas Operativos como GNU/Linux, Windows, Mac OS, Solaris, entre otros.

Multiparadigma: acepta diferentes paradigmas (técnicas) de programación, tales como la orientación a objetos, aspectos, la programación imperativa y funcional.

Código fuente: es un conjunto de instrucciones y órdenes lógicas, compuestos de algoritmos que se encuentran escritos en un determinado lenguaje de programación, las cuales deben ser interpretadas o compiladas, para permitir la ejecución del programa informático.

Como sería una base de datos reactiva??


Antes que nada voy a aclarara que este post tiene como objetivo solo hacer un ejercicio mental, no tiene como objetivo proponer un estándar o sugerir un cambio. Solo vamos a utilizar la imaginación y disfrutar…

Otra cosa, se que existe RDBC que básicamente ofrece un conjunto de funcionalidades reactivas para utilizar base de datos relacionales y esta bien, pero pero tiene sabor a poco. Dado que este conector tiene como objetivo simular un origen de datos reactivo que en realidad no es tan así …

En fin, una base de datos reactiva debería cumplir el manifiesto reactivo :
  • Responsivos
  • Resilientes
  • Elásticos
  • Orientados a Mensajes
No quiero detallar como implementar estos puntos, existen muchas bases de datos nosql que intentan implementarlo y a su modo lo hacen muy bien.

Dado los siguientes puntos y supongamos que los cumpla. Una base reactiva debería retornar siempre un Observer (si utilizamos RxJava, o puede ser un Flux o Mono si utilizamos spring) , por ahora no estoy agregando nada de conocimento esto es igual que R2DBC, vamos a soñar …

Lo que podríamos hacer es trasmitir datos por ejemplo : 

Preparestatement ps = con.createPreparestatement(“select * from Persona”); 
ps.subscribe( rs => System.out.println(rs.getString(“name”); ); 
  
Cada vez que se inserte un registro nuevo se imprimirá el nombre.

Le podríamos poner un delay, por ejemplo :

Preparestatement ps = con.createPreparestatement(“select * from Persona”); 
ps.delay(100);
ps.subscribe( rs => System.out.println(rs.getString(“name”); );

Si tuviéramos que hacer esto, de forma tradicional, deberíamos, revisar la base de datos cada tanto tiempo para ver si insertaron un dato nuevo. En cambio, si hubiera una base reactiva, la base nos retornará  cada 100 nanosegundos el nombre de una persona y esto no debería ser bloqueante, es decir si mientras imprimimos alguien cambia algo, no debería influir en nuestro proceso. Y si llega al final, cada vez que se inserte debería notificarnos. 

Otra cosa muy buena, sería poder suscribir a un cambio (esto desplazaría a los triggers). Deberíamos poder suscribir al cambio de un registro o de todos los registros de una tabla o la estructura de una tabla o etc. Por ejemplo vamos a suscribir un proceso que se llame cuanto eliminen un registro : 

Preparestatement ps = con.createPreparestatement(“select * from Persona p where p.id = 33”); 
ps.subscribe(“delete”, rs => System.out.println(rs.getString(“name”); );

ponele, me estoy suscribiendo y cuando se borre esta fila, la base de datos debería, notificarnos. 
Como se deben haber dado cuenta una base de datos reactiva no solo es un repositorio donde consulto datos, sino que es un sistema el cual conversa con nuestra aplicación y nos notifica de los cambios. Esto favorecería increíblemente las comunicaciones, supongamos que tenemos 2 sistemas que escriben en una base de datos, según lo que venimos razonando podríamos suscribirnos a la inserción de nuevos datos. Ect...

En fin, no conozco nada parecido, alguien conoce algo similar??

Dejo link: 

martes, 21 de julio de 2020

ReactiveX parte 2


Continuando con el post anterior...

En el modelo ReactiveX, Observable le permite tratar flujos de eventos asincrónicos con el mismo tipo de operaciones simples y componibles que se utilizan para colecciones. Lo libera de redes enredadas de devoluciones de llamada (como los callbacks) y, por lo tanto, hace un código sea más legible y menos propenso a errores.

Las técnicas como Java Futures son fáciles de usar para un solo nivel de ejecución asincrónica, pero comienzan a agregar una complejidad no trivial cuando están anidadas.

Es difícil usar Futures para componer de manera óptima flujos de ejecución asincrónicos condicionales (o imposible, ya que las latencias de cada solicitud varían en tiempo de ejecución). Esto se puede hacer, por supuesto, pero rápidamente se vuelve complicado (y por lo tanto propenso a errores) o se bloquea prematuramente en Future.get (), lo que elimina el beneficio de la ejecución asincrónica.

Los Observables de ReactiveX, están destinados a componer flujos y secuencias de datos asincrónicos.

ReactiveX Observables admite no solo la emisión de valores escalares únicos (como lo hacen los futuros), sino también secuencias de valores o incluso flujos infinitos. Observable es una única abstracción que puede usarse para cualquiera de estos casos de uso. Un Observable tiene toda la flexibilidad y elegancia asociadas a el Iterable:


ReactiveX no está sesgado hacia alguna fuente particular de concurrencia o asincronía. Los observables se pueden implementar utilizando grupos de subprocesos, bucles de eventos, I/O sin bloqueo, actores (como de Akka) o cualquier implementación que se adapte a sus necesidades, su estilo o su experiencia. El código del cliente trata todas sus interacciones con Observables como asíncronas, ya sea que su implementación subyacente sea bloqueante o no.

ReactiveX proporciona una colección de operadores con los que puede filtrar, seleccionar, transformar, combinar y componer Observables. Esto permite una ejecución y composición eficientes.

Se Puede pensar en la clase Observable como un equivalente a Iterable. Con un Iterable, el consumidor extrae valores del productor y los bloques de subprocesos hasta que lleguen esos valores. Por el contrario, con un Observable, el productor introduce valores al consumidor cuando los valores están disponibles. Este enfoque es más flexible, porque los valores pueden llegar sincrónicamente o asincrónicamente.


El tipo Observable agrega dos semánticas faltantes al patrón Observador de la Banda de los Cuatro, para que coincida con las que están disponibles en el tipo Iterable:

  • la capacidad del productor de indicarle al consumidor que no hay más datos disponibles (un bucle foreach en un Iterable se completa y regresa normalmente en tal caso; un Observable llama al método onCompleted de su observador)
  • la capacidad del productor de indicarle al consumidor que se ha producido un error (un Iterable genera una excepción si se produce un error durante la iteración; un Observable llama al método onError de su observador)
Con estas adiciones, ReactiveX armoniza los tipos Iterable y Observable. La única diferencia entre ellos es la dirección en la que fluyen los datos. Esto es muy importante porque ahora cualquier operación que pueda realizar en un Iterable, también puede realizarla en un Observable.

Dejo link : http://reactivex.io


sábado, 18 de julio de 2020

ReactiveX

Hace tiempo que existe este framework y es muy raro que no haya escrito de él antes, tal vez porque se utiliza muchísimo en Angular y no soy un experto en esta tecnología. 

Pero bueno, todo llega y vamos a hablar de ReactiveX que en su pagina web dice que ReactiveX es una combinación de buenas ideas: el patrón Observer, el patrón Iterator y la programación funcional.

Patrones y programación funcional, temas que tocamos todo el tiempo en el blog, que raro que no lo vi antes o si lo vi, le reste importancia. Me paso lo mismo con typescript

ReactiveX sigue el patrón Reactor. Que si vamos a la wikipedia podemos leer : 

"El patrón de diseño reactor es un patrón de programación concurrente para manejar los pedidos de servicio entregados de forma concurrente a un manejador de servicio desde una o más entradas. El manejador de servicio demultiplexa los pedidos entrantes y los entrega de forma sincrónica a los manejadores de pedidos asociados."

y

"Este patrón separa completamente al código específico de la aplicación de la implementación del reactor, permitiendo que los componentes de la aplicación puedan ser divididos en módulos reutilizables. Además, la llamada síncrona de los manejadores de pedidos permite concurrencia, de grano grueso, sin agregar la complejidad de múltiples hilos en el sistema."

A la vez ReactiveX utiliza los conceptos de programación reactiva. Pero que sería la programación reactiva?? 

Esto es más fácil explicarlo con un ejemplo, supongamos que tenemos que hacer una aplicación que tiene que calcular una serie de montos, el monto 1 se ingresa, el monto 2 es un porcentaje del monto 1, el monto 3 se ingresa, el monto 4, es la suma del montos. Si programaste aplicaciones seguro que te encontraste con un problema similar. Si ingresa el monto 1 debemos refrescar todos los montos calculados y si ingresan el monto 3 solo el 4. Podemos atacamos este problema poniendo un botón que refresque los valores, el tema es que más allá que es poco práctico, no esta bueno que si modificamos el monto 3, se refresque todo (ya que es innecesario)

Excel o una hoja de calculo, la hace más fácil, cuando modificamos la celda, refresca automáticamente todos los valores que la usan esta celda para su calculo, este es el concepto de reactividad. Y es mucho más eficiente. 

Pero ahora volvamos a reactiveX que básicamente implementa lo que acabo de explicar, con diferentes conceptos : observador y suscripción. 

Por lo tanto ReactiveX es una librería para componer programas asincrónicos y basados en eventos mediante el uso de secuencias observables.

Extiende el patrón de observador para admitir secuencias de datos y/o eventos y agrega operadores que le permiten componer secuencias juntas de manera declarativa, mientras abstrae preocupaciones sobre cosas como subprocesos de bajo nivel, sincronización, seguridad de subprocesos, estructuras de datos concurrentes y no bloqueo de I/O.

ReactiveX es multilenguaje y multiplataforma, talvez la versión más utilizada es la de javascript, ya que viene con Angular y otros frameworks webs. Pero se puede utilizar en diferentes plataformas y lenguajes. 

Les dejo la lista: 

Languages

ReactiveX for platforms and frameworks

Y como me quedo muy largo el post, voy a seguir en otros...

Dejo link: 
http://reactivex.io/

viernes, 17 de julio de 2020

Que hay de nuevo en MongoDB 4.4 ?


MongoDB 4.4 se viene con todo!!! 

El resultado de este release es una base de datos que le permite crear aplicaciones transaccionales, operativas y analíticas más rápido que cualquier otra, para escalarlas globalmente, con la flexibilidad de definir y refinar la distribución de datos en cualquier momento a medida que evolucionan sus requisitos. Todo mientras nos brinda controles de latencia y seguridad más sofisticados.

Esta version mejora las consultas de tal modo que se puede combinar datos de múltiples colecciones para una exploración y análisis más profundos.

Expresiones de agregación personalizadas para ampliar MongoDB con nuestras propias funciones, ejecutadas como parte de una canalización de agregación.

Lectura y escritura para configurar el aislamiento en todo el clúster y las garantías de durabilidad de escritura.

Nuevos controladores Rust y Swift.

MongoDB va ser un webbinar para explicar todo esto, un tanto mejor que yo, te dejo el link:

martes, 14 de julio de 2020

The Truffle Language Implementation Framework

Graal es un super proyecto, que en su paraguas contiene muchos subproyectos. Tal vez el más famoso es pasar a nativa una aplicación java con las imagenes, que se hizo famoso por mejorar mucho la performance de aplicaciones java. 

Pero no voy a hablar de eso ahora, si no de otro subproyecto que permite implementar cualquier lenguaje a en la maquina virtual de graal. Truffle representa un avance significativo en la tecnología de implementación de lenguaje de programación dinámicos en la maquina virtual Graal.

Para hacerla corta Truffle nos permite implementar de forma sencilla un lenguaje dinámico en la maquina virtual GraalVM, con lo cual podemos llevar un programa escrito en un lenguaje dinámico a una imagen nativa. Haciendo que sea super rapido (comparado con su versión no nativa). Y a la vez nos brinda herramientas comunes para debugear diferentes lenguajes. 

Además provee un lenguaje simple como ejemplo. SimpleLanguage es un lenguaje de demostración creado con la API Truffle. El proyecto SimpleLanguage proporciona un escaparate sobre cómo usar las API de Truffle para escribir su propio Lenguaje. Su objetivo es utilizar la mayoría de las funciones del marco Truffle disponibles y documenta su uso ampliamente con la documentación fuente en línea.

Truffle es desarrollado y mantenido por Oracle Labs y el Institute for System Software de la Universidad Johannes Kepler de Linz.

Dejo link: 
https://github.com/oracle/graal/tree/master/truffle

domingo, 12 de julio de 2020

Relaciones en MongoDB

Es común que la información que almacenamos en nuestra base de datos esté conectada entre sí. Esto se denomina relaciones.  En una base de datos podemos encontrar distintos tipos de relaciones, mismas que clasificamos por la cantidad de información que se conecta entre sí. Por ejemplo, cuando un curso puede tener muchos vídeos, decimos que es una relación de uno a muchos, cuando un usuario puede tener un registro de configuración, podemos decir que es una relación uno a uno.

Las relaciones son un problema por sí mismas, y son aún más difíciles de comprender en el contexto de una base de datos como la de MongoDB a la que usualmente nos referimos como una base de datos no relacional.

La primer regla que tienes que considerar es que si en tu información existen muchas relaciones, quizás debas considerar utilizar un motor de bases de datos hecho para éstos casos como una base de datos relacional.

La segunda regla es que sí puedes tener relaciones en una base de datos noSQL como la de MongoDB, pero existen ciertas consideraciones importantes, para entenderlas necesitas saber que existen dos formas principales a través de las cuales puedes definir una relación en MongoDB.

Campos de referencia : este enfoque es el más parecido a las relaciones en una base de datos SQL donde se establece un campo que indica con qué otro registro está conectada la información, este es un campo especial, una llave foránea.

Dicho campo modifica el comportamiento interno de la tabla y ofrece una serie de optimizaciones y beneficios al momento de consultar las relaciones.

En una base de datos no relacional también podemos definir un campo que conecte con otro, sin embargo, este campo no es igual a una llave foránea en una base de datos relacional. Aunque a través de este campo podemos establecer y consultar relaciones, no existen modificaciones de rendimiento interno.

El mayor beneficio de usar este enfoque es que es el más sencillo de usar si tienes experiencia previa con bases de datos relacionales.

Subdocumentos : La mayor ventaja del uso de un motor no relacional como el de MongoDB, es que el rendimiento de lectura es mucho mayor en comparación con el de un motor relacional. Esta diferencia se logra a través de la eliminación de operaciones costosas, entre ellas las operaciones JOIN que nos permiten relacionar información.

La manera en que podemos solucionar este problema, respetando el enfoque no relacional del motor es a través del uso de subdocumentos.

Es importante recordar que, a diferencia del trabajo con bases de datos relacinoales, en una base de datos noSQL como la de MongoDB, no hay un proceso de normalización, en términos prácticos: la información puede estar repetida.

Este punto es clave para entender el uso de subdocumentos, donde al registrar un dato que puede estar relacionado con otro, además de registrar el documento en su colección correspondiente, podemos duplicarlo y agregarlo como un subdocumento del documento con el que está relacionado.

En un ejemplo práctico, el documento Curso podría contener una propiedad vídeos donde se guarden todos los documentos con los registros de los vídeos del curso. Si por alguna razón necesitamos listar todos los vídeos, podríamos duplicar estos documentos en una colección distinta a la de cursos.

Es importante recordar que MongoDB nos permite guardar colecciones o arreglos dentro de un documento, de hecho, existen operaciones hechas para el trabajo con arreglos.

El enfoque de los subdocumentos conserva los beneficios en rendimiento de una base de datos no relacional, por lo que es recomendable usarlos. Por otro lado, cuando la información es redundante, es decir está repetida, debemos mantenerla sincronizada en muchos puntos, si un vídeo se elimina de los subdocumentos del Curso, también debemos eliminarlo de la colección de Vídeos, por citar un ejemplo.

Rust es orientado a objeto?


Antes que nada vamos a aclarar que que un lenguaje sea orientado a objeto ni es bueno, ni es malo. Yo en lo personal opino que es mejor que un lenguaje no sea orientado a objeto, que lo soporte parcialmente. 

Rust está influenciado por muchos paradigmas de programación, incluyendo POO; por ejemplo, con características de la programación funcional. Podría decirse que los lenguajes POO comparten ciertas características comunes, a saber, objetos, encapsulación y herencia.

El libro Design Patterns: Elements of Reusable Object-Oriented Software de Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides (Addison-Wesley Professional, 1994) coloquialmente conocido como el libro The Gang of Four, es un catálogo de libros orientados a objetos patrones de diseño. Y define POO de esta manera: Los programas orientados a objetos están formados por objetos. Un objeto empaqueta tanto los datos como los procedimientos que operan en esos datos. Los procedimientos generalmente se denominan métodos u operaciones.

Usando esta definición, Rust está orientado a objetos: las estructuras y las enumeraciones tienen datos, y los bloques implementados proporcionan métodos en estructuras y enumeraciones. Aunque las estructuras y enumeraciones con métodos no se denominan objetos, proporcionan la misma funcionalidad, según la definición de objetos de la Banda de los Cuatro.

Otro aspecto comúnmente asociado con POO es la idea de encapsulamiento, lo que significa que los detalles de implementación de un objeto no son accesibles para el código que usa ese objeto. Por lo tanto, la única forma de interactuar con un objeto es a través de su API pública o interfaz; el código que usa el objeto no debería poder alcanzar las partes internas del objeto y cambiar los datos o el comportamiento directamente. Esto permite que el programador cambie y refactorice las partes internas de un objeto sin necesidad de cambiar el código que usa el objeto.

En Rust podemos usar la palabra clave pub para decidir qué módulos, tipos, funciones y métodos en nuestro código deben ser públicos, y por defecto todo lo demás es privado. Por ejemplo, podemos definir una estructura AveragedCollection que tiene un campo que contiene un vector de valores i32. La estructura también puede tener un campo que contenga el promedio de los valores en el vector:

pub struct AveragedCollection {
    list: Vec<i32>,
    average: f64,
}

La estructura está marcada como pub para que otro código pueda usarla, pero los campos dentro de la estructura permanecen privados. Esto es importante en este caso porque queremos asegurarnos de que siempre que se agregue o elimine un valor de la lista, el promedio también se actualice. Hacemos esto implementando métodos de adición, eliminación y promedio en la estructura:

impl AveragedCollection {

    pub fn add(&mut self, value: i32) {
        self.list.push(value);
        self.update_average();
    }

    pub fn remove(&mut self) -> Option<i32> {
        let result = self.list.pop();
        match result {
            Some(value) => {
                self.update_average();
                Some(value)
            }
            None => None,
        }
    }

    pub fn average(&self) -> f64 {
        self.average
    }

    fn update_average(&mut self) {
        let total: i32 = self.list.iter().sum();
        self.average = total as f64 / self.list.len() as f64;
    }
}

Los métodos públicos add, remove y average son las únicas formas de acceder o modificar datos en una instancia de AveragedCollection. Cuando se agrega un elemento a la lista usando el método add o se elimina usando el método remove, las implementaciones de cada llamada llaman al método privado update_average que también maneja la actualización del campo promedio.

Dejamos la lista y los campos promedio privados para que no haya forma de que el código externo agregue o elimine elementos al campo de la lista directamente; de lo contrario, el campo promedio podría no estar sincronizado cuando cambie la lista. El método promedio devuelve el valor en el campo promedio, permitiendo que el código externo lea el promedio pero no lo modifique.

Debido a que hemos encapsulado los detalles de implementación de la estructura AveragedCollection, podemos cambiar fácilmente aspectos, como la estructura de datos, en el futuro. Por ejemplo, podríamos usar un HashSet <i32> en lugar de un Vec <i32> para el campo de lista. Mientras las firmas de los metodos agregar, eliminar y los métodos públicos promedio permanezcan igual, no será necesario cambiar el código que usa AveragedCollection. Si hiciéramos pública la lista, este no sería necesariamente el caso: HashSet <i32> y Vec <i32> tienen diferentes métodos para agregar y eliminar elementos, por lo que el código externo probablemente tendría que cambiar si modificara la lista directamente.

Si la encapsulación es un aspecto requerido para que un lenguaje se considere orientado a objetos, entonces Rust cumple con ese requisito. La opción de usar pub o no para diferentes partes del código permite la encapsulación de los detalles de implementación.

La herencia es un mecanismo mediante el cual un objeto puede heredar de la definición de otro objeto, obteniendo así los datos y el comportamiento del objeto principal sin que tenga que definirlos nuevamente.

Si un lenguaje debe tener herencia para ser un lenguaje orientado a objetos, entonces Rust no es uno. No hay forma de definir una estructura que herede los campos de la estructura principal y las implementaciones de métodos. Sin embargo, si está acostumbrado a tener herencia en su caja de herramientas de programación, puede usar otras soluciones en Rust, dependiendo de su razón para buscar la herencia en primer lugar.

Eliges la herencia por dos razones principales: 
  • Una es para la reutilización del código: puede implementar un comportamiento particular para un tipo, y la herencia le permite reutilizar esa implementación para un tipo diferente. En su lugar, puede compartir el código Rust utilizando implementaciones de métodos predeterminados de trait. 
  • La otra razón para usar la herencia se relaciona con el sistema de tipos: para permitir que un tipo secundario se use en los mismos lugares que el tipo primario. Esto también se llama polimorfismo, lo que significa que puede sustituir varios objetos entre sí en tiempo de ejecución si comparten ciertas características.

Para muchas personas, el polimorfismo es sinónimo de herencia. Pero en realidad es un concepto más general que se refiere al código que puede funcionar con datos de múltiples tipos. Para la herencia, esos tipos son generalmente subclases.

En su lugar, Rust usa genéricos para abstraer sobre diferentes tipos posibles y límites de rasgos para imponer restricciones sobre lo que esos tipos deben proporcionar. Esto a veces se llama polimorfismo paramétrico acotado.

La herencia ha caído recientemente en desgracia como una solución de diseño de programación en muchos lenguajes de programación porque a menudo corre el riesgo de compartir más código del necesario. Las subclases no siempre deben compartir todas las características de su clase principal, sino que lo harán con la herencia. Esto puede hacer que el diseño de un programa sea menos flexible. También introduce la posibilidad de llamar a métodos en subclases que no tienen sentido o que causan errores porque los métodos no se aplican a la subclase. Además, algunos lenguajes solo permitirán que una subclase herede de una clase, lo que restringirá aún más la flexibilidad del diseño de un programa.

Por estas razones, Rust adopta un enfoque diferente, utilizando objetos de trait en lugar de herencia. 

Dejo link: 
https://doc.rust-lang.org/book/ch17-01-what-is-oo.html

Libros de Java Code Geek

 

Java Design Patterns

A design pattern is a general reusable solution to a commonly occurring problem within a given context in software design. A design pattern is not a finished design that can be transformed directly into source or machine code

 
 

Android Programming Cookbook

Android is a mobile operating system developed by Google, based on the Linux kernel and designed primarily for touchscreen mobile devices such as smartphones and tablets. Android's user interface is mainly based on direct manipulation,