OCP: The Open Closed Principle
拡張に対して開いていて修正に対して閉じていなければならない
いきなり↑みたいな事を言われても（ﾟДﾟ）ﾊｧ?、って感じでしょう。
機能を追加する事は可能だが書き直しちゃ駄目だお、と言う事です。
・・・これは例が無いと埒が明かない気がします。
class vip{
public:
void update();
private:
std::list<Vipper*> m_vipperList;
};
vipにはvipperがいます。まぁ、ある意味では正しいクラスです。
でもvipper以外にもユーザがいるだろうしupdate以外にもしたい事が発生するかもしれません。
その度に書き直してたりしたらとても非効率。それじゃ、どうすれば良いのか。
答えは予測しろです。今回は例がアレでしたが一つの「概念」は見る方向によって必要なものは大きく、繊細に変わります。大半のゲームのキャラには座標が必要ですがエロゲの主人公に座標を持たせる必要は無いでしょう。
それを見極める「眼」とは経験やセンスと言ったものであり容易に得がたいものだし、プロジェクトの方向転換で変更せざるを得ない状況になるやも知れません。
ですがOOPを使いこなせばリスクを軽減する事が可能です。 その一つの答えが抽象です。 例えばメンバ変数をstd::list<Neler*> m_nelerList;にでもすればvipperだけでなくねらーまで扱うことが出来ます。 又、acceptメソッドを設けてvisitorを受け入れれば様々な処理も可能になります。
クラスそのものを弄らせず、しかし予想されうる拡張を視野に入れて設計を行う。 と言うのがＯＣＰに於ける約束事だと思います。 無駄にメンバを増やさない程度に心掛けましょう。