POO–Responsabilidades

“Hay una diferencia entre programar orientado a objetos y pensar orientado a objetos”

CNX-B4WDebatiendo hoy en el trabajo sobre la funcionalidad que debería tener una toolsbox, salió uno de esos temas que me encantan. ¿Dónde debe estar el código asociado a un clic de un botón?

Responsabilidades

Mucho más allá de si la pregunta se responde aplicando un Chain of Responsibility Pattern, dentro se esconde uno de los pilares de la POO, la Especialización. Los objetos mientras mayor sea su especialización, mejor podremos definir su comportamiento.

¿Qué quiere decir esto? Pues que la responsabilidad de cada objeto debe ser solo, la que permita cumplir los objetivos por el cual fue creado.

Un avión vuela (por suerte). Nosotros desde fuera vemos un conjunto, pero dentro del avión hay miles de objetos que tienen una responsabilidad específica y que entre todos, hace que el avión vuele. Creo que excepto en las teles de la antigua URSS (le quitabas piezas y seguían funcionando), todo objeto tiene una responsabilidad que permite lograr una funcionalidad superior.

¿Que es una toolsbox? pues un panel de botones y nada más. Cuando compramos un panel de botones este no incluye para qué se usa cada botón o qué hace cada botón. Si compramos un interruptor eléctrico, este por si solo no apaga ni enciende la luz, incluso, puede llegar a realizar funciones explosivas si conectas incorrectamente los cables (que me pregunten a mi con 11 años la que lié).

Nuestra toolsbox, tiene botones (como casi todas) y el objetivo que cumplirá cada botón debería ser independiente a la misma. Un botón “dentro de la toolsbox” tiene estados cuyos cambios son notificados al exterior para quien quiera hacer algo que lo haga.

Lo mismo pasa con nuestro avión, mueves los mandos de vuelo y giras, esto no ocurre porque las aletas y el mando sean un único e inseparable objeto, sino porque el mando cambia de estado y notifica a todo aquel que pueda estar interesado para que haga algo. Las aletas y seguramente muchos objetos más dentro de un avión, están escuchando continuamente para saber si los mandos de vuelo han cambiado de posición(estado).

Vean que para definir cual debe ser la responsabilidad de mi  toolsbox, me he basado en todo momento en ejemplos de la vida real.

En el evento que di sobre POO en SecondNug (aquí tenéis los apuntes) cuando se analizaba la crisis del software, se definió como objetivo de la programación orienta a objetos el acercamiento del ordenador al problema y no del problema al ordenador, lo cual significa que debemos intentar en todo momento modelar los problemas existentes en la vida real analizándolo como lo que son, cosas que ocurren en la realidad. Esto era y seguramente aún es, el paradigma de la POO.

El otro día leía un artículo de Eduard sobre knockout y había una línea de texto que decía: «el código javascript es totalmente ignorante del DOM y trabaja tan solo con el viewmodel. Separación de responsabilidades.” ¡Atentos! que en este artículo se habla de separar la responsabilidad entre el HTML y el Javascript… (si digo yo esto en una entrevista de trabajo hace unos años, ya me dirán ustedes que hubieran pensado de mi)

Seguramente hoy por hoy aún queda mucho por hacer, pero da gusto como cada vez más intentamos llevar a la más mínima expresión la separación de responsabilidades. Mi opinión es que mientras menor sea la responsabilidad de un objeto, siempre que cumpla su objetivo, mejor y más fácil será de mantener.

Por cierto, para no dejarles sin saber, la toolsbox terminó con N botones que no saben lo que hacen pero que notifican a quien pueda interesar los estados de onBeforeClick y onClick. (espero no ser yo quien tenga que conectarla) Sonrisa

Salu2

4 comentarios sobre “POO–Responsabilidades”

  1. Lo malo es que algunas veces pecamos de ir colocando mas capas que contradictoriamente hacen mas complicado el saber como funciona el asunto

  2. Hola @ecardenas, gracias por el comentario.. 😉

    Yo creo que esa justificación es muy usada cuando iniciamos un proyecto. ¿por qué separar esto si al final se entiende bien y es solo un «if»?

    El problema es que hoy en día nunca sabemos dónde terminará un proyecto, los clientes piden cambios todos los días y complican la funcionalidad minuto a minuto. Tenía un profesor que me decía que un proyecto pequeño es un proyecto grande que acaba de nacer.

    El @bruno puso un día algo parecido… beta v0.1, beta v0.2, marrón v1.0….

    Al final hoy es un simple «if» por el que no vale la pena separar las responsabilidades, mañana es otro, luego otro y otro y otro… y cada vez te cuesta más hacerlo como es debido por la cantidad de cambios que implica… 🙂

    Es solo mi opinión eh, también puedo equivocarme.. 🙂

    Salu2

  3. Hola @ecardenas…

    bueno, primero que todo no quisiera q pienses que estoy intentando cambiar tu manera de pensar, el mundo de los informáticos es una gran biblioteca con eso de que cada cual tiene 1 librito.. 🙂

    Yo vengo de C, C++ y todo lo que hay de por medio hasta llegar a NET.. de cuando había que hacer «ventanas» con caracteres especiales sobre MS-DOS y la programación era totalmente lineal.

    En todo ese tiempo, si he llegado a esta manera de pensar ha sido más por golpes que por las tendencias. Estoy de «acuerdo» en lo que planteas en tu blog, pero de la misma manera q me comentabas q los extremos son malos, creo que los supuestos q planteas van muy al extremo 🙂

    Difícilmente se tenga que cambiar de SQL Server a Oracle u otro gestor, ni se desarrolla pensando si mañana me van a pedir que mi app funcione en un iPad (también hay casos en que sí) pero hay muchos «casos de uso» antes de llegar a ese punto q cambian continuamente (esto es una realidad) porque no hay proyecto q no cambie sus especificaciones desde que se empieza hasta que se termine.

    El segundo post plantea un error, desde mi punto de vista, muy común. El concepto de tener interfaces no es para poder crear Mocks, esa es una de las ventajas. El verdadero objetivo es hacer algo sin estar «atado» al cómo se hace… si lo piensas, tu cuando envías un SMS solo escribes el texto y das enviar. ¿Qué hay detrás de todo eso? No lo sabes y tampoco te preocupa. ¿Cuantas veces eso ha cambiado sin tu saberlo? No lo sabes y no te preocupa, eso sí… tu sigues enviando SMS como el primer día.. 🙂

    Si tienes un error en tu código «repleto de DI», seguramente te faltará un test. En el caso del blog se debería crear un Mock sobre el servicio para «testear» los controladores, pero también debería existir un Mock sobre la unidad de trabajo para «testear» los servicios, ya con esto cubres tu código porque el error no te saltará en el controlador sino en los servicios.

    Es verdad que seguir la lógica de todo el código cuesta, pero ¿en realidad quieres seguir la lógica de todo el código? Volvemos al SMS, ¿de verdad quieres saber cómo funcionan las telefónicas cuando envías un SMS? Tu solo quieres poder enviar y listo, a que sí.. 🙂

    Salu2

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *