按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
ability to make decisions based on whether an instance would like to be associated with a particular grouping
based on an interface。
Defining the IRemoteControlRoom Interface
Another type of room is one where the lighting is pletely managed by the controller。 The
controller does not seek the input of the room and manages the lighting based on the logic that
seems appropriate to it。
For example； a public…viewing area in a museum does not require light at certain times of
day。 When the museum is closed and the cleaners are finished； the lights can be turned off。 When
the museum is open； the lights are turned on。 This is a simple logic and can be pletely
managed by the controller。
The interface for the controlled room is defined as follows （in LibLightingSystem）：
Public Interface IRemoteControlRoom
Inherits IRoom
ReadOnly Property LightLevel（） As Double
Sub LightSwitch（ByVal lightState As Boolean）
Sub DimLight（ByVal level As Double）
End Interface
The only input that IRemoteControlRoom provides is information about whether the light is
on； off； or at a certain level。 This is through the LightLevel property。 The LightLevel property
is read…only； because the controller and the light level might bee out of sync。
For example； suppose it’s time for the museum to close； and the lights are switched off in
the public…viewing area。 But today； the cleaners took a little while longer than usual。 They turn
the lights back on so that they can see what they are doing。 The local device can do one of two
things： allow the light to be turned on without the approval of the controller； or not allow the
light to be turned on； requiring a controller intervention。 The best approach is to allow a local
override and let the cleaners turn on the light。 The LightLevel property is necessary so that the
controller can verify if the state of the light is what the controller expects it to be。
■Note When you are defining a kernel； sometimes it is necessary to add functionality into an interface that
verifies the state of the implementation。 Because the kernel is not in control of the implementation； the kernel
should not assume the state； as the state could change for some reason。 In the case of the lighting system；
the change could be due to a cleaner turning on the light after it was turned off。
…………………………………………………………Page 225……………………………………………………………
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 203
The IRemoteControlRoom methods LightSwitch（） and DimLight（） turn the light on or off
and set the light to a certain level； respectively。 These methods are used to control the state of
the implementation。
Defining the ISensorRoom Interface
Another type of room is one that can be controlled under certain circumstances。 Let’s go back
to the cleaner example where the cleaner turned on the light。 If the controller notices that the
light is on； even though it was turned off； should the controller turn off the light？ You might say
sure； the controller should turn off the light。 However； that is not pletely correct。 Imagine
the situation where the cleaner turns on the light and the controller turns it off。 The cleaner would
immediately turn the light back on； and the controller would turn it off。 The cleaner would tape
the light switch down so that a constant battle of the light going on and off ensues （because this
battle is in milliseconds； the light remains on）。 A smarter approach would be to allow a timing
of the light。 But how much time—a quarter of an hour； a half hour； an hour？
Another approach is not to use a time interval； but to enhance the interface and allow the
controller to figure out the state。 This enhanced interface； called ISensorRoom； is defined as
follows （in LibLightingSystem）：
Public Interface ISensorRoom
Inherits IRemoteControlRoom
ReadOnly Property IsPersonInRoom（） As Boolean
End Interface
The ISensorRoom interface has a single property IsPersonInRoom； which is a Boolean prop
erty。 If the property has a value of True； then a person is in the room； otherwise； no person is in
the room。 How the implementation determines whether or not a person is in the room is not
the problem of the kernel。 The kernel assumes the implementation knows how to figure this
out。
■Note As a general rule of thumb； the kernel can municate with the implementation only via the inter
face。 The kernel should never assume a certain implementation of an interface。 The kernel should take the
approach that what it sees is what it gets。 Thus； if the kernel needs additional information； the interface
should be extended during design； or another interface should be implemented。 Of course； this does not mean
for every piece of state the interface should be extended。 Sometimes； you will need to define a specific inter
face； such as in the tax application example in the previous chapter （ ICanadianTaxEngine）。
Now that we’ve created the interfaces； we’re ready to implement the kernel。
Implementing the Kernel
In this example； the kernel will be a single class that contains all of the functionality of the
controller。 This definition means that the individual implementations； testing； and applica
tions will interact with a single class。
…………………………………………………………Page 226……………………………………………………………
204 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
Here is an example of implementing the light…dimming method using the
LightingController class （in LibLightingSystem）：
Public Class LightingController
Public Sub DimLights（ByVal grouping As Object； ByVal level As Double）
End Sub
End Class
The user of LightingController would dim a light using this code：
Dim controller As LightingController = New LightingController（）
Dim grouping As Object = Nothing
controller。DimLights（grouping； 0。50）
The user code instantiates the type LightingController directly and uses the method
DimLights（） directly。 Using classes directly has the cost that the controller code cannot change
without affecting the users； as there is a tight coupling between the user code and the kernel。
And this is why I have been writing at length about using interfaces； ideas； and implementa
tions。 Yet； the controller appears to throw all of that out of the window。
The reason for using a class goes back to the previous chapter’s example and the interfaces
ITaxDeduction and ITaxIne。 That example had only a single implementation of each inter
face； and those implementations were not going to change。 As I explained in the previous chapter；
the interfaces could have been represented as classes。 The same logic applies with respect to
the controller。 The controller is not going to change much from a method and property signature
perspective； and there is going to be only a single implementation of the controller。 Therefore； an
interface is not necessary。 Using a class is pletely acceptable； and it’s the approach we’re
using in this chapter。 However； I’ll talk about when you might want to implement the kernel as