# LAB 02 - Paradigmas 2022

###### Integrantes: Franco Artico, Francisco Percivaldi y Martin Piloni

En este laboratorio nos fue entregado un código que funciona correctamente el cual, a partir de una URL de interés dada (como puede ser un sitio web de noticias) crea una **lista de entidades nombradas** con el fin de obtener las palabras que son **más nombradas** dentro de este sitio. Sin embargo, el código dado seguía los lineamentos de un _código spaghetti_.

Nuestra tarea era refactorizar el código usando POO (*Progamación Orientada a Objetos*) en Scala y agregarle a la herramienta nuevas funcionalidades 🛠️.

## Parte 1: Poniendo un poco de orden

La primera gran abstracción propuesta fue separar el **procesamiento** de los datos con la **obtención** de los mismos.

Con esta abstracción, obtenemos que cualquiera de las dos partes puede ser reemplazada con mayor facilidad. A continuación responderemos las preguntas propuestas en el enunciado

#### ¿Cómo es la interfaz de la clase u objeto que implementaron para el primer componente?

Nuestra interfaz para la parte 1 consta de dos clases que luego son instanciadas en ```TrendingNer.scala```.
- Clase ```TextFeedRequester```: esta clase contiene un método llamado ```getResponse``` que realiza una petición HTTP para una URL dada.
- Clase ```RSSFeedRequester```: contiene un método denominado ```parser``` que devuelve una lista de strings donde cada elemento contiene el texto dentro de las etiquetas ```<title>``` y ```<description>```.

#### ¿Utilizaron una clase o un objeto? ¿Por qué?

Utilizamos una Clase.

Nos pareció correcto utilizar clases en vez de objetos ya que un objeto en Scala (Object) no se puede instanciar mas de una vez, por lo que si usabamos objetos sólo podríamos manejar un _request_, mientras que con clases podemos instanciar una cantidad arbitraria de objetos. Esto es muy util cuando tenemos distintos tipos de Feeds.

#### En sus palabras, ¿qué es la cohesión del código? ¿Por qué agregar nuevas clases aumenta la cohesión?

La cohesión del código es como una unidad de medida la cual mide la independencia entre partes de un código.

Es decir, la cohesión se ve aumentada siempre y cuando mantengamos dentro de un mismo módulo aquellas funciones que se encuentren relacionadas entre sí.

El hecho de agregar nuevas clases aumenta la cohesión, si es que los módulos y atributos dentro de ellas están estrechamente relacionados. De ser así, las divisiones en clases nos puden ayudar a separar partes del código, que conjuntas no tienen una gran relación.

#### [Opcional] ¿Qué es la separación de responsabilidades en la programación y cómo se relaciona con la actividad que acabamos de realizar?

La separación de responsabilidades es principio de diseño el cual se basa en dividir un programa en diferentes secciones, de modo que cada sección tenga un fin determinado.

La actividad encargada en esta primera parte fue separar en dos secciones, dos partes de código que se utilizaban para dos cosas distintas. Una parte obtenía los datos dada una URL y la otra los procesaba, al separar estas dos partes en secciones distintas aplicamos directamente el principio de diseño de la separación de responsabilidades, ya que ahora tenemos dos partes donde cada una se encarga de una sóla tarea, obtener y procesar respectivamente.

## Parte 2: Ahora que sea mas util

#### ¿Tienen código similar que se repita en esta versión intermedia del laboratorio?

En nuestro caso, no tuvimos código repetido a esta altura del laboratorio, debido a que desde un principio modularizamos lo mejor que pudimos, en parte gracias a la facilidad que nos brinda la programacion orientada a objetos.

#### ¿Qué es la herencia en la programación orientada a objetos?

La herencia en la programación orientada a objetos es un mecanismo que nos permite a partir de una clase madre heredar métodos y atributos a una clase hija (subclase).
En otras palabras, nos permite definir nuevas clases, basadas en las ya existentes, a fin de reutilizar codigo.

#### ¿Consideraron necesario utilizarla para esta implementación?

Sí, aunque era posible desarrollar un código que funcione sin la necesidad de usar herencia, esta nos brindó varias ventajas
- Mayor cohesión.
- Mayor legibilidad.
- Generar un código más fácil de modularizar y mantener.
- Reutilización de código.

#### ¿Su respuesta cambiaría si tuvieran que dar soporte a muchos tipos distintos de feeds?

No, por que gracias a la herencia, podemos lograr un código con alta cohesión.
Entonces, si necesitamos dar soporte a distintos _feeds_, podemos hacer funciones que parseen el contenido de dichos _feeds_ que sean independientes entre sí, pero que también puedan tener métodos o atributos en común.

### Más preguntas sobre acoplamiento

#### En sus propias palabras, ¿qué es el acoplamiento en el código?

El acoplamiento de código es una unidad de medida que mide el nivel de relación que hay entre dos módulos en un código. Si el acoplamiento es alto, los módulos hacen uso de otros módulos para distintas funcionalidades. De esto, se puede deducir que el acoplamiento está contrastado con la definición de cohesión, que mide la **independencia** entre dos módulos. Un bajo acoplamiento es señal de un buen diseño de _software_.

#### ¿Por qué utilizar literales como Strings para diferenciar comportamientos similares en la(s) clase(s) FeedRequester(s) crea acoplamiento?

Se estaría generando acoplamiento debido a que el comportamiento del componente actual, depende del valor del componente al cual llamamos, por lo tanto estos se están acoplando.
Es decir, al hacer una llamada a una clase desde otra, hace que están clases esten relacionadas directamente.
En el caso de usar literales, estamos condicionando a que puedan hacerse uso de 2 clases distintas, por lo tanto el hecho de que una clase llame a otra, genera acoplamiento.

Por ejemplo, si modificamos lo que realiza alguna de las clases ya sea RedditFeedRequester o RSSFeedRequester, el comportamiento de TrendingNer cambiara.

#### Teniendo en cuenta esta clasificación de tipos de acoplamiento en la programación estructurada, ¿a qué tipo(s) corresponde el caso anterior?

Se trata de **acoplamiento de contenido** y **acoplamiento de datos**.

## Parte 3: Multiples suscripciones
#### ¿Qué clase almacena las URLs suscriptas?
La clase que se encarga de almacenar las URLs suscriptas es SubscriptionService, para esto utiliza un atributo (subscribedUrls), sobre la cual cada vez que se agrega una nueva URL se realiza asignacion destructiva. Por esto mismo almacenar las URLs de esta forma no es declarativo.

#### En sus palabras, ¿qué es la sobrecarga de métodos/funciones? ¿La utilizaron para implementar la clase SubscriptionService?

La sobrecarga de métodos es la forma más común de implementar _polimorfismo_. Consiste en usar el mismo nombre para definir una función, para que esta tome diferentes tipos. No usamos sobrecarga para implementar la clase SubscriptionService.

### Manejando distintos tipos de feeds en SubscriptionService

#### ¿Cómo funciona el polimorfismo de clases en su implementación? ¿De qué manera les permite reducir el acoplamiento?

Cuando implementamos SubscriptionService, en el metodo _subscribe_ tenemos el parámetro _requester_ con el tipo _TextFeedRequester_, esto nos permite pasar como argumento una cantidad arbitraria de feeds distintos mientras hereden de la clase TextFeedRequester (por subtipado), sin ningún problema. Esto permite utilizar clases distintas dependiendo el tipo de Feed que se nos pase, en vez de tener que usar metodos de la clase TextFeedRequester lo que aumentaria el acoplamiento.