oriented - oop design patterns
¿Cómo explico el acoplamiento flexible y la ocultación de información a un nuevo programador? (19)
Al igual que el paso de aplicaciones de Windows de 16 bits a 32 bits donde a los procesos se les asignó su propio espacio de direcciones. Esto detuvo cualquier otro proceso de poder matar su aplicación cuando caminó "accidentalmente" sobre sus datos.
Mover procesos a diferentes espacios de direcciones era como tratar cada proceso como una clase, y ocultar la memoria internamente y desacoplar los procesos forzando la comunicación entre procesos para que solo se produzca a través de una interfaz esperada (por ejemplo, los mensajes de Windows).
¿Cómo explico el acoplamiento flexible y la ocultación 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 los datos está separado, 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 transmitir la idea de que mantener las cosas separadas hace que sea más fácil de mantener?
Bueno, si tienes 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 lo suficientemente simple como para resolverlo 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 excesiva 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 ofrece una mejor aproximación a la herencia frente a la composición y también ofrece algunos buenos ejemplos de por qué la herencia (como dice Josh Bloch) es 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.
Creo que los conceptos OO realmente deben aprenderse de manera 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ó que realmente entendieron cómo y por qué, y tenían una idea de su importancia)
Dada su situación, esto es lo que sugeriría:
1. Haz que sigan exactamente tu 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 ejemplos, tanto de buen diseño como de 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 lograr que codifiquen bien, sin sofocar su creatividad.
Realmente no tengo mucha 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 agregar que los conceptos de OO se pueden aprender de los libros, mientras que su aplicación se puede aprender solo con la práctica. He agregado esta nota en respuesta a un comentario de Christopher W. Allen-Poole.
El problema son tus 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.
Usted 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.
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 buena para explicar la necesidad de acoplamiento flexible:
Trata de encontrar cosas como esta que entretengan y se relacionen con tu nuevo programador.
La teoría solo te llevará tan lejos.
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.
Ciertamente comprenderá las ventajas de escribir un buen código.
Los programas son sistemas de partes que interactúan.
Para que un sistema de partes 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 partes, un sistema cuyas partes están innecesariamente conectadas es más costoso que un sistema cuyas partes están necesariamente conectadas.
Las conexiones innecesarias solo pueden formarse en un sistema cuyas partes están innecesariamente expuestas a las conexiones de otras partes.
Minimizar la exposición innecesaria de piezas a la conexión desde otras partes es fundamental para el desarrollo de programas rentables.
El acoplamiento flojo y el ocultamiento de la información son los fundamentos de la minimización de la exposición de la 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 flexible y la ocultación 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 sus "Nuevos programadores" no conocen el acoplamiento flexible y la ocultación de información, entonces no lo son, "Nuevos programadores"; ellos son potenciales programadores.
Curiosamente, probablemente no ayudará decirles que lean los dos documentos originales: i) Acoplamiento flojo: ''Diseño estructurado'', por WP Stevens, GJ Myers y LL Constantine. ii) Ocultamiento de información: http://www.cs.umd.edu/class/spring2003/cmsc838p/Design/criteria.pdf
Me gusta una tarjeta de crédito como ejemplo.
Usted tiene una tarjeta de credito Una tarjeta de crédito representa su historial de crédito. 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.
Muéstrale esta presentación . Aunque se trata principalmente de DI, es francamente brillante y hasta el punto.
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 u ocultamiento de la información) se vuelve mucho más obvia.
"¿Cómo le gustaría medir la temperatura del refrigerante? ¿Mirando un medidor o metiendo el dedo en un 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? ¿Mirando un indicador o arrastrando su pie en el suelo mientras está rugiendo en la carretera?"
A partir de ahí, puede basarse en los conceptos de "su medidor de temperatura del refrigerante es un indicador. No es un líquido hirviendo", y así sucesivamente, para conceptos más complicados.
Pídale que haga un cambio, usted sabe que será difícil debido a su diseño y muéstrele cómo podría suceder eso utilizando el suyo.
Si él se queja, dígale la verdad: el negocio hará más cambios extraños, es cuestión de tiempo que lo vea.
Pregúntale si es una buena idea permitirte que tomes prestado $ 10 dándote la billetera por un momento y tomándote el dinero tú mismo.
Si está malinterpretando tus diseños, tal vez un par de sesiones de programación de pares será suficiente para ponerlos en marcha. 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.
Si haces pruebas unitarias, explícalo 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.
Simplemente no hables con él. Eso debería enseñarle sobre la ocultación de información. ;-)
Trataría de sentarme con él y trabajar con un par de códigos 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.
acoplamiento libre significa que el código externo debe usar el objeto de clase no abstracta derivada a través de una clase base abstracta. si se produce algún cambio en el conjunto de clases del que depende, entonces no es necesario cambiar en el código externo, es decir, el código externo realmente muestra un acoplamiento flojo.
Acoplamiento flojo: las partes de un reloj pueden ser reemplazadas por otras sin romper el reloj completo. Por ejemplo, puedes quitar una mano y seguirá funcionando.
Ocultar información: las manecillas del reloj no saben que detrás de ellos hay una maquinaria.
Concepto adicional
- Alta cohesión: todos los elementos en el "módulo" de reloj están fuertemente relacionados. En este escenario específico, una batería pertenecería a otro módulo o espacio de nombres.