knitr::opts_chunk$set(
  collapse = TRUE,
  comment = "#>"
)
library(UMLR2)

Intro

Principios

Componentes

Decisiones

Config

Se ha incluido deep y detail aunque no sean siempre necesarios. todos los miembros se usan con get y set

dataframes

Guardamos los tipos de objetos en dataframes para optimizar los procesos de buscar duplicados y de fusionarlos

Si no habria que hacer un matching de clases

lock_objects y portable

El atributo de la clase lock_objects impide que se pueda modificar la clase a través de los métodos de S3. Lógicamente hay que activarlo para proteger las clases.

el atributo portable; por un lado, permite que la clases puedan heredar de clases en otros paquetes, lo cual no es el caso. Por otro lado, si se activa, obliga a prefijar los miembros con self o private, lo cual hace la codificación mas "verbose".

Dentro del paradigma OOP no debería haber diferencias entre un atributo/método publico o privado dentro de la propia clase, por lo que todas las clases deben tener el atributo portable = FALSE

Herencias, agregaciones y composiciones

En las versiones anteriores se estableció un sistema de herencias para facilitar la codificación. Se ha observado que este enfoque hace mas confuso saber donde está definido cada método o donde se ejecuta.

Por este motivo, se considera mas adecuado utilizar la composición de objetos; es decir, que el objeto contenedor instancia el objeto que usa y lo vincula a su ciclo de vida.

Ejemplo:

TODO Aqui van los diagramas

Singletons

Tenemos algunas clases que son inmutables pero usadas por todo el resto de clases y tambien tenemos clases genericas, usadas tambien por el resto de clases, que pueden variar en función de la instancia concreta que se ejecute.

Las primeras los generamos como singleton y son, por archivos fuente:



Grandez/umlr2 documentation built on Aug. 31, 2020, 2:49 a.m.