Categoría: Metodología y filosofía

Artículos, pensamientos y experiencias vitales

De productos adquiridos a servicios de suscripción para la mejora de la autonomía personal

Publicado el

La sociedad va cambiando poco a poco de una cultura de adquisición y almacenamiento de productos a una de contratación y disfrute de servicios.

Esto poco a poco también está llegando al mercado de los productos y servicios de accesibilidad para personas con discapacidad.
De productos de apoyo físicos a digitales

Durante toda la historia de la humanidad tanto el sistema de evaluación de riquezas de una persona como los sistemas de comercio y mercado se basaban en una cultura de elementos tangibles. Métodos de comercio como el trueque se basan en el intercambio de elementos físicos: una vaca por dos cabras, un tonel de vino por 3 toneles de leche, etc.

Los productos de apoyo siempre han sido elementos físicos como bastones, sillas de ruedas, prótesis ortopédicas, gafas y anteojos o muletas por lo que han sido considerados como bienes físicos a poseer por las personas que los necesitan.

Con la aparición de la informática y la tecnología digital aparecieron nuevos productos de apoyo como lectores de pantalla, magnificadores de pantalla, teclados virtuales o sistemas de reconocimiento del habla.

Este tipo de productos de apoyo basados en software han sido comercializados como productos a instalar en un dispositivo como un ordenador personal o dispositivo móvil y disfrutar de él hasta que apareciese una nueva versión del producto de apoyo por la que, en muchos casos, había que volver a pagar ya que la licencia de uso no reconocía el derecho a actualización por parte del usuario a todas las versiones publicadas con posterioridad.

Revolución en el concepto de pago

Con la mejora en las pasarelas de pago y los servicios de transacciones económicas digitales las personas nos hemos acostumbrado y confiado en el comercio digital. Es habitual que una persona tenga una tarjeta de crédito registrada en su dispositivo móvil o tenga varios métodos de pago digital en su perfil de usuario en la Nube.

Esto ha facilitado la aparición de nuevos modelos de comercialización del software al entender que el software es un servicio en lugar de un producto a poseer. Por esta razón aparecieron modelos de pago por suscripción que permiten el acceso a una aplicación o herramienta digital por el tiempo en que la persona pague por el servicio. Plataformas de consumo de contenidos multimedia o de videojuegos o plataformas de música digital son los ejemplos más habituales de este tipo de comercio.

Este cambio también está llegando a herramientas software como aplicaciones de edición de video o documentos, herramientas de diseño 3D o aplicaciones cuyas licencias superan los miles de dólares.

Beneficios del sistema de pago por suscripción

El primer beneficio que se puede apreciar en este nuevo sistema de comercio es el precio reducido para acceder al uso y disfrute de estos elementos digitales. Licencias de 1500 euros por un paquete de diseño artístico por el que hay que volver a pagar tras una nueva actualización pasan a 15 euros al mes para acceder a la última versión disponible.

El segundo beneficio es que los responsables de desarrollar el producto software tienen ingresos más estables que les motiva a mantener y mejorar el producto durante más tiempo buscando nuevas características y funciones que hagan su producto más atractivo y más útil para más personas.

Otro beneficio es el de si la persona ya no necesita el producto pues deja de pagar por el servicio hasta la próxima vez que lo necesite. No hay por qué pagar cuotas de alta o suscripción o realizar trámites burocráticos de registro e identificación cada vez que se suscriba.

Por último se ha observado que estos cambios en los sistemas de comercialización atraen a una ampliación en la competencia. Hay más variedad de servicios disponibles en el mercado que compiten entre ellos ofreciendo mejoras o más funciones.

Productos de apoyo como servicios por suscripción

Esta revolución de productos de apoyo digital como servicios por suscripción se está empezando a dar poco a poco. Ya existen algunos sistemas de control por voz o de reconocimiento de imágenes que se adquieren como un servicio por suscripción. Servicios de ayuda y asistencia a personas con discapacidad mediante videollamadas también se utilizan mediante un modelo de suscripción mensual.

Algunos lectores de pantalla y magnificadores de pantalla están incluyendo nuevas funciones y características que para poderlas utilizar hay que pagar una suscripción mensual o anual.

Este cambio es beneficioso para los creadores de productos de apoyo al permitirles acceder a este nuevo sistema de pagos y recompensa por un mejor mantenimiento del producto pero los beneficios para las personas con discapacidad no están tan claros. A diferencias de los servicios de ocio como las plataformas de video o juegos, o las aplicaciones por suscripción con un marcado perfil profesional un producto de apoyo no suele ser un servicio opcional que una persona necesita por un tiempo determinado. Si una persona ciega no necesita utilizar más un lector de pantallas es probable que la razón para no necesitar un producto de apoyo es porque no esté viva.

