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

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



is　in　the　business　of　giving　you　room　and　board。　The　hotel　managers　need　to　make　sure　that　　

when　they　go　to　the　bank　to　exchange　your　dollars　for　euros；　they　don’t　lose　money　in　the　　

process。　They　ensure　this　by　giving　you　less　money。　

　　　　　Whenever　you　exchange　monies；　you　should　always　look　at　the　spreads。　Sometimes　the　　

spreads　are　good；　sometimes　they　are　horrible。　I　have　found　the　best　spreads　are　at　the　banks。　　

It　is　a　bit　more　work　to　get　money　from　your　home　bank；　but　usually　worth　the　effort。　Another　　

option　is　to　pull　the　money　from　your　credit　card；　however；　sometimes　credit　cards　charge　　

interest　on　the　money　you　withdrew。　

　　　　　Now　that　you　have　an　idea　of　what’s　involved　in　currency　exchange；　let’s　see　what　our　　

sample　application　will　do。　



Organizing　the　Currency　Exchange　Application　



The　currency　application　takes　a　number　of　currency　units　and　converts　it　to　a　number　of　other　　

currency　units。　The　application　will　implement　the　following　features：　



　　　　　o　Accept　and　store　a　currency　exchange　rate　



　　　　　o　Store　the　currency　unit　identifiers　



　　　　　o　Convert　to　a　currency　and　back　to　the　original　currency　



　　　　　o　Distinguish　between　active　currency　traders　and　hotel　currency　traders　



　　　　　o　Implement　a　spread　for　hotel　currency　traders　



　　　　　As　in　the　examples　in　the　previous　chapters；　the　project　structure　of　the　currency　applica

tion　will　consist　of　two　projects：　a　console　testing　application；　named　TestCurrencyTrader；　and　　

a　library　ponent；　named　CurrencyTrader；　which　contains　the　functionality　of　the　hotel　　

trader　and　the　active　trader。　



Writing　Tests　for　the　　

Currency　Exchange　Application　　



Since　we　don’t　know　exactly　how　the　implementation　will　appear；　let’s　start　by　writing　some　　

tests　that　will　use　our　implementation。　We　want　to　build　the　application　incrementally；　so　we’ll　　

write　some　tests；　write　some　code；　test　the　code；　and　continue。　The　overall　big　picture　is　to　be　　

able　to　convert　from　one　currency　to　another。　　


…………………………………………………………Page　160……………………………………………………………

138　　　　　　　CH　AP　T　E　R　　　6　　　■　　　　L　E　A　R　N　IN　G　　　T　HE　　　B　AS　IC　S　　O　F　　　OB　J　E　CT　OR　I　E　N　T　E　D　　　P　R　O　G　R　AM　M　IN　G　



　　　　　　　　　　Getting　Started　with　Structural　Code　



　　　　　　　　　　At　the　heart　of　the　application　are　an　exchange　rate；　currency　units；　and　a　calculation　that　　

　　　　　　　　　　bines　the　exchange　rate　with　the　currency　units。　Thus；　a　logical　first　step　would　be　to　write　　

　　　　　　　　　　test　code　that　bines　these　elements；　something　like　this：　



　　　　　　　　　　Dim　cls　As　CurrencyTrader　=　New　CurrencyTrader（）　

　　　　　　　　　　cls。ExchangeRate　=　1。46　

　　　　　　　　　　Dim　haveUSD　As　Double　=　100。0　

　　　　　　　　　　Dim　getEUR　As　Double　=　cls。Convert（haveUSD）　

　　　　　　　　　　Console。WriteLine（〃Converted　〃　&　haveUSD　&　〃　USD　to　〃　&　getEUR）　



　　　　　　　　　　　　　　　　This　code　is　unique　in　that　the　test　code　has　all　of　the　responsibility　of　making　sure　the　　

　　　　　　　　　　correct　data　is　assigned　to　the　structure。　To　clarify　this；　here　is　the　same　code　with　random　vari

