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

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


rs　　

and　private　methods　of　other　instances　of　that　type。　


…………………………………………………………Page　230……………………………………………………………

208　　　　　　　CH　AP　T　E　R　　　8　　　■　　　　L　E　A　R　N　IN　G　　　AB　OU　T　　　CO　M　P　O　N　E　N　TO　R　IE　N　T　E　D　　AR　C　HI　TE　CT　U　R　E　



　　　　　　　　　　　　　　　　Once　the　data　members　of　the　item　have　been　assigned；　the　item　is　integrated　into　the　list；　　

　　　　　　　　　　　by　redirecting　the　_prev　property　of　the　next　object　（if　it　is　not　Nothing）；　and　then　assigning　the　　

　　　　　　　　　　　local　_next　property　to　the　object　to　be　inserted。　

　　　　　　　　　　　　　　　　The　Remove（）　method　does　the　same　as　　Insert（）；　but　in　reverse。　The　first　step　is　to　redirect　　

　　　　　　　　　　　the　_next　and　_prev　properties　of　the　previous　and　next　objects；　assuming　that　they　are　not　　

　　　　　　　　　　　Nothing。　And　then　the　object　to　be　removed　has　its　_next　and　_prev　properties　assigned　to　Nothing。　



　　　　　　　　　　　■Note　　The　declaration　of　PrevItem　and　NextItem　is　a　mon　architecture　where　data　members　can　be　　

　　　　　　　　　　　read；　but　to　assign　them；　you　need　to　use　methods。　Using　read…only　properties　is　one　way　to　make　sure　that　　

　　　　　　　　　　　the　internal　state　cannot　be　corrupted；　if　you　must　expose　the　internal　state。　



　　　　　　　　　　　Testing　the　Linked　List　



　　　　　　　　　　　BaseLinkedListItem　is　a　core　class　and　serves　a　utility　purpose。　This　makes　the　class　eligible　to　　

　　　　　　　　　　　be　declared　in　the　kernel　or　a　definitions　assembly。　As　the　class　is　a　core　class；　it　means　you　　

　　　　　　　　　　　need　a　more　exhaustive　testing　framework　to　ensure　that　there　will　be　no　problems。　In　this　　

　　　　　　　　　　　section；　we　will　go　through　one　test　that　demonstrates　what　you　should　be　testing　for　and　how　　

　　　　　　　　　　　you　should　be　testing　a　core　class。　

　　　　　　　　　　　　　　　　BaseLinkedListItem　is　declared　as　MustInherit　and　needs　an　implementation。　The　purpose　of　　

　　　　　　　　　　　the　implementation　is　to　give　us　enough　information　on　the　state　and　context　of　the　object。　In　this　　

　　　　　　　　　　　case；　we　want　to　define　an　object　that　tests　every　part　of　the　class　BaseLinkedListItem。　If　you　have　　

　　　　　　　　　　　ever　seen　pictures　of　a　test　car　tire　hooked　up　to　dozens　of　wires；　then　you　will　understand　what　the　　

　　　　　　　　　　　test　class　needs　to　do。　Following　is　a　sample　implementation；　placed　in　the　TestLightingSystem　　

　　　　　　　　　　　project。　Remember　to　include　a　reference　to　　LibLightingSystem　（right…click　References　in　　

　　　　　　　　　　　TestLightingSystem　and　select　Add　Reference　and　then　Projects　　LibLightingSystem）。　　



　　　　　　　　　　　。　。　。　

　　　　　　　　　　　Imports　LibLightingSystem　



　　　　　　　　　　　Class　LinkedItem　　

　　　　　　　　　　　　　　　Inherits　BaseLinkedListItem　



　　　　　　　　　　　　　　　Private　_identifier　As　String　



　　　　　　　　　　　　　　　Public　Sub　New（ByVal　identifier　As　String）　

　　　　　　　　　　　　　　　　　　　_identifier　=　identifier　

　　　　　　　　　　　　　　　End　Sub　



　　　　　　　　　　　　　　　Public　ReadOnly　Property　Identifier　As　String　

　　　　　　　　　　　　　　　　　　　Get　　

　　　　　　　　　　　　　　　　　　　　　　　Return　_identifier　

　　　　　　　　　　　　　　　　　　　End　Get　

　　　　　　　　　　　　　　　End　Property　


…………………………………………………………Page　231……………………………………………………………