Los productos de apoyo son herramientas esenciales para la vida cotidiana y la autonomía personal de una persona con discapacidad.

El acceso a funcionalidades extra o mejoras para un producto de apoyo es algo que si se comprende como un servicio por suscripción para un producto de apoyo pero si el acceso a un producto de apoyo, en todos sus niveles de uso, se debe realizar mediante una suscripción esto puede provocar que personas con discapacidad con pocos recursos económicos o que carezcan de acceso a sistemas de pagos digitales no puedan acceder al uso de estos productos de apoyo por suscripción.

En la diversidad está la solución

La existencia de los servicios por suscripción para el software no anula los sistemas de comercialización anteriores de pagar por una aplicación una vez y disfrutarla hasta que se decida adquirir una mejor.

El mercado es lo suficientemente amplio y flexible para que convivan diversas formas de comercialización del software. Es más, esta tendencia de diversidad en la comercialización debería ampliarse al mercado de productos de apoyo hardware. Por ejemplo, una persona ciega podría pagar un alquiler de una línea braille o una persona en silla de ruedas podría pagar una suscripción mensual para poseer una silla de ruedas eléctrica que fuese actualizada cada año.

Además existen también productos y servicios digitales gratuitos o que requieren de un registro y una aceptación de condiciones para su uso ya que se apoyan en la publicidad o el análisis de la información personal para obtener beneficios.

Los actuales modelos de pago por producto o pago por suscripción abren las puertas a futuros modelos de comercialización de productos y servicios que, esperemos, puedan convivir entre ellos. De esta forma cada persona podría elegir el formato de pago más apropiado a sus circunstancias para que todo el mundo pudiese satisfacer sus necesidades.

Lo que está totalmente claro es que el dinero digital ha llegado para quedarse y esto abre muchas posibilidades para comercializar servicios y productos. Es el momento de que cada persona elija qué le conviene y dónde quiere poner su dinero por la accesibilidad.

SOLID: Principio de inversión de dependencias o Dependency inversion principle

Publicado el

Este es el quinto y último principio de programación SOLID.

Significado

Este principio establece que las clases de alto nivel no deberían depender de las clases de bajo nivel. En su lugar las clases deberían depender de las abstracciones.

Además las abstracciones no deben depender de los detalles sino que los detalles deben depender de las abstracciones.

Con este principio se busca reducir las dependencias entre módulos buscando un menor nivel de acoplamiento entre clases.

Esto es indispensable en proyectos con muchos módulos en los que es necesario utilizar inyección de dependencias.

Ejemplo

Veamos el siguiente ejemplo en el que en nuestro proyecto tenemos una clase que nos permite el acceso a la base de datos en general que llamaremos CargadorDesdeBaseDeDatos y tenemos una clase PersonaEnBaseDeDatos que nos permite cargar datos de la clase Persona.

Para ello la clase PersonaEnBaseDeDatos tiene una propiedad de tipo CargadorDesdeBaseDeDatos que se utiliza como driver de acceso al sistema de almacenamiento de bases de datos de la aplicación.

 

class CargadorDesdeBaseDeDatos {

    funcion obtenerDatosGenerales()

}

 

class PersonaEnBaseDeDatos {

    propiedad datos = CargadorDesdeBaseDeDatos()

    propiedad listaDePersonas

 

    funcion cargaDatos() {

        listaGeneral = datos.obtenerDatosGenerales()

        listaDePersonas = convertirDatosGeneralesEnDatosDePersonas(listaGeneral)

    }

}

 

En el ejemplo en la clase PersonaEnBaseDeDatos dentro de la función cargaDatos() hay una dependencia de la clase AccesoABaseDeDatos. Esto es un problema porque si un día necesitamos cambiar de sistema de base de datos o de obtener datos de Internet tendríamos que modificar demasiado código ya que ambas clases tienen una fuerte dependencia entre ellas.

Imaginemos por ejemplo que queremos incluir la opción de descargar los datos desde una API rest en Internet. El código se complicaría demasiado en todas las clases.

Solución

La solución a este problema es utilizar una abstracción que permita identificar un acceso a datos mediante una interface o protocolo, dependiendo de las posibilidades del lenguaje de programación.

Veamos el código.

 

interface AccesoADatos {

