VB2008从入门到精通(PDF格式英文版)-第48部分

快捷操作: 按键盘上方向键 ← 或 → 可快速上下翻页 按键盘上的 Enter 键可回到本书目录页 按键盘上方向键 ↑ 可回到本页顶部! 如果本书没有阅读完，想下次继续接着阅读，可使用上方 "收藏到我的浏览器" 功能 和 "加入书签" 功能！


　　　　　　　　　　is　to　write　some　code　in　the　base　class　method　of　CalculateTaxToPay（）　that　stores　the　taxable　　

　　　　　　　　　　ine　so　the　subclass　has　access　to　it。　

　　　　　　　　　　　　　　　　The　original　implementation　of　CalculateTaxToPay（）　does　not　consider　a　surtax；　so　the　　

　　　　　　　　　　derived　class　must　contain　that　functionality。　Since　CalculateTaxToPay（）　can　be　overridden　　

　　　　　　　　　　without　the　data　member　_calculatedTaxable；　the　derived　class　would　need　to　implement　the　　

　　　　　　　　　　functionality　in　the　base　class　to　calculate　whether　or　not　the　surtax　applies。　Following　is　an　　

　　　　　　　　　　sample　derived　class　implementation　of　the　tax　engine　for　such　a　situation；　stored　in　a　namespace　　

　　　　　　　　　　called　Surtax；　to　distinguish　it　from　the　base　functionality。　



　　　　　　　　　　Namespace　Surtax　

　　　　　　　　　　　　　　Friend　Class　TaxEngine　　

　　　　　　　　　　　　　　　　　　Inherits　BaseTaxEngine　



　　　　　　　　　　　　　　　　　　Public　Overrides　Function　CalculateTaxToPay（ByVal　account　As　ITaxAccount）　_　

　　　　　　　　　　　　　　　　　　　　As　Double　

　　　　　　　　　　　　　　　　　　　　　　Dim　taxToPay　As　Double　=　MyBase。CalculateTaxToPay（account）　

　　　　　　　　　　　　　　　　　　　　　　If　_calculatedTaxable　》　400　Then　

　　　　　　　　　　　　　　　　　　　　　　　　　　taxToPay　=　taxToPay　＋　10　

　　　　　　　　　　　　　　　　　　　　　　End　If　

　　　　　　　　　　　　　　　　　　　　　　Return　taxToPay　

　　　　　　　　　　　　　　　　　　End　Function　



　　　　　　　　　　　　　　　　　　Public　Overrides　Function　CreateTaxAccount（）　As　ITaxAccount　　

　　　　　　　　　　　　　　　　　　　　　　Throw　New　Exception（〃The　method　or　operation　is　not　implemented。〃）　

　　　　　　　　　　　　　　　　　　End　Function　

　　　　　　　　　　　　　　End　Class　

　　　　　　　　　　　End　Namespace　



　　　　　　　　　　　　　　　　In　the　implementation　of　CalculateTaxToPay（）；　we　replace　the　Overridable　keyword　with　　

　　　　　　　　　　Overrides；　implying　that　the　functionality　of　TaxEngine　replaces　the　functionality　of　BaseTaxEngine。　　　

　　　　　　　　　　Since　our　fictional　country　calculates　the　basic　tax　similarly　to　most　countries；　the　functionality　　

　　　　　　　　　　of　BaseTaxEngine。CalculateTaxToPay（）　can　be　used。　Thus；　the　first　line　of　TaxEngine。　

　　　　　　　　　　CalculateTaxToPay（）　is　MyBase。CalculateTaxToPay（）；　meaning　the　base　class　（BaseTaxEngine）　　

　　　　　　　　　　method　CalculateTaxToPay（）　is　called。　


…………………………………………………………Page　199……………………………………………………………

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　CH　AP　T　E　R　　　7　　　■　　　　L　E　AR　N　IN　G　　　AB　O　U　T　　　CO　M　P　O　N　E　N　TS　　　AN　D　　　C　L　AS　S　　H　I　E　R　AR　C　HI　E　S　177　