　　　　　　　　　　　　　　　　　　　　　　　　　　　　C　H　AP　TE　R　　　8　　　■　　　　L　E　AR　N　IN　G　　　AB　O　U　T　　　CO　M　P　O　N　E　N　T　O　R　IE　N　TE　D　　　A　R　CH　I　TE　C　TU　R　E　209　



　　　　Public　Overrides　Function　ToString（）　As　String　

　　　　　　　　Dim　buffer　As　String　

　　　　　　　　buffer　=　〃Me（〃　&　_identifier　&　〃）〃　

　　　　　　　　If　NextItem　IsNot　Nothing　Then　

　　　　　　　　　　　　buffer　=　buffer　&　〃　next（〃　&　_　

　　　　　　　　　　　　　　　　　　　　　DirectCast（MyBase。NextItem；　LinkedItem）。Identifier　&　〃）〃　

　　　　　　　　Else　　

　　　　　　　　　　　　buffer　=　buffer　&　〃　next（Nothing）〃　

　　　　　　　　End　If　

　　　　　　　　If　PrevItem　IsNot　Nothing　Then　

　　　　　　　　　　　　buffer　=　buffer　&　〃　prev（〃　&　_　

　　　　　　　　　　　　　　　　　　　　　DirectCast（MyBase。PrevItem；　LinkedItem）。Identifier　&　〃）〃　

　　　　　　　　Else　

　　　　　　　　　　　　buffer　=　buffer　&　〃　prev（Nothing）〃　

　　　　　　　　End　If　

　　　　　　　　Return　buffer　

　　　　End　Function　

End　Class　



　　　　　The　　LinkedItem　class　has　a　single　data　member　declaration；　_identifier；　which　is　used　　

to　identify　the　instance。　The　test　code　will　call　the　Insert（）　and　Remove（）　methods；　and　then　　

generate　a　visual　representation　of　the　linked　list。　The　visual　representation　is　used　to　under

stand　what　the　problem　might　be　if　anything　goes　wrong。　You　will　not　write　tests　against　the　　

visual　representation　because　that　would　overplicate　the　testing。　

　　　　　To　generate　a　visual　representation　of　the　object；　the　ToString（）　method　is　overridden。　By　　

default；　all　objects　have　a　ToString（）　implementation；　which　does　absolutely　nothing　other　　

than　spit　out　the　identifier　of　the　object　reference。　To　make　ToString（）　do　something　useful；　　

you　need　to　override　it。　In　the　example；　ToString（）　will　generate　a　buffer　that　contains　the　　

LinkedItem　identifier　and　the　next　and　previous　object　identifiers。　These　three　pieces　of　infor

mation　tell　you　the　structure　of　the　linked　list。　

　　　　　The　next　step　is　to　write　a　test　in　TestLightingSystem’s　Module1。vb　that　verifies　that　the　　

Insert（）　method　works　properly；　and　it　is　implemented　as　follows：　



　　　　Module　Module1　

　　　　　　　　Sub　Main（）　

　　　　　　　　　　　　TestInsert（）　

　　　　　　　　End　Sub　



　　　　　　　　Public　Sub　TestInsert（）　　

　　　　　　　　　　　　Console。WriteLine（〃**************〃）　

　　　　　　　　　　　　Console。WriteLine（〃TestInsert：　Start〃）　

　　　　　　　　　　　　Dim　item1　As　LinkedItem　=　New　LinkedItem（〃item1〃）　

　　　　　　　　　　　　Dim　item2　As　LinkedItem　=　New　LinkedItem（〃item2〃）　

　　　　　　　　　　　　Dim　item3　As　LinkedItem　=　New　LinkedItem（〃item3〃）　



　　　　　　　　　　　　Dim　toString　As　String　=　item1。ToString（）　

　　　　　　　　　　　　Console。WriteLine（toString）　

　　　　　　　　　　　　If　（item1。NextItem　IsNot　Nothing）　OrElse　_　


…………………………………………………………Page　232……………………………………………………………

210　　　　　　CH　AP　T　E　R　　　8　　　■　　　　L　E　A　R　N　IN　G　　　AB　OU　T　　　CO　M　P　O　N　E　N　TO　R　IE　N　T　E　D　　AR　C　HI　TE　CT　U　R　E　



　　　　　　　　　　　　　　　　　　　　　　　　　（item1。PrevItem　IsNot　Nothing）　Then　　