    funcion cargaDatosDePersonas

}

 

class CargadorDesdeBaseDeDatos Implementa AccesoADatos {

    propiedad listaDeDatos

 

    funcion obtenerDatosGeneralesDesdeMySQL() {

        listaDeDatos = cargaDesdeMySQL()

    }

 

    funcion cargaDatosDePersonas() {

        obtenerDatosGeneralesDesdeMySQL()

        return convertirATipoPersona(listaDeDatos)

    }

}

 

class CargadorDesdeInternet Implementa AccesoADatos {

    propiedad listaDeDatos

 

    funcion obtenerDatosGeneralesDeInternet() {

        listaDeDatos = descargaDeLaNube()

    }

 

    funcion cargaDatosDePersonas() {

        obtenerDatosGeneralesDeInternet()

        return convertirATipoPersona(listaDeDatos)

    }

}

 

class PersonaEnBaseDeDatos {

    propiedad datos = AccesoADatos

    propiedad listaDePersonas

 

    funcion constructor(inyeccion: AccesoADatos) {

        datos = inyeccion

    }

 

    funcion cargaDatos() {

        listaDePersonas = datos.cargaDatosDePersonas()

    }

}

 

Con esta solución podemos inyectar cualquier clase del tipo interface AccesoADatos en el constructor de la clase PersonaEnBaseDeDatos. De esta forma podemos cambiar cómo accedemos a esos datos inyectando cualquier clase que implemente la interfaz AccesoADatos consiguiendo un mayor nivel de desacoplamiento entre clases. De esta forma tanto el módulo de alto nivel como el de bajo nivel dependen de abstracciones, por lo que se cumple el principio de inversión de dependencias y además, esto nos obliga a cumplir el principio de Liskov, ya que las clases que accederán a cualquier base de datos son intercambiables entre ellas ya que todas implementan la interfaz de AccesoADatos.

SOLID: Principio de segregación de interfaz o Interface segregation principle

Publicado el

En este artículo hablamos del cuarto principio de los principios de programación SOLID.

Significado

Este principio establece que las clases clientes de otras no deberían verse forzados a depender de interfaces que no usan. En su lugar se apoya la definición de interfaces más específicas para cada caso.

Cuando hablamos de interfaces estamos hablando del concepto de interfaz de clase del lenguaje de programación Java así como la adaptación a cualquier otro tipo de lenguaje de programación. Por ejemplo en Swift estaríamos hablando de protocolos.

En pocas palabras una interface es un acuerdo entre las clases que implementan la interfaz y la propia interfaz definida con sus propiedades y funciones. El acuerdo consiste en que cada clase que implemente dicha interfaz deberá codificar cada una de las propiedades y funciones definidas en la interfaz.

Ejemplo

Este principio es más sencillo de entender con un ejemplo.

Imaginemos que estamos modelando una interfaz de acciones para distintas clases de aves.

 

interface Ave {

    funcion comer()

    funcion cantar()

    funcion volar()

}

 

class Loro implements Ave {

    propiedad nombre

    propiedad color

    propiedad tamaño

 

    funcion comer() {

        // código para comer

    }

 

    funcion cantar() {

        // código para cantar

    }

 

    funcion volar() {

        // código para volar

    }

}

 

class Aguila implements Ave {

    propiedad nombre

    propiedad color

    propiedad tamaño

 

    funcion comer() {

        // código para comer

    }

 

    funcion cantar() {

        noHacerNada()

    }

 

    funcion volar() {

        // código para volar

    }

}

 

class Gallina implements Ave {

    propiedad nombre

    propiedad color

    propiedad tamaño

 

    funcion comer() {

        // código para comer

    }

 

    funcion cantar() {

        // código para cantar

    }

 

    funcion volar() {

        noHacerNada()

    }

}

 

En este ejemplo tenemos una interfaz llamada Ave con 3 acciones pero no todas las aves realizan esas tres acciones. Por ejemplo las águilas no cantan y las gallinas no vuelan. Pero si una clase implementa una interfaz está obligada a incluir esas funciones aunque no hagan nada.

Solución

La solución consiste en segregar la interfaz Ave en 3 interfaces más específicas.

 

interface Ave {

    funcion comer()

}

 

interface AveCantora {

    funcion cantar()

} 

 

interface AveVoladora {

    funcion volar()

}

 

class Loro implements Ave, AveCantora, AveVoladora {

    propiedad nombre

    propiedad color

    propiedad tamaño

 

    funcion comer() {

        // código para comer

    }

 