　　　　　　　　　　able　names　used　instead　of　the　identifiers　for　the　currency　variables：　



　　　　　　　　　　Dim　cls　As　CurrencyTrader　=　New　CurrencyTrader（）　

　　　　　　　　　　cls。ExchangeRate　=　1。46　

　　　　　　　　　　Dim　ukfkisd　As　Double　=　100。0　

　　　　　　　　　　Dim　didkfdbnfd　As　Double　=　cls。Convert（ukfkisd）　

　　　　　　　　　　Console。WriteLine（〃Converted　〃　&　ukfkisd　&　〃　USD　to　〃　&　didkfdbnfd）　



　　　　　　　　　　　　　　　　This　code　is　structural；　rather　than　architectural。　Structural　code　is　code　that　requires　an　　

　　　　　　　　　　intelligent　programmer—a　programmer　who　knows　what　the　individual　items　mean。　In　this　　

　　　　　　　　　　case；　the　programmer　must　know　that　the　Convert（）　method　converts　from　USD　to　EUR　and　　

　　　　　　　　　　therefore　needs　to　supply　the　correct　values　at　the　correct　time。　

　　　　　　　　　　　　　　　Architectural　code；　on　the　other　hand；　is　more　idiot…proof　and　requires　less　knowledge；　　

　　　　　　　　　　because　many　parts　are　encapsulated。　The　user　needs　to　understand　only　how　to　use　the　classes。　

　　　　　　　　　　　　　　　　Put　another　way；　structural　code　is　knowing　how　to　add　two　numbers。　Architectural　code　　

　　　　　　　　　　is　knowing　how　to　punch　in　the　two　numbers　and　hit　the　plus　sign　on　a　calculator。　You　can　　

　　　　　　　　　　argue　that　by　not　knowing　how　to　add　and　relying　on　the　calculator；　you　have　no　idea　if　the　　

　　　　　　　　　　calculator　is　doing　its　job　properly。　That　is　a　valid　point；　and　that　is　why　tests　are　important　to　　

　　　　　　　　　　ensure　that　the　calculator　is　doing　its　job　properly。　



　　　　　　　　　　Understanding　Base　Classes　



　　　　　　　　　　The　first　test　code；　which　is　structural；　is　not　wrong。　Structural　code　forms　the　basis　of　what　is　　

　　　　　　　　　　called　a　base　class。　A　base　class　is　a　class　that　provides　certain　functionality　that　will　be　reused　　

　　　　　　　　　　by　other　classes。　In　this　case；　converting　the　currency　units　is　functionality　that　we　will　need　　

　　　　　　　　　　in　both　the　active　trader　and　hotel　trader。　You　define　base　classes　so　that　you　get　consistent　　

　　　　　　　　　　behavior　when　performing　identical　operations。　In　lieu　of　base　classes；　you　would　need　to　copy　　

　　　　　　　　　　and　paste　the　functionality　to　reuse　it。　

　　　　　　　　　　　　　　　　Base　classes　have　some　very　important　characteristics：　


…………………………………………………………Page　161……………………………………………………………

　　　　　　　　　　　　　　　　　　　　　　　　　　CH　A　PT　E　R　　　6　　　■　　　　L　E　A　R　N　I　N　G　　　T　HE　　　B　AS　IC　S　　O　F　　　O　B　J　E　CT　OR　I　E　N　TE　D　　　P　R　O　G　R　AM　M　IN　G　139　



　　　　　o　　Only　developers　who　understand　what　the　base　class　code　is　trying　to　do　should　use　the　　

　　　　　　　　base　class　code。　In　other　words；　only　those　with　expert　domain　knowledge　should　touch　　

　　　　　　　　the　internals　of　the　base　class。　To　control　access；　we　will　use　scope。　



　　　　　o　　Base　classes　describe　properties　and　methods　that　are　mon　across　multiple　　

　　　　　　　　applications。　　



　　　　　o　　Base　classes　need　extensive　testing　because　their　functionality　will　be　used　throughout　your　　

