¿Cómo explico el acoplamiento suelto y la ocultación de información a un nuevo programador?

Question

¿Cómo explico el acoplamiento suelto y el ocultamiento de información a un nuevo programador? Tengo un programador para el que escribo diseños, pero que parece que no comprende los conceptos de acoplamiento flexible y ocultamiento de información.

Escribo diseños con todo muy bien desglosado en clases por función (el acceso a datos es independiente, una clase para solicitudes, un controlador, aproximadamente 5 clases en total). Vuelven con un diseño modificado donde la mitad de las clases heredan de la otra mitad (y no hay una relación "is-a") y muchas variables públicas.

¿Cómo puedo entender la idea de que mantener las cosas separadas hace que sea más fácil de mantener?

Answer 1

La mejor manera de explicar este tipo de conceptos es usar analogías. Elija algo que no esté relacionado con la programación y utilícelo para explicar los conceptos de diseño abstracto.

La siguiente imagen es bastante bueno para explicar la necesidad de la articulación flexible:

tratar de llegar con este tipo de cosas que divertirá y pertenecer a su nuevo programador.

Answer 2

Theory solo le llevará hasta ahora.

Haz que intente agregar nuevas funciones al código que escribió hace un tiempo. Luego, vuelva a trabajar con el código anterior para que esté ligeramente acoplado y pídale que agregue las mismas características.

Definitivamente comprenderá las ventajas de escribir un buen código.

Answer 3

Pregúntale si es una buena idea permitirte pedir prestado $ 10 dándote la billetera por un momento y tomándote el dinero tú mismo.

Answer 4

Muéstrelo this presentation. Aunque se trata principalmente de DI, es francamente brillante y hasta el punto.

Answer 5

Trataría de sentarme con él y trabajar con un par de piezas de código con él mirando por encima de tu hombro y explicando por qué estás haciendo lo que haces a medida que avanzas. He encontrado que esta es normalmente la mejor manera de explicar las cosas.

Answer 6

Bueno, si tiene que explicárselo, me veo obligado a preguntar: ¿son realmente un programador?

Diles que necesitan una "universidad do over"?

Eso es difícil porque es un concepto tan básico. Personalmente, no me gustaría manejarlo porque es como que a alguien le pagan por aprender cosas que ya debería saber, pero la vida no siempre es ideal.

Lo abordaría al encontrar un problema que es bastante simple de resolver relativamente simple. Las variables públicas generalmente se manejan mejor tratando de encontrar el origen de un problema cuando no se puede ver qué es lo que cambia las variables. Puede diseñar un escenario para eso.

La herencia en exceso puede no ser su culpa. Es posible que hayan aprendido en un curso diseñado en los años 90 que está atrapado en la idea de que "todo debe heredar". Recuerdo los ejemplos anteriores de Manager extends Employee. Es MALO. La cosa es que las personas se enseñan estas tonterías. Todavía.

Para C++ la serie Scott Meyer Effective C++ probablemente valga la pena ponérselos (suponiendo que les moleste leer algo). Para Java, Effective Java de Josh Bloch ("composición de favor") está en la misma línea. No estoy seguro de C#.

Este tipo de libros dan un mejor enfoque a la herencia frente a la composición y también dan algunos buenos ejemplos de por qué la herencia es (como lo dice Josh Bloch) un "detalle de implementación". También he escuchado que se describe como "herencias rompe la encapsulación".

Vi un buen ejemplo una vez de herencia vs composición con la ampliación de las capacidades de una lista en Java y cómo la herencia requería que usted supiera los detalles de implementación del padre para hacer la corrección correcta mientras que la composición no. Veré si puedo encontrarlo.

Answer 7

Pídale que haga un cambio que usted sepa que será difícil debido a su diseño y muéstrele cómo podría hacerlo utilizando el suyo.

Si se queja, dígale la verdad: el negocio le pedirá cambios más extraños, es cuestión de tiempo que lo vea.

Answer 8

El problema es sus expectativas, no los desarrolladores carecen de habilidad. Usted habla de acoplamiento flexible y ocultamiento de información como si se tratara de hechos simples o técnicas mecánicas, no lo son. El desarrollo de software es un arte y la única forma de mejorar en una nave es practicarla y mejorar lenta y gradualmente.

Está buscando un atajo. ¿Quieres que el desarrollador experimente un "¡Ajá!" momento y de repente ver la sabiduría en su diseño. Yo digo, no contengas la respiración.

Adopta la mentalidad de un mentor. Si quieres que mejore sus habilidades de diseño, ¡no le "entregues" un diseño, deja que lo diseñe! Luego revise el diseño con él. Esto le dará experiencia, un sentido más profundo de pertenencia y más disposición para escuchar sus sugerencias antes de que se involucre profundamente en la implementación.