    funcion cantar() {

        // código para cantar

    }

 

    funcion volar() {

        // código para volar

    }

}

 

class Aguila implements Ave, AveVoladora {

    propiedad nombre

    propiedad color

    propiedad tamaño

 

    funcion comer() {

        // código para comer

    }

 

    funcion volar() {

        // código para volar

    }

}

 

class Gallina implements Ave, AveCantora {

    propiedad nombre

    propiedad color

    propiedad tamaño

 

    funcion comer() {

        // código para comer

    }

 

    funcion cantar() {

        // código para cantar

    }

}

 

Ahora cada clase sólo implementa las interfaces necesarias a sus capacidades por lo que no hay funciones que no hacen nada.

Con esta solución es sencillo incluir en un futuro por ejemplo aves que puedan nadar y cada clase sólo implementará las funciones necesarias.

Además con esta solución se mejora aún más el principio de responsabilidad única.

SOLID: Principio de substitución de Liskov o Liskov substitution principle

Publicado el

Este es el tercer principio de los principios de programación SOLID y se relaciona con una característica de la programación orientada a objetos: la Herencia.

Significado

El principio Declara que una subclase debe ser sustituible por su superclase.

Si en nuestro programa al hacer esto la aplicación falla, estaremos incumpliendo este principio SOLID.

Cumpliendo con este principio se confirmará que nuestro programa tiene una jerarquía de clases fácil de entender y un código reutilizable.

Ejemplo

Siguiendo con los ejemplos de los artículos de Principio de responsabilidad única y el Principio de abierto/cerrado imaginemos que queremos controlar si una persona puede acceder a una sala restringida sólo a ciertos trabajadores. En nuestro ejemplo tendremos operarios, técnicos, estudiantes, jefes y guardias y sólo los guardias y los jefes podrán acceder a la sala de control ya que estas dos clases incluyen la función entraEnSalaDeControl(). Realizaremos esta gestión en la clase ControlarAcceso que contiene una función para imprimir si tiene acceso o no a la sala.

A esta función se le pasa como parámetro(array) una lista de objetos de la clase Persona.

Veamos el código.

 

class Persona {
    propiedad nombre
    propiedad apellidos
    propiedad nacionalidad
    propiedad fechaDeNacimiento

    funcion calculaEdad()
}

 

class Operario: Persona {
    propiedad numeroDeIdentificación

    funcion utilizaHerramienta()

    funcion tomaUnDescanso()

}

 

class Técnico: Persona {
    propiedad numeroDeIdentificación

    funcion utilizaHerramienta()

    funcion revisaOperario()

    funcion controlaCalidad()

    funcion tomaUnDescanso()

}

 

class Jefe: Persona {
    propiedad departamento

    funcion revisaPersona()

    funcion controlaCalidad()

    funcion entraEnSalaDeControl() {

        imprime(“Jefe.nombre accede a la sala de control»)

 

    }

}

 

class Guardia: Persona {
    propiedad numeroDePlaca

    funcion vigilaSala()

    funcion arrestaPersona()

    funcion entraEnSalaDeControl() {

        imprime(“Guardia.nombre accede a la sala de control»)

    }
}

 

class ControlarAcceso {

    funcion imprimePermisos(listaDePersonas: Array de Persona) {

        Bucle personaDeLaLista en listaDePersonas {

            Si personaDeLaLista esInstanciaDe Operario

            ENTONCES imprime(“personaDeLaLista.nombre no tiene acceso.»)

            Si personaDeLaLista esInstanciaDe Técnico

            ENTONCES imprime(“personaDeLaLista.nombre no tiene acceso.»)

            Si personaDeLaLista esInstanciaDe Guardia

            ENTONCES personaDeLaLista.entraEnSalaDeControl()

            Si personaDeLaLista esInstanciaDe Jefe

            ENTONCES personaDeLaLista.entraEnSalaDeControl()

        }

    }

}

 

Este código además de incumplir el principio de abierto / cerrado incumple el principio de substitución de Liskov.

Solución

Utilizando las propiedades de la Herencia en programación orientada a objetos podemos incluir una función entraEnSalaDeControl() con un valor por defecto de no acceso en la clase Persona. 

Todas las clases hijas heredarán esta función por lo que sólo habría que sobreescribir esta función en las clases que si tengan acceso.

El código quedaría de la siguiente forma.

 

class Persona {
    propiedad nombre
    propiedad apellidos
    propiedad nacionalidad
    propiedad fechaDeNacimiento

    funcion calculaEdad()

