按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
■Note The order of which is the parent and which is the child is my logic； some might disagree。 This
disagreement is healthy and part of the object…oriented design process。
The first model that you would design would probably be the rear…wheel…drive model；
since it is simpler to design； cheaper； and more popular。 You would consider all…wheel drive as
a feature。 The all…wheel…drive model is not a pletely new car。 Both the 530i and 530xi would
share the same tires； motor； steering wheel； body trim； and so on。 What would be different is
that the 530xi replaces the power train； thus changing the behavior of the car。
Let’s say that you are a driver sitting in the seat driving your BMW； and it’s a snowy night
in Canada。 Whether you are driving the 530i or the 530xi； you would use the same steering
wheel； blinkers； gas pedal； brake； and so on。 But the behavior of the 530i and 530xi would be
different—the rear…wheel…drive car might slide around a bit more than the all…wheel…drive car。
The power train overrides behavior； which means the consumer of the hierarchy sees the same
interface （for example； methods and properties）； but gets different behavior。
Another way to use inheritance is not to replace functionality； but to enhance function
ality； as illustrated in Figure 6…2。 This is called overloading behavior。
…………………………………………………………Page 163……………………………………………………………
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 141
Figure 6…2。 A more extensive inheritance tree illustrating how functionality can be enhanced
In Figure 6…2； all of the cars are related in that they are the 530 line。 The new model is the
BMW 530xi Sports Wagon； which； from an inheritance perspective； is based on the function
ality of the BMW 530xi。 But here is the twist： the functionality of the 530xi Sports Wagon requires
you to get accustomed to the Sports Wagon。 For example； even though you press a single
button to open the trunk； the Sports Wagon’s trunk is slightly different from the trunk in the
530xi and 530i； and thus exposes the driver to a slightly different user interface and behavior。
When you use inheritance to overload functionality； you are adding functionality that is
called in the same way； but is used and behaves differently。 With this form of inheritance； you
don’t just change behavior； you also change the user interaction。
In our example； we will use inheritance to extend functionality； and not override or overload。
Using Visual Basic Properties
So far； the test code would call a data member reference； as in this line：
cls。ExchangeRate = 123。45
The data member could be implemented as follows：
Public MustInherit Class CurrencyTrader
Public ExchangeRate As Double
End Class
Exposing the data member using a public scope worked in previous chapters； but we don’t
really want to do this because we are exposing the internal state of the object。 In object…oriented
programming； exposing the internal state is a bad idea （as explained in more detail shortly）。
…………………………………………………………Page 164……………………………………………………………
142 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
Rather than expose the data member publicly； we will change the test code to use properties。
Properties also expose the internal state of an object； but they provide a layer of abstraction。 As
you will learn； some properties expose both internal state and external state。 This is the case
with the ExchangeRate property that we will use to access and modify the exchange rate。 If we
did not use the ExchangeRate property； we would need to create a method that assigns the
exchange rate and a method that retrieves the exchange rate。 The methods would behave like
the property； but they would not be as convenient to use。
Rewriting the Test Code to Use Properties
The interesting thing about Visual Basic properties is that they look and behave like data members。
This means with Visual Basic properties； the test code does not need to be rewritten； as the test
code still assumes a direct access to the variable。 Consider the rewritten CurrencyTrader that
exposes ExchangeRate as a Visual Basic property； shown in Figure 6…3。
Data member ExchangeRate is relabeled to
Public MustInherit Class CurrencyTrader _exchangeRate； and the scope is changed
Private _exchangeRate As Double from public to private
Public Property ExchangeRate（） As Double
Get
Return _exchangeRate A Visual Basic property declaration looks like a
End Get function declaration without the parameters； and
Set（ByVal value As Double） instead of Function； Property is used
_exchangeRate = value
End Set
End Property
End Class What makes a property uniquely
different from a function are the Get
and Set keywords used to return and
assign the value of the property
Figure 6…3。 Exposing ExchangeRate as a Visual Basic