Un lado: observo que las personas buscan estos atajos todo el tiempo con habilidades abstractas pero no con más habilidades "físicas". Tome tenis, por ejemplo. Si fueras entrenador de tenis y un nuevo jugador siguiera golpeando largamente sus diestros, no solo le mostrarías un video de YouTube de un golpe de derecha de Roger Federer y esperarías que lo "entendiera". Un gran golpe de derecha toma AÑOS de experiencia a medida que aprendes el sentimiento y lo usas en diferentes escenarios: no es tu aprendizaje muscular, sino tu cerebro. No es diferente con el diseño de software. Te vuelves bueno haciéndolo una y otra vez. Poco a poco aprende de sus errores y mejora al apreciar las consecuencias de cada decisión de diseño individual.

Answer 9

Si realiza pruebas unitarias, explíquelo en términos de escritura de prueba. Alternativamente, las Clases abstractas y las Interfaces usan el acoplamiento flexible y la ocultación de información con gran efecto. Si se lo explica en términos de otros conceptos que ya puede manejar, será más probable que aprecie el concepto rápidamente.

Answer 10

Creo que los conceptos de OO realmente se deben aprender de forma práctica. Uno realmente necesita hacer estas cosas para entender. Voy a la escuela (ingeniería) y la mayoría de mis compañeros realmente no entienden el concepto. Ellos saben en general que el acoplamiento flojo es "bueno" pero no por qué. Tampoco saben cómo lograr un acoplamiento flojo. Ahora estoy trabajando en mi proyecto de último año y los llegué a formar parte del proceso de diseño.(Ayudó el que realmente entendían cómo y qué y tenía una idea de su importancia)

Dada su situación, esto es lo que sugeriría:
1. Hacer que se siguen exactamente su diseño (al menos por un par de semanas). Si quieren desviarse, pídales que discutan qué y por qué con usted. [Las limitaciones de tiempo pueden no permitir esto].
2. Siéntese con ellos en cualquier parte del diseño que esté haciendo a continuación y explique algunas de sus elecciones de diseño, con ejemplos. Algunas cosas que son obvias para usted pueden necesitar que se las señale.
3. Esté atento a los ejemplos, tanto de buen diseño como mal diseño y muéstreles cómo funciona mejor.

La tarea más importante aquí es la delegación. Tienes que mostrarles cómo es el buen código, tal vez entrenarlos por un par de horas. Luego, acuerda cuándo revisar y cómo puede ayudarlos (dentro de su tiempo libre limitado (?)) A hacer bien la tarea. Lo principal es lograr que se identifiquen y comprendan un buen diseño. Hacer estas cosas los ayudará a 'comprar' el diseño. Una vez que sientan que es su diseño, estoy seguro de que harán un mejor trabajo.

En general, creo que necesitas ponerte de pie y hacer que lo codifiquen correctamente, sin sofocar su creatividad.

Realmente no tengo demasiada experiencia en el área. Solo estoy dando mi opinión sobre el tema, en función de lo que funcionó para mí. Espero que esto ayude.

Nota
me gustaría añadir que los conceptos orientados a objetos se pueden aprender de libros, mientras que su aplicación sólo puede aprenderse por la práctica. He agregado esta nota en respuesta a un comentario de Christopher W. Allen-Poole.

Answer 11

No hay nada como una analogía física. Ve a tu auto y señala cómo todo lo complicado, caliente y peligroso está bastante aislado del frágil humano. Siéntese en el asiento del conductor y señale algunos de los medidores importantes; por ejemplo, la temperatura del refrigerante, el tacómetro y el velocímetro. Observe cómo los medidores son notablemente similares: todos toman un valor escalar (de algún lugar) y lo representan moviendo una aguja a una posición entre min y max.

Sin embargo, si piensas en lo que se está midiendo, la fuerte motivación para mantener ese aislamiento (también conocido como acoplamiento débil o ocultamiento de información) se vuelve mucho más obvia.

• "¿Cómo le gustaría para medir la temperatura del refrigerante? La consulta de un calibre o por meter el dedo en el líquido casi hirviendo?"

• "¿Cómo le gustaría medir la velocidad de rotación del motor? Al mirar un indicador o al dejar que un cigüeñal de varios miles de revoluciones raspe la carne de sus huesos mientras intenta calcularla a mano?"

• "¿Cómo le gustaría medir la velocidad del automóvil? Al mirar un indicador o al arrastrar el pie en el suelo mientras está rugiendo por la carretera?"