    funcion entraEnSalaDeControl() {

        imprime(“Persona.nombre no tiene acceso a la sala de control»)

    }

}

 

class Operario: Persona {
    propiedad numeroDeIdentificación

    funcion utilizaHerramienta()

    funcion tomaUnDescanso()

}

 

class Técnico: Persona {
    propiedad numeroDeIdentificación

    funcion utilizaHerramienta()

    funcion revisaOperario()

    funcion controlaCalidad()

    funcion tomaUnDescanso()

}

 

class Jefe: Persona {
    propiedad departamento

    funcion revisaPersona()

    funcion controlaCalidad()

    SobreEscrito funcion entraEnSalaDeControl() {

        imprime(“Persona.nombre accede a la sala de control»)

    }

}

 

class Guardia: Persona {
    propiedad numeroDePlaca

    funcion vigilaSala()

    funcion arrestaPersona()

    SobreEscribe funcion entraEnSalaDeControl() {

        imprime(“Persona.nombre accede a la sala de control»)

    }
}

 

class ControlarAcceso {

    funcion imprimePermisos(listaDePersonas: Array de Persona) {

        Bucle personaDeLaLista en listaDePersonas {

            personaDeLaLista.entraEnSalaDeControl

        }

    }

}

 

Ahora la función imprimePermisos no tiene que consultar a qué clase pertenece la persona de la lista ya que por contrato de herencia todas las clases hijas de Persona incluyen la función entraEnSalaDeControl(). Esto facilita que si en el futuro es necesario agregar nuevas clases hijas de Persona sólo habrá que sobreescribir la función en aquellas clases que si tengan acceso. De esta forma mejoramos el mantenimiento del proyecto.

SOLID: Principio de abierto/cerrado u Open/closed principle

Publicado el

Como vimos en el artículo de los principios SOLID este es el segundo principio.

Significado

Este principio Establece que las clases deben estar abiertas para su extensión, pero cerradas para su modificación.

Ejemplo

Siguiendo con el ejemplo de la clase Persona que vimos en el artículo del principio de responsabilidad única imaginemos que tenemos una lista de personas(array) y queremos imprimir por pantalla las personas que tengan la edad suficiente para conducir un vehículo. Pero debemos tener en cuenta que según el país esta edad puede ser distinta. Para completar este programa crearemos una clase ListaDePersonasMayoresDeEdad que resolverá este problema con la función imprimeConductores().

Para el ejemplo de código en lugar de cargar los datos de personas de la base de datos tendremos una lista que se rellenará en el constructor de la clase ListaDePersonasMayoresDeEdad.

El código de ejemplo quedaría así:

 

class Persona {
    propiedad nombre
    propiedad apellidos
    propiedad nacionalidad
    propiedad fechaDeNacimiento

funcion calculaEdad()
}

 

class ListaDePersonasMayoresDeEdad {

    propiedad listaDePersonas

 

    funcion Constructor() {

        listaDePersonas = [

            Persona(“Fulano”, “De tal”, Español, 1/5/1981),

            Persona(“Mengano”, “De cual”, Mejicano, 3/12/1992),

            Persona(“John”, “Doe”, Norteamericano, 13/2/2012),

            Persona(“Boris”, “Stalin”, Ruso, 20/9/1999)

        ]

    }

 

    funcion imprimeConductores() {

        bucle personaDeLaLista en listaDePersonas {

            Si personaDeLaLista.nacionalidad = Español Y personaDeLaLista.calculaEdad() >= 18

            entonces imprime(personaDeLaLista)

            Si personaDeLaLista.nacionalidad = Norteamericano Y personaDeLaLista.calculaEdad() >= 16

            entonces imprime(personaDeLaLista)

            Si personaDeLaLista.nacionalidad = Ruso Y personaDeLaLista.calculaEdad() >= 18

            entonces imprime(personaDeLaLista)

        }

    }

}

 

Este programa no cumple el principio de abierto/cerrado por la sencilla razón de la necesidad de modificar la clase ListaDePersonasMayoresDeEdad cada vez que haya una nacionalidad nueva en nuestra base de datos. La función imprimeConductores() tendría que ser modificada cada vez que en la base de datos apareciese un usuario con una nueva nacionalidad.

Solución

Dependiendo de las características y las capacidades del lenguaje de programación que estemos utilizando la solución puede crearse mediante clases abstractas, protocolos o empleando una solución generalista como la creación de una clase nacionalidad que encapsule ciertos requisitos en la base de datos.

