實例講授C++編程中的虛函數與虛基類。本站提示廣大學習愛好者:(實例講授C++編程中的虛函數與虛基類)文章只能為提供參考,不一定能成為您想要的結果。以下是實例講授C++編程中的虛函數與虛基類正文
工場辦法形式分歧於簡略工場形式的處所在於工場辦法形式把對象的創立進程放到裡子類裡。如許工場父對象和產物父對象一樣,可所以籠統類或許接口,只界說響應的標准或操作,不觸及詳細的創立或完成細節。
其類圖以下:
實例代碼為:
#pragma once class IProduct { public: IProduct(void); virtual ~IProduct(void); }; #pragma once #include "iproduct.h" class IPad : public IProduct { public: IPad(void); ~IPad(void); }; #pragma once #include "iproduct.h" class IPhone : public IProduct { public: IPhone(void); ~IPhone(void); }; #pragma once #include"IProduct.h" class IFactory { public: IFactory(void); virtual ~IFactory(void); virtual IProduct* getProduct(); }; #pragma once #include "ifactory.h" class IPadFactory : public IFactory { public: IPadFactory(void); ~IPadFactory(void); virtual IProduct* getProduct(); }; #pragma once #include "ifactory.h" class IPhoneFactory : public IFactory { public: IPhoneFactory(void); ~IPhoneFactory(void); virtual IProduct* getProduct(); };
症結的完成:
#include "StdAfx.h" #include "IPadFactory.h" #include"IPad.h" IPadFactory::IPadFactory(void) { } IPadFactory::~IPadFactory(void) { } IProduct* IPadFactory::getProduct() { return new IPad(); } #include "StdAfx.h" #include "IPhoneFactory.h" #include"IPhone.h" IPhoneFactory::IPhoneFactory(void) { } IPhoneFactory::~IPhoneFactory(void) { } IProduct* IPhoneFactory::getProduct() { return new IPhone(); }
挪用方法:
#include "stdafx.h" #include"IFactory.h" #include"IPadFactory.h" #include"IPhoneFactory.h" #include"IProduct.h" int _tmain(int argc, _TCHAR* argv[]) { IFactory *fac = new IPadFactory(); IProduct *pro = fac->getProduct(); fac = new IPhoneFactory(); pro = fac->getProduct(); return 0; }
運用場景:
1..net外面的數據庫銜接對象就是發生數據敕令對象的工場。每種數據庫的connection對象裡(繼續自IDbConnection)都有對本身createCommand(界說在IDbCommand裡)的完成。
2..net外面的迭代器,IEnumerable界說了迭代器的接口,即工場辦法,每個繼續自IEnumerable的類都要完成GetEnumerator。可以參看ArrayList,String的GetEnumerator辦法。他們都繼續自IEnumerable。
比較簡略工場形式與工場辦法形式:
1. 構造龐雜度
從這個角度比擬,明顯簡略工場形式要占優。簡略工場形式只需一個工場類,而工場辦法形式的工場類跟著產物類個數增長而增長,這無疑會使類的個數愈來愈多,從而增長了卻構的龐雜水平。
2.代碼龐雜度
代碼龐雜度和構造龐雜度是一對抵觸,既然簡略工場形式在構造方面絕對簡練,那末它在代碼方面確定是比工場辦法形式龐雜的了。簡略工場形式的工場類跟著產物類的增長須要增長許多辦法(或代碼),而工場辦法形式每一個詳細工場類只完成單一義務,代碼簡練。
3.客戶端編程難度
工場辦法形式固然在工場類構造中引入了接口從而知足了OCP,然則在客戶端編碼中須要對工場類停止實例化。而簡略工場形式的工場類是個靜態類,在客戶端無需實例化,這無疑是個吸惹人的長處。
4.治理上的難度
這是個症結的成績。
我 們先談擴大。盡人皆知,工場辦法形式完整知足OCP,即它有異常優越的擴大性。那能否就解釋了簡略工場形式就沒有擴大性呢?謎底能否定的。簡略工場形式同 樣具有優越的擴大性——擴大的時刻僅須要修正大批的代碼(修正工場類的代碼)便可以知足擴大性的請求了。雖然這沒有完整知足OCP,但筆者以為不須要太拘 泥於設計實際。
然後我們從保護性的角度剖析下。假設某個詳細產物類須要停止必定的修正,極可能須要修正對應的工場類。當同時 須要修正多個產物類的時刻,對工場類的修正會變得相當費事(對號入坐曾經是個成績了)。反而簡略工場沒有這些費事,當多個產物類須要修正是,簡略工場形式 依然僅僅須要修正獨一的工場類(不管如何都能改到知足請求吧?年夜不了把這個類重寫)。
由以上的剖析,筆者以為簡略工場形式更好用更便利些。固然這只是筆者的小我意見罷了,究竟公認的,工場辦法形式比簡略工場形式更“先輩”。但有時過於先輩的器械未必合適本身,這個見仁見智吧。