　　　　　　　　　　　　　　　　　　　　　　　　　　Throw　New　Exception（　_　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　〃TestInsert：　Empty　structure　is　incorrect〃）　

　　　　　　　　　　　　　　　　　　　　　　End　If　



　　　　　　　　　　　　　　　　　　　　　　item1。Insert（item2）　

　　　　　　　　　　　　　　　　　　　　　　toString　=　item1。ToString（）　

　　　　　　　　　　　　　　　　　　　　　　Console。WriteLine（toString）　

　　　　　　　　　　　　　　　　　　　　　　If　（item1。NextItem　IsNot　item2）　OrElse　_　

　　　　　　　　　　　　　　　　　　　　　　　　　（item1。PrevItem　IsNot　Nothing）　Then　

　　　　　　　　　　　　　　　　　　　　　　　　　　Throw　New　Exception（　_　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　〃TestInsert：　Item　1…》Item2　structure　is　incorrect〃）　

　　　　　　　　　　　　　　　　　　　　　　End　If　

　　　　　　　　　　　　　　　　　　　　　　toString　=　item2。ToString（）　

　　　　　　　　　　　　　　　　　　　　　　Console。WriteLine（toString）　

　　　　　　　　　　　　　　　　　　　　　　If　（item2。NextItem　IsNot　Nothing）　OrElse　_　

　　　　　　　　　　　　　　　　　　　　　　　　　（item2。PrevItem　IsNot　item1）　Then　　

　　　　　　　　　　　　　　　　　　　　　　　　　　Throw　New　Exception（　_　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　〃TestInsert：　Item　2…》Item1　structure　is　incorrect〃）　

　　　　　　　　　　　　　　　　　　　　　　End　If　

　　　　　　　　　　　　　　　　　　　　　　item2。Insert（item3）　

　　　　　　　　　　　　　　　　　　　　　　toString　=　item2。ToString（）　

　　　　　　　　　　　　　　　　　　　　　　Console。WriteLine（toString）　

　　　　　　　　　　　　　　　　　　　　　　If　（item2。PrevItem　IsNot　item1）　OrElse　_　

　　　　　　　　　　　　　　　　　　　　　　　　　（item2。NextItem　IsNot　item3）　Then　　

　　　　　　　　　　　　　　　　　　　　　　　　　　Throw　New　Exception（　_　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　〃TestInsert：　Item2…》Item1；　Item3　structure　is　incorrect〃）　

　　　　　　　　　　　　　　　　　　　　　　End　If　

　　　　　　　　　　　　　　　　　　　　　　toString　=　item3。ToString（）　

　　　　　　　　　　　　　　　　　　　　　　Console。WriteLine（toString）　

　　　　　　　　　　　　　　　　　　　　　　　If　（item3。PrevItem　IsNot　item2）　OrElse　_　

　　　　　　　　　　　　　　　　　　　　　　　　　　（item3。NextItem　IsNot　Nothing）　Then　　

　　　　　　　　　　　　　　　　　　　　　　　　　　Throw　New　Exception（　_　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　〃TestInsert：　Item3…》Item2；　structure　is　incorrect〃）　

　　　　　　　　　　　　　　　　　　　　　　End　If　



　　　　　　　　　　　　　　　　　　　　　　toString　=　item1。ToString（）　

　　　　　　　　　　　　　　　　　　　　　　Console。WriteLine（toString）　

　　　　　　　　　　　　　　　　　　　　　　toString　=　item2。ToString（）　

　　　　　　　　　　　　　　　　　　　　　　Console。WriteLine（toString）　

　　　　　　　　　　　　　　　　　　　　　　toString　=　item3。ToString（）　

　　　　　　　　　　　　　　　　　　　　　　Console。WriteLine（toString）　

　　　　　　　　　　　　　　　　　　　　　　Console。WriteLine（〃TestInsert：　End〃）　

　　　　　　　　　　　　　　　　　　End　Sub　

　　　　　　　　　　　　　　End　Module　


…………………………………………………………Page　233……………………………………………………………

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　C　H　AP　TE　R　　　8　　　■　　　　L　E　AR　N　IN　G　　　AB　O　U　T　　　CO　M　P　O　N　E　N　T　O　R　IE　N　TE　D　　　A　R　CH　I　TE　C　TU　R　E　211　



　　　　　This　test　generates　pretty　output　like　this：　



**************　

TestInsert：　Start　

Me　（item1）　next（Nothing）　prev（Nothing）　

Me　（item1）　next（item2）　prev（Nothing）　

Me　（item2）　next（Nothing）　prev（item1）　

Me　（item2）　next（item3）　prev（item1）　

Me　（item3）　next（Nothing）　prev（item2）　

Me　（item1）　next（item2）　prev（Nothing）　

Me　（item2）　next（item3）　prev（item1）　

Me　（item3）　next（Nothing）　prev（item2）　

TestInsert：　End　



　　　　　The　pretty　output　is　not　a　verification　of　what　went　right。　Rather；　the　extensive　output　　

makes　it　simpler　to　perform　postmortem　debugging　to　understand　why　something　failed。　　

　　　　　In　the　TestInsert（）　method；　a　situation　is　created　where　three　　LinkedItem　instances　are　　

instantiated：　item1；　item2；　and　item3。　Initially；　the　three　items　are　not　linked；　but　we　use　the　　

Insert（）　method　to　link　them　into　a　structure；　as　shown　in　Figure　8…4。　



Figure　8…4。　　Testable　doubly　linked　list　structure　



　　　　　But　to　get　to　the　structure　in　Figure　8…4；　some　intermediate　steps　are　required；　and　in　the　　

implementation　of　the　method　TestInsert（）；　those　intermediate　steps　are　tested。　The　NextItem　　

and　PrevItem　properties　for　each　and　every　item　are　tested　for　the　proper　values　at　each　step。　If　　

some　of　the　values　don’t　match；　an　exception　is　thrown　to　indicate　an　improper　structure。　If　an　　

exception　is　thrown；　the　generation　of　the　visual　structure　bees　important。　As　an　aside；　　

while　developing　the　Insert（）　and　Remove（）　algorithms；　the　visual　structures　and　test　code　　

helped　me　figure　out　a　bug。　

　　　　　The　TestInsert（）　method　is　an　example　of　an　exhaustive　test　of　a　context。　The　download

able　source　code　contains　several　other　examples　of　exhaustive　tests。　


…………………………………………………………Page　234……………………………………………………………

212　　　　　　　　CH　AP　T　E　R　　　8　　　■　　　　L　E　A　R　N　IN　G　　　AB　OU　T　　　CO　M　P　O　N　E　N　TO　R　IE　N　T　E　D　　AR　C　HI　TE　CT　U　R　E　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　DEBUGGING　AND　TESTING　TOOLS　



　　　　　　　　　　　　　　　Some　of　you　might　be　thinking　that　to　figure　out　why　a　test　failed；　you　should　use　a　debugger。　However；　with　　

　　　　　　　　　　　　　　　proper　tests　that　are　part　of　an　extensive　testing　framework　and　that　generate　extensive　output；　the　need　for　　

　　　　　　　　　　　　　　　a　debugger　is　reduced。　Among　the　people　who　believe　in　a　test…driven　development　（TDD）　environment　（including　　

　　　　　　　　　　　　　　　me）；　there　is　a　question　on　the　merits　of　a　debugger。　According　to　Wikipedia’s　Test…Driven　Development　entry　　

　　　　　　　　　　　　　　　（http：//en。wikipedia。org/wiki/Test…driven_development）；　“Programmers　using　pure　TDD　on　　

　　　　　　　　　　　　　　　new　（‘greenfield’）　projects　report　they　only　rarely　feel　the　need　to　invoke　a　debugger。　Used　in　conjunction　with　　

　　　　　　　　　　　　　　　a　Version　control　system；　when　tests　fail　unexpectedly；　reverting　the　code　to　the　last　version　that　passed　all　　

　　　　　　　　　　　　　　tests　may　often　be　more　productive　than　debugging。”　　

　　　　　　　　　　　　　　　　　　　　A　debugger　is　good　for　finding　problems；　but　bad　for　understanding　the　nature　of　the　problem。　Good　tests　　

　　　　　　　　　　　　　　　verify　scenarios。　The　more　scenarios；　the　more　tests；　and　the　more　tested　your　code　is。　If　a　particular　scenario　　

　　　　　　　　　　　　　　fails；　you　know　that　you　have　a　problem。　And　if　everything　was　OK　until　you　made　a　slight　change　that　caused　　

　　　　　　　　　　　　　　the　tests　to　fail；　you　know　you　have　a　problem。　Test　scripts　are　signposts　that　tell　you　what　is　working　and　　

　　　　　　　　　　　　　　　what　might　not　be　working。　By　using　a　debugger；　you　are　often　testing　large　chunks　of　code　where　you　need　　

　　　　　　　　　　　　　　to　labor　to　find　the　bug。　A　debugger　has　its　uses；　but　when　writing　good　tests　in　many　scenarios；　you　will　rarely　　

　　　　　　　　　　　　　　　need　to　use　it。　

　　　　　　　　　　　　　　　　　　　　And　speaking　of　writing　tests；　as　I　noted　in　Chapter　6；　in　this　book；　I　could　introduce　a　testing　framework　　

　　　　　　　　　　　　　　　like　NUnit　（http：//nunit。org）　or　Microsoft　Visual　Studio　Team　System　（http：//　

　　　　　　　　　　　　　　　msdn2。microsoft。/en…us/vstudio/default。aspx）。　When　you　are　writing　production　code；　you　　

　　　　　　　　　　　　　　　will　probably　use　such　a　testing　framework。　Testing　frameworks　do　not　help　you　to　write　your　tests；　but　rather　　

　　　　　　　　　　　　　　　help　you　by　providing　support　code　to　generate　errors；　log　problems；　and　indicate　progress　of　the　tests。　Do　　

　　　　　　　　　　　　　　　not　get　misled　by　tools　that　say　they　can　write　the　tests　for　you。　No　tool　can　write　your　tests；　because　that　　

　　　　　　　　　　　　　　　would　imply　the　tool　understands　the　context　of　your　code。　And　since　such　a　tool　does　not　yet　exist；　you　will　　

　　　　　　　　　　　　　　　need　to　write　your　own　tests。　



　　　　　　　　　　　　Implementing　Room　Groupings　　



　　　　　　　　　　　　Room　groupings　are　collections　of　rooms　that　fall　into　a　specific　organization。　The　idea　behind　　

　　　　　　　　　　　　a　grouping　is　to　perform　group　operations　without　having　to　explicitly　examine　a　room　before　　

　　　　　　　　　　　　performing　an　operation。　For　example；　in　the　case　of　the　museum；　we　don’t　need　to　figure　out　　

　　　　　　　　　　　　whether　a　room　is　public　or　private　each　time　a　global　operation　is　being　performed。　

　　　　　　　　　　　　　　　　　The　organization　of　the　collection　is　that　there　can　be　multiple　room　groupings　that　are　　

　　　　　　　　　　　　linked　together；　and　within　a　grouping；　there　are　multiple　rooms　that　can　be　grouped　together。　　

　　　　　　　　　　　　The　linked　list　structure　has　two　levels　and　is　coded　as　follows　（in　　LibLightingSystem）：　　



　　　　　　　　　　　　　　　　Class　RoomGrouping　　

　　　　　　　　　　　　　　　　　　　　Inherits　BaseLinkedListItem　

　　　　　　　　　　　　　　　　　　　　Public　Rooms　As　Room　

　　　　　　　　　　　　　　　　　　　　Public　Description　As　String　

　　　　　　　　　　　　　　　　End　Class　



　　　　　　　　　　　　　　　　Class　Room　　

　　　　　　　　　　　　　　　　　　　　Inherits　BaseLinkedListItem　

　　　　　　　　　　　　　　　　　　　　Public　ObjRoom　As　IRoom　

　　　　　　　　　　　　　　　　End　Class　


…………………………………………………………Page　235……………………………………………………………

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　C　H　AP　TE　R　　　8　　　■　　　　L　E　AR　N　IN　G　　　AB　O　U　T　　　CO　M　P　O　N　E　N　T　O　R　IE　N　TE　D　　　A　R　CH　I　TE　C　TU　R　E　213　



　　　　　The　class　declaration　Room　represents　an　individual　room。　But　notice　how　it　derives　from　　

BaseLinkedListItem；　which　seems　to　imply　that　Room　is　actually　many　rooms。　This　is　part　of　the　　

linked　list　implementation；　it　is　like　a　chain；　where　the　chain　is　created　by　individual　links。　

　　　　　The　RoomGrouping　class　has　two　data　members：　Rooms；　which　represents　the　list　of　rooms　in　　

the　grouping；　and　Description；　which　represents　an　easy…to…understand　description　of　the　　

grouping。　The　single　data　member　for　Room　is　a　reference　to　an　　IRoom　interface　instance。　　

　　　　　The　room　groupings　are　managed　by　the　　LightingController　class。　An　initial　implemen

tation　of　　LightingController　i