　　　　　　　　code。　If　the　base　classes　have　bugs；　most　likely　a　large　chunk　of　your　code　will　have　bugs。　



■Note　　Base　classes　are　a　general　concept　that　only　developers　understand　fully。　A　general　concept　is　called　　

a　design　pattern。　Design　patterns　create　a　developer　lingo　where　words　like　factory；　state；　and　visitor　refer　to　　

specific　coding　concepts　that　developers　understand　without　needing　to　explain　the　coding　concept。　I　suggest　　

that　you　learn　more　about　design　patterns。　The　Data　&　Object　Factory　web　site　（http：//dofactory。/　

Patterns/Patterns。aspx）　has　some　excellent　coding　examples　of　essential　patterns　used　by　developers。　



　　　　　　In　the　current　example；　the　CurrencyTrader　class　needs　to　be　converted　into　a　base　class　　

that　can　be　used　only　by　knowledgeable　developers　（those　who　know　about　currency　trading）。　　

You　want　to　prevent　your　source　code　from　being　used　in　the　wrong　context。　

　　　　　　One　way　to　stop　usage　in　the　wrong　context　is　to　declare　the　CurrencyTrader　class　as　　

MustInherit。　The　MustInherit　keyword　says　that　the　class　in　question　cannot　be　instantiated。　　

You　can　reference　the　class；　but　you　cannot　instantiate　the　class。　Consider　the　following　code；　　

which　declares　CurrencyTrader　as　MustInherit。　



MustInherit　Class　CurrencyTrader　

End　Class　



　　　　　　Using　MustInherit　implies　that　someone　needs　to　create　a　class　that　can　be　instantiated；　　

using　a　mechanism　called　inheritance。　Note　that　any　class　can　be　extended　in　this　way；　but　　

MustInherit　marks　a　class　that　is　specifically　designed　to　be　extended。　From　a　developer　　

perspective；　the　idea　behind　MustInherit　is　to　embed　reusable　logic　used　by　some　other　class。　　

Using　MustInherit　implies　inheritance。　



Understanding　Inheritance　



Inheritance　is　similar　to　a　genealogy　tree；　in　that　you　have　a　tree　structure　where　there　is　a　parent；　　

and　the　descendants　of　the　parent　are　children。　And　like　the　genealogy　tree；　the　structure　can　　

have　multiple　levels。　However；　inheritance　is　not　quite　like　genealogy；　because　genealogy　requires　　

a　pair　of　humans　to　create　a　tree。　　

　　　　　A　class　uses　inheritance　to　gain　functionality　from　the　base　class　and　bees　a　subclass　　

of　that　base　class。　Inheritance；　and　in　particular　；　has　a　tree　structure　where　there　is　only　a　　

single　root　parent。　When　you　use　inheritance；　you　can　gain　functionality；　but　you　can　also　override　　

functionality；　as　illustrated　in　Figure　6…1。　


…………………………………………………………Page　162……………………………………………………………

140　　　　　　　　CH　AP　T　E　R　　　6　　　■　　　　L　E　A　R　N　IN　G　　　T　HE　　　B　AS　IC　S　　O　F　　　OB　J　E　CT　OR　I　E　N　T　E　D　　　P　R　O　G　R　AM　M　IN　G　



　　　　　　　　　　　Figure　6…1。　Simple　two…level　inheritance　example　using　the　awesome　BMW　530i　and　530xi　



　　　　　　　　　　　　　　　　　The　pictures　in　Figure　6…1　seem　to　illustrate　the　same　car；　but　in　fact；　they　are　two　different　　

　　　　　　　　　　　models　with　a　major　difference　in　their　power　trains。　From　an　inheritance　perspective；　the　　

　　　　　　　　　　　BMW　530i　could　be　considered　the　parent　of　the　BMW　530xi。　　



　　　　　　　　　　　■Note　　The　order　of　which　is　the　parent　and　which　is　the　child　is　my　logic；　some　might　disagree。　This　　

