起：
既存のﾌﾟﾛｸﾞﾗﾑclass Aに機能fugaを追加したいと思ったが､fugaのためだけにclass A を書き換えて他に影響が出ても困るよ｡

class A {
 hoge
}

承：
そうだ！ﾌﾟﾛｸﾞﾗﾑをｺﾋﾟﾍﾟして別物として書き直そう！

class B {
 hoge
 fuga
}

転：
いや待て！同じことをいくつも書くのは効率悪いぞ！
A にﾐｽがあったら B もやりなおしか！

class A {
 hoge
}
class B {
 hoge
  fuga
}

結：
class Bにはclass Aにない部分だけを書くようにしようぜ！
専門用語で継承って言うんだ｡

class A {
 hoge
}
class B extends A {
 fuga
}

正直なところを書けば､ﾏﾆｭｱﾙや入門書を読み解けないﾚﾍﾞﾙの人が使うものではない｡
理路整然としたｺｰﾄﾞを書けるようでなければﾒﾝﾃﾅﾝｽの手間が増え続けるだけになってしまうので､機能を追加したければ新たに書き直すというくらいの努力をして十分にｽｷﾙｱｯﾌﾟしてから使うことを推奨する｡

ｵﾌﾞｼﾞｪｸﾄ指向は人間系を模倣したものです｡

継承は､会社組織で考えると分かりやいでしょう｡

担当者ﾚﾍﾞﾙでは､決めていないことも上位の組織で決めてあることは守らなければ成りません｡
つまり､担当者が決めていないことは､上位組織で決めておけば良いのです｡

要は､共通の定義は上位ｸﾗｽで定義しておけば､利用できるのです｡
裏返すと､下位ｸﾗｽの定義が優先されることになります｡
これは正に人間系を象徴していますね｡
ｵﾌﾞｼﾞｪｸﾄ指向ﾌﾟﾛｸﾞﾗﾐﾝｸﾞでのｼｽﾃﾑ構築が怖いことの一番大きな理由がこれだと思います｡
信頼の世界であれば､ｼｽﾃﾑは軽くなる｡余談です｡