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