　　　　　　Calling　the　base　class　results　in　calculating　a　basic　tax　to　pay　amount。　We　need　to　figure　out　　

if　a　surtax　applies；　and　that　is　where　the　protected　data　member　_calculatedTaxable　es　into　　

play。　Having　called　BaseTaxEngine。CalculateTaxToPay（）；　the　data　member　_calculatedTaxable　is　　

assigned　and　contains　the　amount　that　is　being　taxed。　Thus；　TaxEngine。CalculateTaxToPay（）　　

can　make　a　decision　if　more　than　400　currency　units　have　been　earned。　And　if　so；　then　the　vari

able　taxToPay　is　incremented　with　another　10　currency　units。　Had　_calculatedTaxable　not　　

existed；　TaxEngine。CalculateTaxToPay（）　would　have　needed　to　call　the　base　class　functionality　　

to　get　the　basic　tax　rate；　and　then　recalculate　the　taxable　monies　to　figure　out　if　the　surtax　applied。　



■Note　　When　you　use　Overrides　with　methods；　you　are　saying　that　you　need　something　special。　This　does　　

not　imply　that　the　base　class　functionality　will　be　called。　It　implies　that　you　might　call　the　base　class　functionality　　

and　perform　some　additional　operations。　Thus；　when　designing　base　class　functionality；　it　is　important　to　　

track　calculations　or　operations　using　protected　data　members。　The　data　members　avoid　having　derived　classes　　

perform　the　same　operations　multiple　times；　slowing　down　the　application　and　avoiding　potential　errors。　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　USING　NAMESPACES　



　　　Namespaces　are　used　to　define　classes；　interfaces；　and　structures　that　belong　together。　In　this　chapter’s　　

　　　example；　there　is　an　American　tax　engine；　a　Swiss　tax　engine；　and　so　on。　For　organizational　purposes；　each　　

　　　should　have　its　own　namespace。　Sometimes　you　might　even　create　a　custom　assembly　for　each　set　of　inter

　　　face　implementations；　but　you　would　still　need　to　create　a　namespace。　Creating　a　namespace　is　independent　　

　　　of　the　fact　of　whether　or　not　you　create　a　separate　assembly。　

　　　　　　　　　In　the　examples；　I　use　namespaces　like　Surtax　and　Canada。　Whenever　you　create　a　class　or　a　module；　　

　　　or　some　other　type；　you　can　embed　the　type　within　the　namespace。　Then　to　use　the　newly　defined　　

　　　namespaces　in　code　pieces　that　are　not　part　of　the　namespace；　use　the　Imports　keyword。　　



Abstracting　Instantiations　with　Factories　



Take　a　good　look　at　the　scope　declaration　of　the　tax　engine　shown　earlier　and　pare　it　with　　

the　scope　declaration　for　the　ITaxEngine　interface。　What　you　will　notice　is　that　　ITaxEngine　is　　

declared　as　Public　scope；　as　is　BaseTaxEngine；　and　TaxEngine　is　declared　as　　Friend。　Going　back　　

to　our　project　structure；　this　scope　declaration　implies　that　any　reference　to　LibTax　will　see　the　　

interface　ITaxEngine　and　　BaseTaxEngine；　but　not　TaxEngine。　For　example；　the　following　test　　

code　will　not　work。　



Dim　taxengine　As　ITaxEngine　=　New　Surtax。TaxEngine（）　



　　　　　　The　reason　the　test　code　will　not　work　is　that　any　type　that　is　not　declared　with　Public　scope　　

is　private　to　the　solution　containing　the　declaration。　You　may　be　thinking；　“That’s　great—you　　

declare　a　type　that　you　cannot　instantiate。　So；　how　can　I　use　that　type？”　

　　　　　　The　scope　declarations　are　not　a　mistake　and　illustrate　a　design　pattern　called　a　factory　。　A　　

