《VB2008从入门到精通(PDF格式英文版)》第161章

of　type　IDefinition。　
Is　it　correct　to　assume　that　the　dynamic　loading　of　a　type　can　fulfill　the　contract　of　DoIt（）？
Can　you　assume　that　the　type　even　supports　IDefinition？　
What　convention　over　configuration　attempts　to　do　is　create　pockets　of　self…contained
functionality　that　can　take　care　of　themselves。　That　self…contained　functionality　may　require
configuration　file　settings；　and　it　may　require　other　assemblies。　But　what　it　does　not　require　is
a　directive　that　includes　source　code　that　explicitly　states　what　to　do　when。
Consider　a　workplace　scenario。　Instead　of　having　a　manager　tell　the　workers　what　to　do　at
every　step；　a　certain　amount　of　peer…to…peer　intelligence　and　self…reliance　are　assumed。　The
self…reliance　is　both　good　and　bad。　It　is　good　in　that　there　are　fewer　moving　parts；　but　bad　in
that　the　peers　might　be　doing　something　that　they　should　not。　
The　following　code　shows　an　example　of　convention。　
Interface　Imand
Sub　Run（）　
End　Interface　
。　。　。　
ConfigurationLoader。Instance。Load（）　
Dim　definition　As　IDefinition　=　_　
ConfigurationLoader。Instance。Instantiate（Of　Imand）（〃Impl1〃）　
definition。Run（）　
…………………………………………………………Page　360……………………………………………………………
338 CH　AP　T　E　R 1　2 ■ L　E　A　R　N　I　N　G A　B　OU　T A　PP　L　I　CA　TI　O　N CO　N　F　I　G　U　R　AT　IO　N AN　D D　Y　N　A　M　I　C L　O　AD　I　N　G　
The　code　runs　some　other　code　via　the　Run（）　method　and　does　not　have　any　return　values
or　parameters。　The　code　doing　the　executing　is　hoping　that　everything　will　work　out；　because
it　cannot　check　a　return　value。　And　that　is　the　gist　of　convention　over　configuration—the
calling　code　hopes　everything　will　work　out。
For　the　most　part；　convention　works　out　quite　nicely　because　it　is　easier　to　extend　and
maintain　a　convention…based　system；　since　there　are　fewer　moving　parts。　For　any　plex
system；　the　fewer　moving　parts　the　better。　The　downside　is　that　the　administrator　needs　to
understand　what　the　moving　parts　are。
People　have　a　tendency　to　make　everything　configurable　and　leave　nothing　to　the　puter
program。　Whether　or　not　something　works　depends　on　how　the　configuration　is　written。　In
a　convention　architecture；　the　called　functionality　will　make　decisions　about　what　it　deems
appropriate。　
Here　is　an　example　of　configuration：　
_　
Public　Property　TypeName（）　As　String　
Get
Return　CStr（MyBase。Item（_propTypeName））　
End　Get　
End　Property　
The　code　should　look　familiar；　as　it　reassembles　the　configuration　code　you　saw　earlier。
But　this　code　is　overconstrained　and　requires　too　many　moving　parts。　It　would　be　great　to
simplify　it　to　the　following　code　（which　does　not　pile　because　you　cannot　change　the　code
base　of　the library）。　
_　
Public　ReadOnly　Property　TypeName（）　As　String　
Get
Return　CStr（MyBase。Item（_propTypeName））　
End　Get　
End　Property　
The　difference　between　the　two　code　pieces　is　the　missing　parameters　in　the attributes。
The　parameters　are　not　necessary　because　they　are　already　defined　by　the　data　member
_propTypeName；　and　you　can　use　the　identifier　of　the　property　as　that　extra　piece　of　informa
tion。　So　the　property　identifier　TypeName　could　be　used　as　an　identifier　for　an　XML　attribute。　
Some　may　argue　that　by　having　a　cross…reference　between　the　property　identifier　and
configuration　identifier；　you　are　creating　a　hard…coded　dependency。　That’s　a　valid　argument。
But　is　the　code’s　assumption　a　mon…sense　assumption？　Is　it　an　extreme　proposition　to　say
that　your　property　identifier　is　the　name　of　your　XML　attribute？　The　answer　is　that　it　is　not　an
extreme　proposition；　and　the　Ruby　on　Rails　creators　said　the　same　when　creating　their　own
architecture。　
Let’s　now　consider　the　ability　to　indicate　whether　a　configuration　item　is　required。　By
specifying　whether　or　not　an　attribute　is　required；　you　can　avoid　an　exception　at　a　later　point。
However；　think　about　the　bigger　context。　The IsRequired　attribute　is　processed　when　the
program　is　started。　The　validity　of　the　configuration　file　is　not　processed　at　pile　time；　and
thus　the　only　thing　that　IsRequired　does　is　generate　an　exception　earlier。　Maybe　you　want　to
avoid　any　runtime　errors　that　could　bring　down　a　program　during　processing。　I　don’t　think　it　is
…………………………………………………………Page　361……………………………………………………………
CH　AP　T　E　R 1　2 ■ L　E　AR　N　IN　G AB　O　U　T AP　P　L　I　CAT　I　ON CO　N　F　IG　U　R　AT　IO　N A　N　D D　Y　N　A　M　IC L　O　AD　IN　G　339　
a　big　advantage；　but　I　am　sure　others　will　think　it　is；　and　thus　using　the　IsRequired　property
is　a　judgment　call。
■Note The　aim　of　convention…based　architecture　is　to　make　as　many　assumptions　as　possible；　without
sacrificing　the　bigger　goal　of　the　application。　A　good　convention…based　architecture　is　not　easy　to　create
because　it　requires　pletely　understanding　the　needs　of　the　developers　and　those　who　run　the　application。
My　personal　rule　of　thumb　is　to　solve　the　problem　first；　and　then　decide　what　should　be　configured　and　what
should　be　a　convention。　
Dynamically　Loading　Base　Class　or
Interface　Types　
This　chapter　demonstrated　two　categories　of　code　that　were　dynamically　loaded。　The　first　cate
gory　was　a　type　that　implemented　an　interface　（Implementation　and　IDefinition）。　The　second