Главная » C# » Стандартные реализации приложения для вычисления налогов Visual C# (Sharp)

0

В некоторых случаях в базовых классах нет необходимости. Иногда можно просто создать стандартную реализацию, которая может охватывать несколько подсистем. В случае с движком для вычисления налогов, доход есть доход,  что в Канаде, что в Соединенных Штатах, что в Германии. Разница заключается в том, каким обром доход обрабатывается при вычислении налогов. Еще одним постоянным аспеом для всех стран является то обстоятельство, что капитальный доход облагается только частичным налогом.

Для дохода можно создать реализацию, одинаковую для разных движков для вычисления налога:

sealed class Taxlncome : ITaxIncome { double „amount;

double „taxableRate;

public Taxlncome(double amount, double taxableRate) {

_amount = amount;

_taxableRate = taxableRate;

}

public double RealAmount { get {

return „amount;

}

}

public double TaxableAmount { get {

return „amount * „taxableRate;

}

}

}

Интерфейс iTaxincome имеет два свойства, которые реализуются в классе Taxlncome: RealAmount И TaxableAmount. Значения ЭТИ Х двух СВОЙСТ В считаются доступными только для чтения и определяются конструктором класса Taxlncome. Назначением конструктора является присвоить эти два значения, после чего объект становится   неизменяемым.   Таким   образом,   изменить   значения   в   интерфейсе

8 Зак.  555

ITaxIncome можно, только создав новый экземпляр класса Taxincome. Хотя создие нового экземпляра каждый раз, когда нам нужно изменить значения свойств ReaiAmount и TaxabieAmount, может показаться дополнительной работой, данный подход имеет определенные преимущества в терминах производительности и упраения ресурсами.

В коде  примера свойство TaxabieAmount является результатом умножения членов данных _amount и _taxableRate. Например, при вычислении налогооблагаемой части капитальных доходов в Канаде общая сумма умножается на 50%. Поэтому значение члена данных _taxabieRate будет о. 50.

Следует также обратить внимание на то, что в объявление класса Taxincome оасть видимости указана не как public, а как sealed. Это означает, что из данного класса нельзя получать производные классы. В аспекте проектирования, это говит, что класс Taxincome является разделяемым и не подлежит наследованию, чты не повлиять каким-либо образом на разделяемое поведение.

Ключевое слово sealed может также применяться с методами; такие методы нельзя подменять или перегружать. Обычно ключевое слово sealed используется с метом, когда мы не хотим, чтобы производный класс изменял поведение метода.

Реализация класса  ITaxDeduction похожа на реализацию класса  ITaxIncome:

sealed class TaxDeduction : ITaxDeduction { double _amount;

public TaxDeduction(double amount) {

_amount = amount;

}

public double Amount { get {

return _amount;

}

}

}

Область видимости классов Taxincome И TaxDeduction объявлена как seladed, Т. К. их функциональность будет общей для всех реализаций. Но разумно ли предостаять интерфейсы, а не сами классы? Интерфейсы применяются как средство для отделения реализаций от идей. Интерфейсы меняются очень редко, в то время как реализации могут меняться и в действительности меняются чаще. Но если реализия ведет себя подобно интерфейсу в терминах изменения сигнатуры  интерфейса, то почему бы не предоставлять сам класс? Потому, что иногда мы будем предтавлять класс, а иногда — интерфейс. Для движка для вычисления налогов проставление классов Taxincome И TaxDeduction, имеющих область ВИДИМОСТИ sealed, скорее всего,  не оказалось бы проблемой. Практическим правилом в даом  аспекте будет предоставлять  классы только тогда,  когда  имеется уверенность в том, что сигнатуры интерфейсов методов  и  свойств  не  будут меняться  слиом часто.

Источник: Гросс  К. С# 2008:  Пер. с англ. — СПб.:  БХВ-Петербург, 2009. — 576 е.:  ил. — (Самоучитель)

По теме:

  • Комментарии