UIコンポーネントがデータ構造であってはならない理由を説明しようとしている別のプログラマーがいます。
たとえば、「データベース」からレコード セットを含むデータ構造を取得し、そのレコード セットをアプリケーション内の UI コンポーネントに表示したいとします。
このプログラマー (彼は無名のままで、彼は若く、私は彼に教えています...) によると、アプリケーション内で UI コンポーネントを描画するクラスにデータ構造をサブクラス化する必要があります!!!!!!
したがって、このロジックに従って、レコード セットは UI の描画を管理する必要があります。
******ヘッドデスク*****
UI 上の複数の種類のコンポーネントで同じデータ構造をレンダリングしたい場合、レコードセット自体に描画を要求するのは間違っていることはわかっています。レコード セットの基本クラスからレンダリングするすべての UI コンポーネントに対して、さらに別のクラスを拡張する必要があります。
私は、MVC パターンの「クリーンさ」を十分に認識しています (つまり、データ (モデル) を UI (ビュー) またはその上で行われるアクションと混同しないということです)。 data (コントローラーは多かれ少なかれ...まあ、実際にはAPIが実際にそれを処理する必要はありません...そして、コントローラーはできる限り少ない呼び出しを行い、どのビューをレンダリングするかを伝えます))しかし、それは確かにかなりきれいですデータ構造を使用して UI コンポーネントをレンダリングするよりも!
上記の例以外に、彼に送ることができる他のアドバイスはありますか? OOP を初めて学ぶときは、すべてを拡張したいという「段階」を通過することを理解しています。
デザインパターンがすべての問題の解決策であると考える段階が続きます...これも完全に正しいわけではありません...ジェフに感謝します。
この子をそっと正しい方向に向ける方法はありますか? 私の言いたいことを彼に説明するのに役立つ例は他にありますか?