A partir de ahí, se puede construir sobre los conceptos de "el indicador de temperatura del líquido refrigerante es - una galga. Se NO ES-un líquido hirviendo" y así sucesivamente con los conceptos más complicados.

Answer 12

Simplemente no hable con él. Eso debería enseñarle sobre la ocultación de información. ;-)

Answer 13

Me gusta una tarjeta de crédito como ejemplo.

Usted tiene una tarjeta de crédito. Una tarjeta de crédito representa su historial crediticio. Tiene un equilibrio y una APR. Tiene permisos y un estado financiero completo. Tiene una identificación, una fecha de vencimiento y un código de seguridad. La banda magnética resume todo esto.

Cuando vaya a su establecimiento local que acepta tarjetas de crédito, no es necesario que lo sepa. No quieren saber eso, y a menudo es muy peligroso si lo saben. Lo que necesitan "saber" es que hay una banda magnética que se encargará de todo esto, y (a veces) que la persona que tiene la tarjeta tiene una identificación para que coincida con el nombre impreso en la tarjeta.

Darles más información es (en el mejor de los casos) inútil, o (en el peor de los casos) peligroso. Exigirles que sepan con qué banco consultar, asegurarse de que sepan cómo calcular su APR particular o permitirles que revisen su saldo es simplemente una tontería en ese momento.

Answer 14

Missing in Action: Information Hiding, por Steve McConnell

Answer 15

Si él está interpretando mal sus diseños, tal vez un par de pares de programación sesiones será suficiente para conseguir que en el camino. Tengo que estar de acuerdo con @ThomasD y lo ampliaré; la encapsulación que está pasando aquí podría ser usted. Podría ser un simple caso de mala interpretación en lugar de que ellos no entiendan los conceptos.

Answer 16

Los programas son sistemas de piezas que interactúan.

Para que un sistema de piezas interactuantes funcione conjuntamente, se requieren conexiones entre estas partes.

Cuantas más conexiones, más costoso es el programa.

Para un número fijo de piezas, un sistema cuyas piezas se conectan innecesariamente es más costoso que un sistema cuyas partes están necesariamente conectadas.

Las conexiones innecesarias solo se pueden formar en un sistema cuyas piezas están innecesariamente expuestas a las conexiones de otras partes.

Minimizar la exposición innecesaria de piezas a la conexión de otras partes es fundamental para el desarrollo de programas rentables.

El acoplamiento flojo y el ocultamiento de información son los fundamentos de la minimización de exposición de conexión.

Esto no es un conocimiento opcional para un programador.

Esto es fundamental.

No puede ser un programador consciente de los costos sin este conocimiento.

Preguntar cómo explicar el acoplamiento flojo y el ocultamiento de información a un nuevo programador es como preguntar cómo explicar la cirugía a un nuevo cirujano. ¿O para explicar la arquitectura a un nuevo arquitecto? O cómo explicar volar a un piloto.

Si su 'Nuevos programadores' no conoce el acoplamiento libre y la ocultación de información, entonces no lo son, 'Nuevos programadores'; ellos son potenciales programadores.

Curiosamente, probablemente no ayude decirles que lean los dos documentos originales: i) Acoplamiento flojo: 'Diseño estructurado', por W.P. Stevens, G.J. Myers y L.L. Constantine. ii) Ocultamiento de información: http://www.cs.umd.edu/class/spring2003/cmsc838p/Design/criteria.pdf

Answer 17

Al igual que el paso de aplicaciones de Windows de 16 bits a 32 bits donde los procesos tenían su propio espacio de direcciones. Esto detuvo cualquier otro proceso de poder matar su aplicación cuando caminó "accidentalmente" sobre sus datos.

Moving procesos a diferentes espacios de direcciones era como el tratamiento de cada proceso como una clase, y ocultar la memoria interna y desacoplamiento los procesos forzando la comunicación entre procesos a pasar sólo a través de una interfaz esperada (por ejemplo, mensajes de Windows).

Answer 18

• acoplamiento flojo: Las partes de un reloj podrán ser sustituidos por otros con el arranque de todo el reloj. Por ejemplo, puedes quitar una mano y seguirá funcionando.

• Ocultar información: Las manecillas del reloj no saben que detrás de ellas hay una maquinaria.

concepto adicional

• alta cohesión: Todos los elementos en el "módulo" reloj están fuertemente relacionados. En este escenario específico, una batería pertenecería a otro módulo o espacio de nombres.

Answer 19

acoplamiento libre significa que el código externo debe usar el objeto de la clase no abstracta derivada a través de la clase base abstracta. si se produce algún cambio en el conjunto de clase del que depende, entonces no es necesario cambiar en el código externo, es decir, el código externo realmente muestra un acoplamiento flojo.