　　　　　　　　　　　disagreement　is　healthy　and　part　of　the　object…oriented　design　process。　



　　　　　　　　　　　　　　　　　The　first　model　that　you　would　design　would　probably　be　the　rear…wheel…drive　model；　　

　　　　　　　　　　　since　it　is　simpler　to　design；　cheaper；　and　more　popular。　You　would　consider　all…wheel　drive　as　　

　　　　　　　　　　　a　feature。　The　all…wheel…drive　model　is　not　a　pletely　new　car。　Both　the　530i　and　530xi　would　　

　　　　　　　　　　　share　the　same　tires；　motor；　steering　wheel；　body　trim；　and　so　on。　What　would　be　different　is　　

　　　　　　　　　　　that　the　530xi　replaces　the　power　train；　thus　changing　the　behavior　of　the　car。　

　　　　　　　　　　　　　　　　　Let’s　say　that　you　are　a　driver　sitting　in　the　seat　driving　your　BMW；　and　it’s　a　snowy　night　　

　　　　　　　　　　　in　Canada。　Whether　you　are　driving　the　530i　or　the　530xi；　you　would　use　the　same　steering　　

　　　　　　　　　　　wheel；　blinkers；　gas　pedal；　brake；　and　so　on。　But　the　behavior　of　the　530i　and　530xi　would　be　　

　　　　　　　　　　　different—the　rear…wheel…drive　car　might　slide　around　a　bit　more　than　the　all…wheel…drive　car。　　

　　　　　　　　　　　The　power　train　overrides　behavior；　which　means　the　consumer　of　the　hierarchy　sees　the　same　　

　　　　　　　　　　　interface　（for　example；　methods　and　properties）；　but　gets　different　behavior。　

　　　　　　　　　　　　　　　　Another　way　to　use　inheritance　is　not　to　replace　functionality；　but　to　enhance　function

　　　　　　　　　　　ality；　as　illustrated　in　Figure　6…2。　This　is　called　overloading　behavior。　


…………………………………………………………Page　163……………………………………………………………

　　　　　　　　　　　　　　　　　　　　　　　　　CH　A　PT　E　R　　　6　　　■　　　　L　E　A　R　N　I　N　G　　　T　HE　　　B　AS　IC　S　　O　F　　　O　B　J　E　CT　OR　I　E　N　TE　D　　　P　R　O　G　R　AM　M　IN　G　141　



Figure　6…2。　A　more　extensive　inheritance　tree　illustrating　how　functionality　can　be　enhanced　



　　　　　In　Figure　6…2；　all　of　the　cars　are　related　in　that　they　are　the　530　line。　The　new　model　is　the　　

BMW　530xi　Sports　Wagon；　which；　from　an　inheritance　perspective；　is　based　on　the　function

ality　of　the　BMW　530xi。　But　here　is　the　twist：　the　functionality　of　the　530xi　Sports　Wagon　requires　　

you　to　get　accustomed　to　the　Sports　Wagon。　For　example；　even　though　you　press　a　single　　

button　to　open　the　trunk；　the　Sports　Wagon’s　trunk　is　slightly　different　from　the　trunk　in　the　　

530xi　and　530i；　and　thus　exposes　the　driver　to　a　slightly　different　user　interface　and　behavior。　

　　　　　When　you　use　inheritance　to　overload　functionality；　you　are　adding　functionality　that　is　　

called　in　the　same　way；　but　is　used　and　behaves　differently。　With　this　form　of　inheritance；　you　　

don’t　just　change　behavior；　you　also　change　the　user　interaction。　　

　　　　　In　our　example；　we　will　use　inheritance　to　extend　functionality；　and　not　override　or　overload。　　



Using　Visual　Basic　Properties　



So　far；　the　test　code　would　call　a　data　member　reference；　as　in　this　line：　



cls。ExchangeRate　=　123。45　



　　　　　The　data　member　could　be　implemented　as　follows：　