El objetivo de la solución se enfoca en evitar tener que modificar una función o clase en el futuro simplemente porque se agreguen nuevos datos a la base de datos.

Recordemos que este principio nos mueve a extender una clase para evitar estar modificando otra constantemente. Por esa razón podemos extender la clase Persona gracias a la nueva clase Nacionalidad

Veamos el código de esta solución.

 

class Persona {
    propiedad nombre
    propiedad apellidos
    propiedad nacionalidad
    propiedad fechaDeNacimiento

funcion calculaEdad()
}

 

class Nacionalidad {

    propiedad nombreDeNacionalidad

    propiedad edadParaConducir

}

 

class ListaDePersonasMayoresDeEdad {

    propiedad listaDePersonas

    propiedad nacionalidades 

    funcion Constructor() {

        nacionalidades = [

            Nacionalidad(Español , 18),

            Nacionalidad(Norteamericano , 21),

            Nacionalidad(Mejicano , 15),

            Nacionalidad(Ruso , 18),

        ]

 

        listaDePersonas = [

            Persona(“Fulano”, “De tal”, Español, 1/5/1981),

            Persona(“Mengano”, “De cual”, Mejicano, 3/12/1992),

            Persona(“John”, “Doe”, Norteamericano, 13/2/2012),

            Persona(“Boris”, “Stalin”, Ruso, 20/9/1999)

        ]

    }

 

    funcion imprimeConductores() {

        bucle personaDeLaLista en listaDePersonas {

            Si personaDeLaLista.calculaEdad() >= personaDeLaLista.nacionalidad.edadParaConducir

            entonces imprime(personaDeLaLista)

        }

    }

 

}

 

Ahora el bucle que hay en la función imprimeConductores() se ha reducido y es más legible.

Esta solución es más fácil de mantener y facilita que la clase Nacionalidad pueda incorporar más información interesante para nuestra aplicación y su mantenimiento ha mejorado al no existir la necesidad de modificar eternamente una función de una clase concreta dependiendo de qué datos hay en la base de datos.

SOLID: Principio de responsabilidad única o Single responsibility principle

Publicado el

Como vimos en el artículo de los principios SOLID este es el primero de los principio SOLID.

Significado

Este principio establece que una clase o componente debe ser responsable de una sola cosa.

Este principio está alineado con el término de desacoplamiento o decoupled utilizado en muchas metodologías de desarrollo.

Cuando se codifica una clase que sólo posee una responsabilidad o función es fácil diseñar tests para comprobar que funciona correctamente y además facilita que esa clase pueda ser reutilizada en futuros proyectos.

Ejemplo

Imaginemos el siguiente ejemplo en el que tenemos una clase Persona que contiene los datos de un usuario.

El código de nuestra clase podría ser algo como:

 

class Persona {
    propiedad nombre
    propiedad apellidos
    propiedad nacionalidad
    propiedad fechaDeNacimiento

    funcion calculaEdad()
    funcion guardaEnBaseDeDatos()
    funcion cargaDesdeBaseDeDatos()
}

Este ejemplo viola el principio de responsabilidad única.

Esto se debe a que la clase Persona además de guardar la información de una persona también se encarga de almacenar y recuperar la información de una base de datos.

Imaginemos que nuestra aplicación está utilizando MySQL pero en una futura versión queremos incluir soporte para la base de datos RealM manteniendo la opción de MySQL. Los cambios que tendríamos que hacer a nuestra clase persona complicarían enormemente el código.

En cambio si creamos una clase Persona que almacene los datos de un usuario y otra clase PersonaMySQL que se encargue de recuperar y almacenar los datos en nuestra base de datos MySQL permitiría fácilmente la codificación de una nueva clase PersonaRealM que haga lo mismo que la clase PersonaMySQL pero adaptando el código a la base de datos RealM.

 

class Persona {
    propiedad nombre
    propiedad apellidos
    propiedad nacionalidad
    propiedad fechaDeNacimiento

    funcion calculaEdad()
}

class PersonaMySQL {
    funcion guardaEnBaseDeDatos()
    funcion cargaDesdeBaseDeDatos()
}

class PersonaRealM {
    funcion guardaEnBaseDeDatos()
    funcion cargaDesdeBaseDeDatos()
}

Nuestro programa será mucho más cohesivo y estará más encapsulado aplicando este principio. Siguiendo esta forma de agrupar funciones y propiedades en nuestras clases se simplifica las operaciones de mantenimiento como localizar dónde hay un error o ampliar la funcionalidad de nuestra aplicación agregando soporte a otras bases de datos.