VB2008从入门到精通(PDF格式英文版)-第54章

按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！



144　　　　　　　　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　



　　　　　　　　　　　　　　　　　In　the　modified　implementation　of　Oven；　the　data　member　_temperature　is　not　externally　　

　　　　　　　　　　　exposed。　And　in　this　situation；　the　role　of　the　data　member　_temperature　is　not　to　represent　the　　

　　　　　　　　　　　temperature　of　the　oven；　but　to　act　as　an　upper　limit　to　which　the　oven　should　be　heated。　The　　

　　　　　　　　　　　upper　limit　is　assigned　using　the　SetTemperature（）　method。　To　check　the　temperature　of　the　　

　　　　　　　　　　　oven；　you　don’t　retrieve　the　temperature　of　the　oven；　but　call　the　AreYouPreheated（）　method。　　

　　　　　　　　　　　The　caller　receives　either　a　True　or　　False　value　to　indicate　whether　or　not　the　oven　is　ready。　

　　　　　　　　　　　　　　　　　The　caller　of　Oven　has　the　responsibility　only　of　setting　the　upper　temperature　and　asking　　

　　　　　　　　　　　if　the　oven　is　preheated。　From　this　example；　it　would　seem　that　you　don’t　need　properties。　　

　　　　　　　　　　　However；　you　still　need　properties　because　Oven　in　its　current　form　represents　an　easy…to…use　　

　　　　　　　　　　　class　that　can　be　integrated　at　the　architectural　business…logic　level。　

　　　　　　　　　　　　　　　　　The　challenge　of　the　developer　is　to　bridge　the　gap　between　a　raw　structural　class　and　the　　

　　　　　　　　　　　exposure　of　an　architectural　business…logic…level　class。　That　challenge　will　be　met　when　the　　

　　　　　　　　　　　hotel　currency　trader　and　active　currency　trader　are　implemented。　

　　　　　　　　　　　　　　　　　Even　with　these　arguments　and　the　distinction　between　base　class　and　architectural　business

　　　　　　　　　　　logic…level　classes；　some　still　naysay　properties。　The　reason　has　to　do　with　controlling　access。　　

　　　　　　　　　　　　　　　　　Suppose　you　are　in　a　grocery　store；　waiting　at　the　cash　register。　The　cashier　tallies　up　the　　

　　　　　　　　　　　items；　arrives　at　a　total；　and　asks　you　to　pay。　Do　you　open　your　purse　or　wallet　and　let　the　cashier　　

　　　　　　　　　　　get　the　credit　card　or　cash？　Along　the　same　lines；　why　can’t　you　just　place　the　cash　into　the　cash　　

　　　　　　　　　　　register？　The　answer　to　these　questions　is　one　of　trust。　As　trustworthy　as　the　cashier　and　shopper　　

　　　　　　　　　　　might　be；　we　feel　better　when　we　know　we　have　the　control。　　

　　　　　　　　　　　　　　　　　Let’s　go　back　to　an　example　I　mentioned　at　the　beginning　of　the　chapter：　allowing　people　　

　　　　　　　　　　　to　grab　into　your　pockets。　The　previously　defined　Temperature　property　is　allowing　someone　to　　

　　　　　　　　　　　grab　into　your　pockets。　You　wouldn’t　generally　allow　it；　but　what　if　that　person　were　your　spouse　　

　　　　　　　　　　　or　your　mom？　Would　you　still　disallow　it？　The　answer　is　very　different；　because　you　probably　　

　　　　　　　　　　　trust　your　mom　or　spouse。　In　the　same　way；　often　state　and　its　exposure　are　a　matter　of　trust　　

　　　　　　　　　　　and　using　the　right　scope。　



　　　　　　　　　　　■Note　　In　this　discussion　of　properties　and　object…oriented　design；　my　goal　is　to　explain　that　there　is　a　place　　

　　　　　　　　　　　and　time　for　both；　and　you　should　not　feel　biased　toward　one　approach　or　the　other。　When　you　design　a　type　　

　　　　　　　　　　　that　does　not　reveal　its　state；　you　are　designing　a　type　that　fulfills　an　abstract　intention。　When　you　design　a　　

　　　　　　　　　　　type　that　reveals　its　state　（to　some　extent）　through　properties；　you　are　designing　a　type　that　is　used　at　the　　

　　　　　　　　　　　lower　technical　level。　Also　keep　in　mind　that　sometimes　internal　state　is　external　state；　such　as　the　exchange　　

　　　　　　　　　　　rate　example。　You　cannot　abstract　away　the　exchange　rate　state　because　it　is　a　number　used　in　a　calculation。　



　　　　　　　　　　　Understanding　Inheritance　and　Scope　Modifiers　



　　　　　　　　　　　At　this　point；　the　　ExchangeRate　property　is　a　mechanical　property　that　will　be　used　by　any　class　　

　　　　　　　　　　　that　subclasses　CurrencyTrader。　So　now　we　need　to　decide　whether　access　to　the　property　　

　　　　　　　　　　　should　be　restricted。　The　answer　is　that　it　should　be　restricted　to　only　those　developers　who　　

　　　　　　　　　　　truly　understand　how　to　convert　currencies。　Access　should　be　restricted　to　those　classes　that　　

　　　　　　　　　　　will　subclass　CurrencyTrader。　Following　is　the　rewritten　version　of　CurrencyTrader。　


…………………………………………………………Page　167……………………………………………………………

　　　　　　　　　　　　　　　　　　　　　　　　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　145　



Public　MustInherit　Class　CurrencyTrader　

　　　　Private　_exchangeRate　As　Double　



　　　　Protected　Property　ExchangeRate（）　As　Double　

　　　　　　　　Get　

　　　　　　　　　　　　Return　_exchangeRate　

　　　　　　　　End　Get　

　　　　　　　　Set　（ByVal　value　As　Double）　

　　　　　　　　　　　　_exchangeRate　=　value　

　　　　　　　　End　Set　

　　　　End　Property　

End　Class　



　　　　　The　bolded　code　highlights　three　examples　of　scope　access：　



　　　　　Public：　The　type；　method；　data　member；　or　property　can　be　accessed　and　referenced　by　　

　　　　　any　other　type。　In　the　context　of　a　crowd　of　people；　it　means　anyone　can　reach　into　your　　

　　　　　pocket　and　inspect　your　wallet。　



　　　　　Private：　The　method；　data　member；　or　property　can　be　accessed　and　referenced　only　by　　

　　　　　the　type　declaring　the　method；　data　member；　or　property。　In　the　context　of　a　crowd　of　　

　　　　　people；　it　means　only　you　can　reach　into　your　pocket　and　inspect　your　wallet。　



　　　　　Protected：　The　method；　data　member；　or　property　can　be　accessed　and　referenced　by　the　　

　　　　　type　declaring　the　method；　data　member；　or　property　or　by　types　that　subclass　the　declaring　　

　　　　　type。　In　the　context　of　a　crowd　of　people；　it　means　only　you　and　people　who　you　have　　

　　　　　allowed　can　reach　into　your　pocket　and　inspect　your　wallet。　



　　　　　If　you　happen　to　declare　a　type；　method；　or　property　without　a　scope　modifier；　the　default　　

is　assumed；　which　means　public　is　implied。　Data　members　are　private　by　default。　The　Private　　

and　Protected　modifiers　cannot　be　assigned　to　a　type。　You’ll　learn　more　about　other　modifiers　　

and　details　about　type　scope　declarations　in　the　next　chapter。　



Using　Visual　Basic　Inheritance　to　Subclass　Another　Type　



The　rewritten　version　of　CurrencyTrader　will　cause　the　test　code　to　break；　because　it　uses　the　　

MustInherit　keyword；　and　thus　cannot　be　instantiated　directly。　Here　is　the　broken　code：　



Dim　cls　As　CurrencyTrader　=　New　CurrencyTrader（）　

cls。ExchangeRate　=　123。44　



　　　　　The　code　will　not　work　for　two　reasons：　



　　　　　o　　CurrencyTrader　uses　the　MustInherit　keyword　and　thus　cannot　be　instantiated。　



　　　　　o　　ExchangeRate　is　protected　and　cannot　be　referenced　externally。　



　　　　　This　broken　code　puts　us　in　a　bind。　Up　to　this　point；　whenever　we　tested　code；　we　assumed　　

all　of　the　pieces　that　were　to　be　tested　could　be　referenced。　One　solution　would　be　to　change　　

the　scope　declarations　and　remove　the　MustInherit　and　　Protected　keywords。　Yes；　that　solves　the　　

problem；　but　it　is　a　cop…out。　The　better　approach　is　to　test　CurrencyTrader　as　it　was　intended　to　be　　


…………………………………………………………Page　168……………………………………………………………

146　　　　　　　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　



　　　　　　　　　　used：　as　a　class　that　is　derived　from。　So；　the　solution　is　to　use　inheritance　and　create　a　test　class　　

　　　　　　　　　　that　derives　from　CurrencyTrader；　as　follows：　



　　　　　　　　　　Public　Class　TestCurrencyTrader　

　　　　　　　　　　　　　　Inherits　CurrencyTrader　

　　　　　　　　　　　　　　Public　Sub　InitializeExchangeRate（）　　

　　　　　　　　　　　　　　　　　　ExchangeRate　=　100。0　

　　　　　　　　　　　　　　End　Sub　

　　　　　　　　　　End　Class　



　　　　　　　　　　　　　　　TestCurrencyTrader　is　a　test　class　that　is　added　to　the　test　source　code。　To　inherit　from　a　　

　　　　　　　　　　class；　you　define　a　class；　and　in　the　following　line；　use　the　keyword　Inherits。　This　line　says　that　　

　　　　　　　　　　the　class　TestCurrencyTrader　is　subclassing　CurrencyTrader。　　

　　　　　　　　　　　　　　　To　expose　a　method　outside　the　class　declaration；　you　use　the　Public　modifier。　

　　　　　　　　　　　　　　　Inheritance　means　identifiers　that　are　scoped　　Protected　or　　Public　can　be　referenced　in　　

　　　　　　　　　　the　subclassed　type。　For　example；　notice　how　ExchangeRate