factory　is　a　way　of　abstracting　the　instantiation　away　from　the　caller　so　that　the　interface　can　　

vary　from　its　implementation。　In　our　restaurant　analogy；　it　means　when　you　want　a　waiter；　you　　


…………………………………………………………Page　200……………………………………………………………

178　　　　　　　CH　AP　T　E　R　　　7　　　■　　　　L　E　A　R　N　IN　G　　　AB　OU　T　　　CO　M　P　O　N　E　N　TS　　　AN　D　　C　L　AS　S　　H　I　E　R　AR　C　H　IE　S　



　　　　　　　　　　　don’t　want　to　need　to　know　his　name。　You　would　rather　have　a　generic　mechanism　where　the　　

　　　　　　　　　　　restaurant　presents　to　you　the　waiter。　Otherwise；　to　eat　at　a　restaurant；　you　would　need　to　　

　　　　　　　　　　　know　the　name　of　your　waiter　before　being　able　to　order　something。　That　would　be　inefficient。　

　　　　　　　　　　　　　　　　The　correct　way　of　defining　a　factory　is　as　follows：　



　　　　　　　　　　　　　　Public　Module　EngineCreator　　

　　　　　　　　　　　　　　　　　　Public　Function　CreateSurtaxTaxEngine（）　As　ITaxEngine　　

　　　　　　　　　　　　　　　　　　　　　　Return　New　Surtax。TaxEngine（）　

　　　　　　　　　　　　　　　　　　End　Function　



　　　　　　　　　　　　　　　　　　'　Required　for　country…specific　tax　calculations　

　　　　　　　　　　　　　　　　　　Public　Function　CreateCanadianTaxEngine（）　As　ITaxEngine　

　　　　　　　　　　　　　　　　　　　　　　Return　New　Canada。TaxEngine（）　

　　　　　　　　　　　　　　　　　　End　Function　

　　　　　　　　　　　　　　End　Module　



　　　　　　　　　　　　　　　　The　factory　is　typically　declared　in　a　module　because　a　module　is　not　instantiated。　Generally　　

　　　　　　　　　　　speaking；　you　don’t　want　to　add　a　factory　to　an　object　that　can　be　instantiated　because　it　could　　

　　　　　　　　　　　result　in　context…specific　instantiation。　In　other　words；　you　usually　want　a　fresh　object　created　　

　　　　　　　　　　　from　scratch　each　time；　so　it’s　not　affected　by　the　current　state　of　the　application。　In　the　imple

　　　　　　　　　　　mentation　of　CreateSurtaxTaxEngine（）；　the　type　Surtax。TaxEngine　is　instantiated；　and　the　　

　　　　　　　　　　　instance　is　cast　to　the　interface　type　ITaxEngine。　

　　　　　　　　　　　　　　　　The　EngineCreator　module　is　declared　with　public　scope；　implying　any　code　that　references　　

　　　　　　　　　　　the　assembly　can　see　the　module。　Thus；　the　test　code　can　be　rewritten　as　follows　（we　need　to　　

　　　　　　　　　　　import　the　LibTax　project；　of　course）：　



　　　　　　　　　　　Dim　taxengine　As　ITaxEngine　=　EngineCreator。CreateSurtaxTaxEngine（）　



　　　　　　　　　　　　　　　　After　calling　　EngineCreator。CreateSurtaxTaxEngine（）；　the　test　code　has　a　valid　instance　of　　

　　　　　　　　　　　ITaxEngine。　It’s　very　important　to　note　that　the　test　code　has　no　idea　what　type　implemented　　

　　　　　　　　　　　the　interface。　This　allows　the　assembly　to　change　which　type　is　referenced　in　the　implementa

　　　　　　　　　　　tion　of　CreateSurtaxTaxEngine（）　without　having　to　inform　the　caller　of　the　method。　

