三大特性

• 封裝：對具有相同屬性的事物進行統一描述
• 繼承：一個類獲取另外一個類的屬性的方式
• 多型：一個類例項的相同方法在不同情形有不同表現形式，說白了就是父類指標指向子類物件

七項原則：目的就是實現   高內聚、低耦合

• 單一職責原則（Single Responsibility Principle，SRP）：類的職責單一，對外只提供一種功能，而引起類變化的原因都應該只有一個
• 開閉原則（Open-Closed Principle，OCP）：增加功能是通過增加程式碼，而不是修改程式碼

class Calculater
{
public:
int calculate(int a,int
 
 b,char c)
{
	if(c=='+')
	{
		return a+b;
	}
	if(c=='-')
	{
		return a-b;
	}
	if(c=='*')
	{
		return a*b;
	}
	if(c=='/')
	{
		return a/b;
	}
}
如果我再想加入 % 功能，則需要修改 calculate 方法， 得修改原始碼
};

class Calculater
{
  public:
  virtual int calculate()=0;
}

class Plus:public Calculater
{
   virtual int calculate
 
(int a,int b)
   {
   		return a+b;
   }
}

class Subtrct:public Calculater
{
   virtual int calculate(int a,int b)
   {
   		return a-b;
   }
}

class Multiply:public Calculater
{
   virtual int calculate(int a,int b)
   {
   		return a*b;
   }
}

class Devide:public Calculater
{
   virtual int calculate
 
(int a,int b)
   {
   		return a/b;
   }
}

這時候如果想新增功能就直接 再繼承一個抽象類，不用修改其他程式碼

• 里氏代換原則（Liskov Substitution Principle，LSP）：任何抽象類出現的地方都可以用他的實現類進行替換，實際就是虛擬機制（多型），語言級別實現面向物件功能

• 依賴倒轉原則（Dependence Inversion Principle，DIP）：依賴於抽象(介面)，不要依賴具體的實現(類)，也就是針對介面程式設計

• 介面隔離原則（Interface Segregation Principle，ISP）：一個方法對外只提供一個功能

• 合成複用原則（Composite Reuse Principle，CRP）：如果使用繼承，會導致父類的任何變換都可能影響到子類的行為。如果使用物件組合（將另一個物件當做成員），就降低了這種依賴關係。對於繼承和組合，優先使用組合

錯誤的做法

class Car
{
public:
	virtual void setcar() = 0;
};


class tuolaji : public Car
{
public:
	virtual void setcar()
	{
		cout << "拖拉機";
	}

};

class Person : public tuolaji  //繼承，這樣就能使用其中方法
{
public:
	void Party()
	{
		cout << "julain開著"; 
		setcar(); 
		cout << "去開Party"<<endl;
	}
};

int main()
{
	Person p;
	p.Party();	
	return 0;
}

class Car
{
public:
	virtual void setcar() = 0;
};

class tuolaji : public Car
{
public:
	virtual void setcar()
	{
		cout << "拖拉機";
	}
};

class Person
{
public:
	void Set(Car *c)
	{
       car = c;
	}
	void Party()
	{
		cout << "julian開著"; 
		car->setcar(); 
		cout << "去Party" << endl;
	}

	string name;
	Car* car;   // 作為成員：類的組合 ，而不是繼承

};

int main()
{
	Person p;
	BMW * bmw = new BMW;
	p.Set(bmw);
	p.Party();
	
	return 0;
}

• 笛米特原則 （Law of Demeter Principle，LoD）：一個物件應當對其他物件儘可能少的瞭解，從而降低各個物件之間的耦合，提高系統的可維護性

情況1：呼叫者直接對每個類進行操作，需要了解每個類的細節 情況2：呼叫者通過中介對類ABC進行操作，並不去了解類ABC的細節，只操作中介提供的介面