Public　MustInherit　Class　CurrencyTrader　

　　　　Public　ExchangeRate　As　Double　

End　Class　



　　　　　Exposing　the　data　member　using　a　public　scope　worked　in　previous　chapters；　but　we　don’t　　

really　want　to　do　this　because　we　are　exposing　the　internal　state　of　the　object。　In　object…oriented　　

programming；　exposing　the　internal　state　is　a　bad　idea　（as　explained　in　more　detail　shortly）。　


…………………………………………………………Page　164……………………………………………………………

142　　　　　　　CH　AP　T　E　R　　　6　　　■　　　　L　E　A　R　N　IN　G　　　T　HE　　　B　AS　IC　S　　O　F　　　OB　J　E　CT　OR　I　E　N　T　E　D　　　P　R　O　G　R　AM　M　IN　G　



　　　　　　　　　　　　　　　　Rather　than　expose　the　data　member　publicly；　we　will　change　the　test　code　to　use　properties。　　

　　　　　　　　　　　Properties　also　expose　the　internal　state　of　an　object；　but　they　provide　a　layer　of　abstraction。　As　　

　　　　　　　　　　　you　will　learn；　some　properties　expose　both　internal　state　and　external　state。　This　is　the　case　　

　　　　　　　　　　　with　the　　ExchangeRate　property　that　we　will　use　to　access　and　modify　the　exchange　rate。　If　we　　

　　　　　　　　　　　did　not　use　the　ExchangeRate　property；　we　would　need　to　create　a　method　that　assigns　the　　

　　　　　　　　　　　exchange　rate　and　a　method　that　retrieves　the　exchange　rate。　The　methods　would　behave　like　　

　　　　　　　　　　　the　property；　but　they　would　not　be　as　convenient　to　use。　　



　　　　　　　　　　　Rewriting　the　Test　Code　to　Use　Properties　



　　　　　　　　　　　The　interesting　thing　about　Visual　Basic　properties　is　that　they　look　and　behave　like　data　members。　　

　　　　　　　　　　　This　means　with　Visual　Basic　properties；　the　test　code　does　not　need　to　be　rewritten；　as　the　test　　

　　　　　　　　　　　code　still　assumes　a　direct　access　to　the　variable。　Consider　the　rewritten　CurrencyTrader　that　　

　　　　　　　　　　　exposes　ExchangeRate　as　a　Visual　Basic　property；　shown　in　Figure　6…3。　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　Data　member　ExchangeRate　is　relabeled　to　

　　　　　　　　　　　　　Public　MustInherit　Class　CurrencyTrader　　　　　　　　　　　　　　　_exchangeRate；　and　the　scope　is　changed　

　　　　　　　　　　　　　　　　　Private　_exchangeRate　As　Double　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　from　public　to　private　



　　　　　　　　　　　　　　　　　Public　Property　ExchangeRate（）　As　Double　

　　　　　　　　　　　　　　　　　　　　　Get　

　　　　　　　　　　　　　　　　　　　　　　　　　Return　_exchangeRate　　　　　　　　　　　　　　　　　　A　Visual　Basic　property　declaration　looks　like　a　

　　　　　　　　　　　　　　　　　　　　　End　Get　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　function　declaration　without　the　parameters；　and　

　　　　　　　　　　　　　　　　　　　　　Set（ByVal　value　As　Double）　　　　　　　　　　　　　　　　　　　　　　instead　of　Function；　Property　is　used　

　　　　　　　　　　　　　　　　　　　　　　　　　_exchangeRate　=　value　

　　　　　　　　　　　　　　　　　　　　　End　Set　

　　　　　　　　　　　　　　　　　End　Property　

　　　　　　　　　　　　　End　Class　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　What　makes　a　property　uniquely　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　different　from　a　function　are　the　Get　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　and　Set　keywords　used　to　return　and　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　assign　the　value　of　the　property　



　　　　　　　　　　　Figure　6…3。　Exposing　ExchangeRa