按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
resource management。
In the sample code； the TaxableAmount property is the result of multiplying the data members
_amount and _taxableRate。 For example； when calculating the taxable ine of a capital gain
in Canada； you multiply the total amount by 50％。 Thus； the _taxableRate data member would
have a value of 0。50。
Another item to note is that the declaration of TaxIne is lacking a Public scope； but has
a NotInheritable keyword prefixed to the identifier。 When a class is prefixed with NotInheritable；
it means that the class cannot be subclassed。 From a design perspective； the code is saying
TaxIne is a shared class that should not be subclassed lest it affect the shared behavior。
The NotInheritable keyword can also be applied to a method； which means that the method
cannot be overloaded or overridden。 You would use NotOverridable on a method when you do
not want a derived class to change the behavior of the method。 Though to be able to use the
NotOverridable keyword； you first need to define a method that overrides another method。
…………………………………………………………Page 202……………………………………………………………
180 CH AP T E R 7 ■ L E A R N IN G AB OU T CO M P O N E N TS AN D C L AS S H I E R AR C H IE S
The implementation of ITaxDeduction is similar to ITaxIne：
NotInheritable Class TaxDeduction
Implements ITaxDeduction
Private _amount As Double
Public Sub New（ByVal amount As Double）
_amount = amount
End Sub
Public ReadOnly Property Amount（） As Double _
Implements ITaxDeduction。Amount
Get
Return _amount
End Get
End Property
End Class
TaxIne and TaxDeduction are sealed classes because the functionality will be shared
among implementations。 But is it wise to expose the interfaces and not the classes themselves？
Interfaces are used to separate implementation from ideas。 Interfaces change very little； whereas
implementations can and will change more often。 But if an implementation behaves like an
interface in terms of changing interface signature； why not just expose the class itself？ The
answer is that sometimes you will expose the class； and sometimes you will expose the interface。
For the tax engine； exposing the sealed classes TaxIne and TaxDeduction would probably
have been fine。 The rule of thumb is that you expose classes only when you are sure that the
interface signatures of methods and properties will not change very often。
Implementing a Base Tax Account
The ITaxAccount interface is also a candidate for base class functionality。 The implementation
of this interface looks like this：
MustInherit Class BaseTaxAccount
Implements ITaxAccount
Private _deductions（100） As ITaxDeduction
Private _ines（100） As ITaxIne
Public Sub AddDeduction（ByVal deduction As ITaxDeduction） _
Implements ITaxAccount。AddDeduction
For c1 As Integer = 0 To 100
If _deductions（c1） Is Nothing Then
_deductions（c1） = deduction
Exit For
End If
Next
End Sub
…………………………………………………………Page 203……………………………………………………………
CH AP T E R 7 ■ L E AR N IN G AB O U T CO M P O N E N TS AN D C L AS S H I E R AR C HI E S 181
Public Sub AddIne（ByVal ine As ITaxIne） _
Implements ITaxAccount。AddIne
For c1 As Integer = 0 to 100
If _ines（c1） Is Nothing Then
_ines（c1） = ine
Exit For
End If
Next
End Sub
Public ReadOnly Property Deductions（） As ITaxDeduction（） _
Implements ITaxAccount。Deductions
Get
Return _deductions
End Get
End Property
Public ReadOnly Property Ine（） As ITaxIne（） _
Implements ITaxAccount。Ine
Get
Return _ines
End Get
End Property
Public MustOverride Function GetTaxRate（ByVal ine As Double） As Double _
Implements ITaxAccount。GetTaxRate
End Class
Let’s take stock of what has been acplished and decide if the tax engine is plete
from a base functionality perspective。
o Ideas have been defined for a plete tax engine。
o Some interfaces have been implemented in the form of base classes。
o Some interfaces have been implemented as sealed default implementations。
The tax engine can be considered plete because all of the interfaces have been defined
and accounted for from a base functionality perspective as either base classes or default imple
mentations。 It is does not mean that interfaces will always be implemented。 Sometimes some
interfaces will not have a base functionality or base classes。
The important aspect to remember when defining the base functionality is to account for
all interfaces to serve a purpose。 Do not define an interface as a placeholder for potential future
functionality。 When seeing an interface； a user expects it to serve some type of purpose。
…………………………………………………………Page 204……………………………………………………………
182 CH AP T E R 7 ■ L E A R N IN G AB OU T CO M P O N E N TS AN D C L AS S H I E R AR C H IE S
■Note The rule of thumb for interfaces is that once defined and put into production； they are not changed。
This rule of thumb is almost written in concrete。 You never change interfaces once they are in production