または、ご自身の経験によると、
あなたの好きなトリックは何ですか?
一番の原則はカプセル化です-少なくとも大学はその部分を正しく持っています。
継承、ポリモーフィズム、結束、簡潔さ、結合、依存関係など...これらすべてのものは本当にその1つの傘に分類されます。
「練習によってカプセル化し、必要に応じて公開します。」
残りはほとんどそこから始まります。変更によって再訪を余儀なくされる場所の数を制限します。理想的には、動作のすべての変更は連鎖反応の開始または終了になります(テストを変更してからテストするものを変更します) )そして、設計を変更するたびに、結果として生じる変更はまったく発生しません。これはめったに達成されない現実です。
「変化するものを見つけて、それをカプセル化します。」
あるクラスに別のクラスの動作を与えるために継承を使用しないでください。代わりに委任を使用します。継承を使用して抽象化を作成し、その背後に多数のバリエーションが存在します。設計を劣化させる必要がある問題があると思われる場合、問題はおそらく、代わりに設計を改善する必要があるということです。
おそらくどこかに良い説明のあるOOPコード品質の良いリストがあるので、ここでそれを再入力することはしません。それらの原則に従い、状況に応じて慣行を適応させてください。そうすれば、かなりうまくいくはずです。
CSC 110 のクラスで、Homer Simpson は PIE が好きだと教えられました (PIE はオブジェクト指向プログラミングの 3 大概念です)。
P = ポリモーフィズム I = 継承 E = カプセル化