回答:
オープンエンドの設計問題について人と話し合ってください。システムのモデルを構築する方法、尋ねられる質問の種類、新しい情報に応じて設計がどのように変化するかを確認します。
Steve Yeggeが彼のブログ投稿の1つで言及した素晴らしい例は、XMLのオブジェクトモデルを考え出すように依頼することです。
最も人気のあるすべての設計パターンを熟知していれば、候補者が設計問題の解決策を実際に検索したことを証明できます。
それらを議論し、それらをいつ適用するかを知ることができるということは、彼がそれらを理解している良い兆候です。
彼の過去の経験での使用例を尋ねることも役立つかもしれません。
本Head First Design Patternsを読んでください。本のすべての例は、オブジェクト指向の問題から始まり、デザインパターンで終わります。また、特定のOOPの概念が限られた結果を達成する理由と、特定のOOPの概念が他より優れている理由も示しています。
デザインパターンの本ですが、この本はOOPの問題でいっぱいです:-)
簡単に始めましょう：OOPとは何ですか？
まず、OOPの基本的な前提である抽象化、ポリモーフィズム、継承、カプセル化について尋ねることから始めます。それらを暖めるための思考のための良い食べ物。
彼らに問題を与える
次に、パターンを含む可能性が高い問題を提示します。パターンに名前を付けたり、パターンを使用したりする必要はありませんが、その分野での経験があれば、そのアプローチはおそらくいくらかをもたらします。
おそらく動的テキスト入力検証。入力文字を文字ごとに検証して、それが有効な日付、時刻、またはISO8601形式の日付と時刻であるかどうかを確認できるようにします。キーが押されるたびに入力文字列のコピーを取得し、少なくとも1つの形式でテキストが良好であるかどうかを示すブール値を返すことができます。OOの設計原則を使用して、設計について話し合い、スケッチするよう依頼します。
チャットを終えるまでに
彼らがOODを理解していれば、かなり良いアイデアが得られます。
もう一度同じ問題を与えますが、今回は別のデザインを要求します
次に、Observerパターンを使用せずにシステムを再設計するように依頼します（言及されている場合）-Chain of Responsibilityアプローチまたはコマンドパターンを選択できます。あなたは本当に気にしません、あなたは彼らが関係する原則を合理的に把握していることを知っています。
パターンベースのアプローチを採用していなくても、問題を関連する機能に分解しようとする方法を聞くだけで、目的の結果が得られます。
私は誰にでもよく知られている現実世界のシナリオを選択する傾向があります†。関係する俳優。それらの間にはどのような相互作用がありますか？共通の機能を抽象化できる場所。考慮すべきプロパティ。
はい、座ってUMLを描画するように依頼することができます。はい、OOP実装の詳細に関する質問を検索して、「すぐに実行できる」かどうかを確認できます。
しかし、雇用主がチーム内で本当に必要としているのは、関係する概念を理解し、それらを最終的に適用できる心です。概念が組み込まれていると、仕様をすばやく学習できます。
†深い知識とコードヘルプとのつながりがない：家族が朝にバスルームを使用する。夕食を作る。仕事へのバス路線; 車の組み立て。
かなりうまくいくようで、実際には数秒しかかからないもの：オブジェクトモデルの設計を依頼します。それは何でも構いません。それは絶対に些細なことです。実際、テストを不必要に引き出さないために、おそらく簡単なはずです。
彼らが最初に書くものがオブジェクトである場合、彼らはすでにオブジェクト指向の理解において同業者の99％より先にいます。彼らが最初に書くのがクラスの場合、親切に彼らに出かけ、次の候補者を送ってもらい、なぜそれがCOPではなくOOPと呼ばれるのかを考えてください。