Come valuteresti le abilità di progettazione orientata agli oggetti? [chiuso]

Potresti mostrare un design OO semi-assente di un problema semplice e discutere cosa fa, cosa è buono e cattivo in merito, se è abbastanza flessibile, cosa potrebbe essere migliorato e come.

Se hai bisogno di portare avanti la discussione, chiedi cosa pensa la persona su alcuni aspetti del codice, ma non con una domanda principale.

È importante ricordare che la discussione è importante, non che tu conoscessi le risposte in anticipo. Qualsiasi sviluppatore decente dovrebbe essere in grado di indicare qualcosa sul codice che non avevi nemmeno pensato prima.

Discutere di un problema progettuale aperto con la persona. Guarda come procede a costruire un modello del sistema, che tipo di domande vengono poste, come cambia il design in risposta alle nuove informazioni.

Un grande esempio - citato da Steve Yegge in uno dei suoi post sul blog - è chiedere alla persona di creare un modello a oggetti per XML.

Avere una buona conoscenza di tutti i più modelli di design può dimostrare che il candidato ha effettivamente cercato soluzioni ai suoi problemi di progettazione.

Essere in grado di discuterli e sapere quando applicarli o meno è una buona indicazione che li capisce.

Anche chiederlo a lui come esempio nelle sue esperienze passate può essere d'aiuto.

Non fai un quiz sul vocabolario. "Definisci l'ereditarietà" o "Le funzionalità del nome 3 di progettazione OO" sono domande che non ti diranno nulla sulle capacità dell'individuo, ma solo da quanto tempo ha letto l'ultima volta un libro di testo. Ho incontrato molti grandi programmatori che usano queste abilità ogni giorno, ma si sentirei soffocati se gli fosse chiesto di dare una definizione formale.

Gli chiederà di scrivere gli oggetti di business, le classi e le interfacce / metodi per una stanza o qualsiasi altra entità virtuale

Se possibile, chiedi il codice di esempio.

Altrimenti, trova un codice procedurale da usare come esempio (o un codice OO mal progettato), quindi chiedi loro come ridisegnarlo, generalizzarlo e migliorarlo. Assicurati che il programma abbia un contesto extra, in modo che la riprogettazione possa essere significativa.

In definitiva ciò che stai testando-- il design-- è soggettivo. Pertanto, la tua valutazione dovrebbe essere aperta per consentire diverse possibili buone soluzioni, e non solo una singola. Quindi, pensa a possibili modifiche ai requisiti che potrebbero imporre un cambio di interfaccia: come gestiscono?

Leggi il libro Head First Design Patterns. Tutti gli esempi nel libro iniziano con un problema orientato agli oggetti e finiscono nel modello di progettazione. Dicono anche perché alcuni concetti di OOP raggiungono risultati limitati e perché alcuni sono migliori di altri.

Anche se un libro di design pattern questo libro è pieno di problemi di OOP: -)

Inizia semplice: cos'è OOP?

Potresti iniziare chiedendo le premesse di base di OOP: astrazione, polimorfismo, ereditarietà e incapsulamento. Buon cibo per il pensiero per farli scaldare.

Dai loro un problema

Successivamente, presenta loro un problema che probabilmente coinvolgerà i pattern. Non è necessario nominare o utilizzare i pattern, ma il loro approccio probabilmente ne fruttterà alcuni se hanno esperienza nell'area.

Forse la validazione dell'input di testo dinamico. Ti piacerebbe essere in grado di convalidare il carattere di input per carattere per vedere se è una data, ora o data e ora valide nel formato ISO8601. Si ottiene una copia della stringa di input ogni volta che si preme un tasto e si può restituire a booleano per indicare se il testo rimane valido almeno in uno dei formati. Chiedi loro di parlare e di delineare un progetto usando i principi di progettazione OO.

Quando hai finito di chattare su

1. Controller (quella cosa che attiva gli eventi di modifica e valuta le risposte),
2. Observer (i validatori rispondono agli eventi di modifica),
3. Strategia (ogni validatore rappresenta un modo diverso per determinare se l'input è valido),

allora avrai una buona idea se capiscono l'OOD.

Dai loro di nuovo lo stesso problema, ma questa volta chiedi un design diverso

Ora, chiedi loro di ridisegnare il sistema senza usare un pattern Observer (se lo menzionano) - possono scegliere di optare per un approccio Chain of Responsibility o forse un pattern Command. Non ti interessa davvero quale, sai che hanno una ragionevole comprensione dei principi coinvolti.

Anche se non optano per un approccio basato su pattern, solo ascoltando il modo in cui tenta di rompere il problema nella sua relativa funzionalità produrrà i risultati che stai cercando.

Tendo a scegliere uno scenario del mondo reale, qualcosa di ben noto a chiunque † e chiedo loro di identificare le entità; gli attori coinvolti; quali interazioni ci sono tra loro; dove le caratteristiche comuni potrebbero essere astratte; quali proprietà devono essere considerate.

Sì, potresti chiedere loro di sedersi e disegnare UML, sì si potrebbe chiedere loro di cercare domande su alcune specifiche di implementazione OOP per vedere se possono "andare a fondo".

Ma ciò di cui un datore di lavoro ha realmente bisogno all'interno del proprio team è una mente che comprende i concetti coinvolti e li può applicare a qualsiasi risultato. I dettagli possono essere appresi rapidamente, quando i concetti sono incorporati.

† Profonda familiarità e assenza di una connessione con l'aiuto del codice: L'uso di un bagno da parte della famiglia al mattino; cucinando la cena; una linea di autobus per lavorare; il montaggio di una macchina.

Qualcosa che sembra funzionare piuttosto bene, e in realtà richiede solo pochi secondi: chiedi loro di progettare un modello a oggetti. Non importa per cosa. Può essere assolutamente banale. In effetti, probabilmente dovrebbe essere banale, non trascinare il test inutilmente.

Se la prima cosa che scrivono è un oggetto, sono già davanti al 99% dei loro pari nella loro comprensione di OO. Se la prima cosa che scrivono è una classe, chiedi loro di uscire e inviare il prossimo candidato, e pensa al motivo per cui si chiama OOP e non COP.