按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
gory was a type that implemented an interface （Implementation and IDefinition）。 The second
type was a class that subclassed another class （ LoaderSection； ConfigurationSection）。 Each
approach has its advantages and disadvantages； but there is a single rule that you can use。
Whether to use an interface or class depends on how much responsibility you want to
delegate to the implementation。 In the configuration processing example； the infrastructure
specifically indicated that the only responsibility of the dynamically loaded class is to indicate
which identifiers should be processed。 How the value of the identifiers are extracted and converted
into types is the responsibility of the base class。
When you instantiate a type and use an interface； you are delegating plete control to
the dynamically instantiated type。 The calling code is explicitly saying； “Here is your contract。
How you deal with it is your responsibility。 Just make sure to implement the contract properly。”
By delegating all the responsibility； you are； in a sense； asking for trouble； because developers
might implement a contract incorrectly。
The Important Stuff to Remember
In this chapter； you learned about configuring an application and dynamically loading code
that is executed。 The main items to remember are as follows：
o A application configuration file works only because there is code in the application
that uses the specified items in the configuration file。
o Applications have application configuration files where the name of the file is the
name of the executing application appended with a 。config。
o A application configuration file is a specially formatted XML file。
o A application configuration file applies to a specific assembly loaded by the
application。
o The default scenario for a application configuration file is to store the settings as
key/value pairs in the section。
…………………………………………………………Page 362……………………………………………………………
340 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
o You can enhance the application configuration file； but that implies implementing
types that specifically outline which XML nodes and attributes are to be present in the XML。
o When processing data； you sometimes need a type （such as ConfigurationInfo） that is
used to store information in a structured manner for a specific reason。
o has plenty of functionality that allows a developer to dynamically execute code。
o One way of dynamically executing code is to load an assembly； instantiate a type； and
then cast the instance to a specific known type。
o You can instantiate private types declared in an assembly。
o You can use the GAC to store assemblies that will be shared by multiple applications。
o Use the GAC only if you must。 If you do use the GAC； you need to create strongly named
assemblies using signing。
o Regardless of how an assembly is versioned； a version number should exist and be used。
o In convention…based coding； your code makes assumptions about its behavior。
Convention…based coding is more pact； but because assumptions are made； the
code is less flexible。 However； do not confuse flexibility with being the best way to do
something。 You should have flexible code when you need it； not just because it can be
written that way。
Some Things for You to Do
The following are some exercises for you to do to apply what you’ve learned in this chapter。
1。 Rewrite the configuration code so that the configuration file specifies a directory where
all assemblies in that directory are loaded。
2。 Having read all of the assemblies with the rewritten configuration； call a predefined
type that will tell the caller which types are available and their appropriate types。
3。 Modify ConfigurationLoader so that it uses the new configuration architecture to
instantiate types。
…………………………………………………………Page 363……………………………………………………………
C H A P T E R 1 3
■ ■ ■
Learning About Multithreading
Your brain allows you to multitask。 For example； you can prepare dinner while talking on the
telephone。 However； this multitasking has limits； and you can do only two or three things
simultaneously。 But suppose you could put down the work； start another piece of work； then
put that down； and then switch to the original work。 How many tasks could you handle at the
same time？ Probably a few hundred； because what you are doing is serializing the multitasking。
Now suppose you and another person are preparing dinner in the kitchen； but you are not
municating with each other。 What is the likelihood that you will run into the other person？
Probably pretty high。 What I am trying to get across here is the difference between multitasking
with a single brain and multitasking with multiple brains。 Multitasking always has a cost； which is
orchestration。 And sometimes doing more multitasking is not going to speed things up。 There
is a limit to how many brains are required to run an efficient kitchen。
The focus of this chapter is how to write code that is capable of multitasking。 The operating
system multitasks； by default； but whether or not your program multitasks depends on how
you write your code。 For example； suppose the lighting controller introduced in Chapter 8 had
to control 3；000 rooms？