¿Cómo evaluaría las habilidades de diseño orientado a objetos? [cerrado]

qué tipo de ideas o preguntas lo llevarían a determinar las habilidades OOAD de una persona.

Podría mostrar un diseño OO a medias de un problema simple y discutir qué hace, qué tiene de bueno y qué tiene de malo, si es lo suficientemente flexible, qué podría mejorarse y cómo.

Si necesita iniciar la discusión, pregunte qué piensa la persona sobre algún aspecto del código, pero no con una pregunta principal.

Es importante recordar que la discusión es importante, no que supieras las respuestas de antemano. Cualquier desarrollador decente debería ser capaz de señalar algo sobre el código que ni siquiera había pensado antes.

Discuta un problema de diseño abierto con la persona. Vea cómo procede a construir un modelo del sistema, qué tipo de preguntas se le hacen, cómo cambia el diseño en respuesta a la nueva información.

Un gran ejemplo, mencionado por Steve Yegge en una de sus publicaciones de blog, es pedirle a la persona que presente un modelo de objetos para XML.

Tener un buen conocimiento de todos los patrones de diseño más populares puede demostrar que el candidato realmente buscó soluciones a sus problemas de diseño.

Ser capaz de discutirlos y saber cuándo aplicarlos o no es una buena indicación de que los comprende.

Pedirle, por ejemplo, usos en sus experiencias pasadas también puede ayudar.

No des un examen de vocabulario. "Definir herencia" o "nombrar 3 características del diseño OO" son preguntas que no le dirán nada sobre las habilidades del individuo, sino cuánto tiempo desde la última vez que leyó un libro de texto. Conocí a varios programadores excelentes que usan estas habilidades todos los días, pero se ahogarían si se les pidiera dar la definición formal.

Le pedirá que escriba los objetos de negocios, clases e interfaces / métodos para una sala o cualquier otra entidad virtual.

Si es posible, solicite un código de muestra.

De lo contrario, busque algún código de procedimiento para usar como ejemplo (o algún código OO mal diseñado) y luego pregúnteles cómo lo rediseñarían, generalizarían y mejorarían. Asegúrese de que el programa tenga un contexto adicional, de modo que el rediseño pueda ser significativo.

En última instancia, lo que está probando, el diseño, es subjetivo. Por lo tanto, su evaluación debe ser abierta para permitir varias buenas soluciones posibles, y no solo una. Luego, piense en los posibles cambios en los requisitos que obligarían a un cambio de interfaz: ¿cómo lo manejan?

Lea el libro Head First Design Patterns. Todos los ejemplos en el libro comienzan con un problema orientado a objetos y terminan en el patrón de diseño. También explican por qué ciertos conceptos de OOP lograrán resultados limitados y por qué ciertos son mejores que otros.

A pesar de ser un libro de Patrones de diseño, este libro está lleno de problemas de OOP :-)

Comience simple: ¿de qué se trata OOP?

Puede comenzar preguntando sobre las premisas básicas de la POO: abstracción, polimorfismo, herencia y encapsulación. Buena comida para pensar para calentarlos.

Darles un problema

Luego, presénteles un problema que probablemente involucre patrones. No es necesario nombrar o usar patrones, pero su enfoque probablemente producirá algo si tienen experiencia en el área.

Quizás validación dinámica de entrada de texto. Le gustaría poder validar el carácter de entrada por carácter para ver si es una fecha, hora o fecha y hora válidas en formato ISO8601. Obtiene una copia de la cadena de entrada cada vez que se presiona una tecla y puede devolver un booleano para indicar si el texto sigue siendo bueno en al menos uno de los formatos. Pídales que hablen y esbocen un diseño usando los principios de diseño OO.

Para cuando hayas terminado de hablar sobre

1. Controlador (esa cosa que dispara los eventos de cambio y evalúa las respuestas),
2. Observador (los validadores responden a los eventos de cambio),
3. Estrategia (cada validador representa una forma diferente de determinar si la entrada es válida),

entonces tendrás una muy buena idea si entienden OOD.

Vuelva a darles el mismo problema, pero esta vez pídales un diseño diferente.

Ahora, pídales que rediseñen el sistema sin usar un patrón de Observador (si lo mencionaron); pueden optar por un enfoque de Cadena de Responsabilidad o tal vez un patrón de Comando. Realmente no te importa cuál, sabes que tienen una comprensión razonable de los principios involucrados.

Incluso si no adoptan un enfoque basado en patrones, solo escuchar la forma en que intentan dividir el problema en su funcionalidad relacionada arrojará los resultados que busca.

Tiendo a elegir un escenario del mundo real, algo bien conocido por cualquiera † y pedirles que identifiquen las entidades; los actores involucrados; qué interacciones hay entre ellos; donde las características comunes podrían ser abstraídas; qué propiedades deben considerarse.

Sí, podría pedirles que se sienten y dibujar UML, sí, podría hacerles preguntas de búsqueda sobre algunos detalles de implementación de OOP para ver si pueden "comenzar a ejecutar".

Pero lo que un empleador realmente necesita dentro de su equipo es una mente que comprenda los conceptos involucrados y pueda aplicarlos a lo que resulte. Los detalles se pueden aprender rápidamente, cuando los conceptos están integrados.

† Familiaridad profunda y ausencia de una conexión con el código de ayuda: el uso de un baño por parte de una familia por la mañana; cocinando la cena; una ruta de autobús al trabajo; El montaje de un automóvil.

Algo que parece funcionar bastante bien, y en realidad solo toma unos segundos: pídales que diseñen un modelo de objetos. No importa para qué. Puede ser absolutamente trivial. De hecho, probablemente debería ser trivial, no arrastrar la prueba innecesariamente.

Si lo primero que escriben es un objeto, ya están por delante del 99% de sus pares en su comprensión de OO. Si lo primero que escriben es una clase, pídales amablemente que salgan y envíen al próximo candidato y que contemplen por qué se llama OOP y no COP.