　　　　　　　　　　　　　　　　Putting　this　into　the　context　of　the　restaurant；　it　means　waiters　can　be　replaced。　So　if　you　　

　　　　　　　　　　　repeatedly　visit　a　restaurant　and　get　a　waiter　called　John；　but　one　day　John　gets　sick　and　is　not　　

　　　　　　　　　　working；　you　can　still　order　and　receive　your　food　from　the　waitress　called　Mary。　It　would　be　a　　

　　　　　　　　　　　bad　idea　for　a　restaurant　to　depend　on　a　particular　server　for　a　particular　guest。　



　　　　　　　　　　　Using　Default　Implementations　



　　　　　　　　　　　In　some　cases；　base　classes　are　not　necessary。　Sometimes　you　can　create　a　default　implemen

　　　　　　　　　　　tation　that　could　span　multiple　subsystems。　In　the　case　of　the　tax　engine；　an　ine　is　an　ine　　

　　　　　　　　　　　in　Canada；　an　ine　in　the　United　States；　and　an　ine　in　Germany。　What　varies　is　how　the　　

　　　　　　　　　　　ine　is　treated　in　each　country　when　calculating　taxes。　Another　consistency　across　countries　is　　

　　　　　　　　　　　that　if　ine　is　a　capital　gain；　not　all　of　the　ine　is　taxable。　

　　　　　　　　　　　　　　　　In　the　case　of　ine；　you　can　create　an　implementation　that　would　be　identical　across　　

　　　　　　　　　　　different　tax　engines；　as　follows：　


…………………………………………………………Page　201……………………………………………………………

　　　　　　　　　　　　　　　　　　　　　　　　　　　CH　AP　T　E　R　　　7　　　■　　　　L　E　AR　N　IN　G　　　AB　O　U　T　　　CO　M　P　O　N　E　N　TS　　　AN　D　　　C　L　AS　S　　H　I　E　R　AR　C　HI　E　S　179　



NotInheritable　Class　TaxIne　　

　　　　Implements　ITaxIne　



　　　　Private　_amount　As　Double　

　　　　Private　_taxableRate　As　Double　



　　　　Public　Sub　New（ByVal　amount　As　Double；　ByVal　taxableRate　As　Double）　　

　　　　　　　　_amount　=　amount　

　　　　　　　　_taxableRate　=　taxableRate　

　　　　End　Sub　

　　　　　

　　　　Public　ReadOnly　Property　RealAmount（）　As　Double　_　

　　　　　　　　Implements　ITaxIne。RealAmount　

　　　　　　　　Get　　

　　　　　　　　　　　　Return　_amount　

　　　　　　　　End　Get　

　　　　End　Property　



　　　　Public　ReadOnly　Property　TaxableAmount（）　As　Double　_　

　　　　　　　　Implements　ITaxIne。TaxableAmount　

　　　　　　　　Get　

　　　　　　　　　　　　Return　_amount　*　_taxableRate　

　　　　　　　　End　Get　

　　　　End　Property　

End　Class　



　　　　　The　ITaxIne　interface　has　two　properties　that　are　implemented　in　TaxIne：　RealAmount　　

and　TaxableAmount。　The　values　for　the　two　properties　are　considered　read…only　and　are　defined　　

by　the　constructor　of　TaxIne。　The　purpose　of　the　constructor　is　to　assign　two　values　and　　

then　consider　the　object　as　immutable。　If　you　wanted　to　change　the　values　of　the　ITaxIne　　

interface；　you　would　need　to　instantiate　a　new　instance　of　TaxIne。　While　it　sounds　like　a　pain　　

to　need　to　instantiate　a　new　instance　whenever　you　want　to　change　the　value　of　the　RealAmount　and　　

TaxableAmount　properties；　this　approach　has　some　advantages　in　terms　of　performance　and　　

resource　management。　

　　　　　In　the　sample　code；　the　TaxableAmount　property　is　the　result　of　multiplying　the　data　members　　

_amount　and　_taxableRate。　For　example；　whe