按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
144 CH AP T E R 6 ■ L E A R N IN G T HE B AS IC S O F OB J E CT OR I E N T E D P R O G R AM M IN G
In the modified implementation of Oven； the data member _temperature is not externally
exposed。 And in this situation； the role of the data member _temperature is not to represent the
temperature of the oven； but to act as an upper limit to which the oven should be heated。 The
upper limit is assigned using the SetTemperature（） method。 To check the temperature of the
oven； you don’t retrieve the temperature of the oven； but call the AreYouPreheated（） method。
The caller receives either a True or False value to indicate whether or not the oven is ready。
The caller of Oven has the responsibility only of setting the upper temperature and asking
if the oven is preheated。 From this example； it would seem that you don’t need properties。
However； you still need properties because Oven in its current form represents an easy…to…use
class that can be integrated at the architectural business…logic level。
The challenge of the developer is to bridge the gap between a raw structural class and the
exposure of an architectural business…logic…level class。 That challenge will be met when the
hotel currency trader and active currency trader are implemented。
Even with these arguments and the distinction between base class and architectural business
logic…level classes； some still naysay properties。 The reason has to do with controlling access。
Suppose you are in a grocery store； waiting at the cash register。 The cashier tallies up the
items； arrives at a total； and asks you to pay。 Do you open your purse or wallet and let the cashier
get the credit card or cash？ Along the same lines； why can’t you just place the cash into the cash
register？ The answer to these questions is one of trust。 As trustworthy as the cashier and shopper
might be； we feel better when we know we have the control。
Let’s go back to an example I mentioned at the beginning of the chapter： allowing people
to grab into your pockets。 The previously defined Temperature property is allowing someone to
grab into your pockets。 You wouldn’t generally allow it； but what if that person were your spouse
or your mom？ Would you still disallow it？ The answer is very different； because you probably
trust your mom or spouse。 In the same way； often state and its exposure are a matter of trust
and using the right scope。
■Note In this discussion of properties and object…oriented design； my goal is to explain that there is a place
and time for both； and you should not feel biased toward one approach or the other。 When you design a type
that does not reveal its state； you are designing a type that fulfills an abstract intention。 When you design a
type that reveals its state （to some extent） through properties； you are designing a type that is used at the
lower technical level。 Also keep in mind that sometimes internal state is external state； such as the exchange
rate example。 You cannot abstract away the exchange rate state because it is a number used in a calculation。
Understanding Inheritance and Scope Modifiers
At this point； the ExchangeRate property is a mechanical property that will be used by any class
that subclasses CurrencyTrader。 So now we need to decide whether access to the property
should be restricted。 The answer is that it should be restricted to only those developers who
truly understand how to convert currencies。 Access should be restricted to those classes that
will subclass CurrencyTrader。 Following is the rewritten version of CurrencyTrader。
…………………………………………………………Page 167……………………………………………………………
CH A PT E R 6 ■ L E A R N I N G T HE B AS IC S O F O B J E CT OR I E N TE D P R O G R AM M IN G 145
Public MustInherit Class CurrencyTrader
Private _exchangeRate As Double
Protected Property ExchangeRate（） As Double
Get
Return _exchangeRate
End Get
Set （ByVal value As Double）
_exchangeRate = value
End Set
End Property
End Class
The bolded code highlights three examples of scope access：
Public： The type； method； data member； or property can be accessed and referenced by
any other type。 In the context of a crowd of people； it means anyone can reach into your
pocket and inspect your wallet。
Private： The method； data member； or property can be accessed and referenced only by
the type declaring the method； data member； or property。 In the context of a crowd of
people； it means only you can reach into your pocket and inspect your wallet。
Protected： The method； data member； or property can be accessed and referenced by the
type declaring the method； data member； or property or by types that subclass the declaring
type。 In the context of a crowd of people； it means only you and people who you have
allowed can reach into your pocket and inspect your wallet。
If you happen to declare a type； method； or property without a scope modifier； the default
is assumed； which means public is implied。 Data members are private by default。 The Private
and Protected modifiers cannot be assigned to a type。 You’ll learn more about other modifiers
and details about type scope declarations in the next chapter。
Using Visual Basic Inheritance to Subclass Another Type
The rewritten version of CurrencyTrader will cause the test code to break； because it uses the
MustInherit keyword； and thus cannot be instantiated directly。 Here is the broken code：
Dim cls As CurrencyTrader = New CurrencyTrader（）
cls。ExchangeRate = 123。44
The code will not work for two reasons：
o CurrencyTrader uses the MustInherit keyword and thus cannot be instantiated。
o ExchangeRate is protected and cannot be referenced externally。
This broken code puts us in a bind。 Up to this point； whenever we tested code； we assumed
all of the pieces that were to be tested could be referenced。 One solution would be to change
the scope declarations and remove the MustInherit and Protected keywords。 Yes； that solves the
problem； but it is a cop…out。 The better approach is to test CurrencyTrader as it was intended to be
…………………………………………………………Page 168……………………………………………………………
146 CH AP T E R 6 ■ L E A R N IN G T HE B AS IC S O F OB J E CT OR I E N T E D P R O G R AM M IN G
used： as a class that is derived from。 So； the solution is to use inheritance and create a test class
that derives from CurrencyTrader； as follows：
Public Class TestCurrencyTrader
Inherits CurrencyTrader
Public Sub InitializeExchangeRate（）
ExchangeRate = 100。0
End Sub
End Class
TestCurrencyTrader is a test class that is added to the test source code。 To inherit from a
class； you define a class； and in the following line； use the keyword Inherits。 This line says that
the class TestCurrencyTrader is subclassing CurrencyTrader。
To expose a method outside the class declaration； you use the Public modifier。
Inheritance means identifiers that are scoped Protected or Public can be referenced in
the subclassed type。 For example； notice how ExchangeRate