Como você avaliaria as habilidades de design orientado a objetos? [fechadas]

que tipo de idéias ou perguntas levaria você a determinar as habilidades de OOAD de uma pessoa.

Você pode mostrar um design simples de OO de um problema simples e discutir o que ele faz, o que é bom e o que é ruim, se é flexível o suficiente, o que pode ser melhorado e como.

Se você precisar iniciar a discussão, pergunte o que a pessoa pensa sobre algum aspecto do código, mas não com uma pergunta inicial.

Importante é lembrar que a discussão é importante, não que você soubesse as respostas antes. Qualquer desenvolvedor decente deve ser capaz de apontar algo sobre o código que você nem pensava antes.

Discuta um problema de design em aberto com a pessoa. Veja como ele / ela cria o modelo do sistema, que tipo de perguntas são feitas, como o design muda em resposta a novas informações.

Um ótimo exemplo - mencionado por Steve Yegge em uma de suas postagens no blog - é pedir à pessoa que crie um modelo de objeto para XML.

Ter um bom conhecimento de todos os padrões de design mais populares pode provar que o candidato realmente procurou soluções para seus problemas de design.

Ser capaz de discuti-los e saber quando aplicá-los ou não é uma boa indicação de que ele os entende.

Pedir a ele por exemplo usos em suas experiências passadas também pode ajudar.

Não faça um teste de vocabulário. "Definir herança" ou "nomear 3 recursos do design de OO" são perguntas que não lhe dizem nada sobre as habilidades do indivíduo, apenas quanto tempo desde a última vez que ele leu um livro didático. Eu conheci vários grandes programadores que usam essas habilidades todos os dias, mas que se sufocariam se solicitados a dar a definição formal.

Solicitará que ele anote os objetos de negócios, classes e interfaces / métodos para uma sala ou qualquer outra entidade virtual

Se possível, peça um código de amostra.

Caso contrário, encontre algum código de procedimento para usar como exemplo (ou algum código OO mal projetado) e, em seguida, pergunte a eles como eles o reprojetariam, generalizariam e melhorariam. Certifique-se de que o programa tenha um contexto extra, para que o novo design possa ser significativo.

Em última análise, o que você está testando-- design-- é subjetivo. Portanto, sua avaliação deve ser aberta para permitir várias boas soluções possíveis, e não apenas uma única. Em seguida, pense em possíveis alterações nos requisitos que forçariam uma alteração na interface: como eles lidam com isso?

Leia o livro Head First Design Patterns. Todos os exemplos do livro começam com um problema orientado a objetos e acabam no padrão Design. Eles também dizem por que certos conceitos de OOP alcançarão resultados limitados e por que certos são melhores que outros.

Mesmo que um livro de Design Pattern esteja cheio de problemas do OOP :-)

Comece simples: o que é OOP?

Você pode começar perguntando sobre as premissas básicas da OOP: abstração, polimorfismo, herança e encapsulamento. Boa comida para pensar para aquecê-los.

Dê a eles um problema

Em seguida, apresente a eles um problema que provavelmente envolverá padrões. Não é necessário nomear ou usar padrões, mas sua abordagem provavelmente renderá alguns se tiverem experiência na área.

Talvez validação dinâmica de entrada de texto. Você gostaria de poder validar o caractere de entrada por caractere para ver se é uma data, hora ou data e hora válidas no formato ISO8601. Você obtém uma cópia da sequência de entrada toda vez que uma tecla é pressionada e pode retornar um booleano para indicar se o texto permanece bom em pelo menos um dos formatos. Peça-lhes para conversar e esboçar um design usando os princípios de design OO.

Quando você termina de conversar sobre

1. Controlador (aquele que aciona os eventos de mudança e avalia as respostas),
2. Observador (os validadores respondem aos eventos de mudança),
3. Estratégia (cada validador representa uma maneira diferente de determinar se a entrada é válida),

então você terá uma boa idéia se eles entenderem OOD.

Dê a eles o mesmo problema novamente, mas desta vez peça um design diferente

Agora, peça que eles redesenhem o sistema sem usar um padrão Observador (se o mencionaram) - eles podem optar por uma abordagem da Cadeia de Responsabilidade ou talvez um padrão de Comando. Você realmente não se importa com isso, sabe que eles têm uma compreensão razoável dos princípios envolvidos.

Mesmo que eles não adotem uma abordagem baseada em padrões, apenas ouvir a maneira como eles tentam dividir o problema em sua funcionalidade relacionada produzirá os resultados que você procura.

Costumo escolher um cenário do mundo real, algo bem conhecido por qualquer pessoa † e pedir que identifiquem as entidades; os atores envolvidos; que interações existem entre eles; onde características comuns poderiam ser abstraídas; quais propriedades precisam ser consideradas.

Sim, você pode pedir para eles se sentarem e desenharem UML, sim, você pode fazer perguntas sobre algumas especificações específicas de implementação de OOP para ver se elas podem "dar o fora".

Mas o que um empregador realmente precisa dentro de sua equipe é uma mente que entenda os conceitos envolvidos e possa aplicá-los ao que aparecer. Os detalhes podem ser aprendidos rapidamente, quando os conceitos são incorporados.

† Familiaridade profunda e ausência de conexão com o código ajudam: o uso de um banheiro pela família pela manhã; fazendo o jantar; uma linha de ônibus para o trabalho; a montagem de um carro.

Algo que parece funcionar bastante bem e na verdade leva apenas alguns segundos: peça para que eles projetem um modelo de objeto. Não importa para quê. Pode ser absolutamente trivial. De fato, provavelmente deve ser trivial não arrastar o teste desnecessariamente.

Se a primeira coisa que escrevem é um objeto, eles já estão à frente de 99% de seus pares no entendimento do OO. Se a primeira coisa que escreverem for uma aula, peça-lhes que saiam e mandem o próximo candidato, e reflitam sobre o motivo pelo qual se chama OOP e não COP.