Как реализовать многоуровневое наследование с помощью шаблона проектирования

1

Я ранее реализовал абстрактный шаблон Factory на простых задачах, и он сработал. Поэтому я попытался использовать одно и то же решение этой проблемы, но я был в замешательстве. Я написал классы нижнего уровня, но смутился, как объединить их с одной программой. Что я должен делать и как это сделать?

Я использую Java для написания кода для расчета налога. У меня есть базовый класс TaxPayer. Налогоплательщик может иметь несколько источников incomeSource. Существует много типов TaxPayer или IncomeSource. В качестве атрибутов, которые будут храниться в базе данных, может быть много источников дохода для разных источников дохода. Ставка налога будет различной для разных типов налогоплательщиков и суммы taxableIncome.

Базовый класс Налогоплательщик определяется как

public abstract class TaxPayer {
    private List<IncomeSource> incomeSource;
    double taxRate;
    Address address;
    other attributes here;

    public Double getTaxRate(){
        return 0.25; //default tax rate
    }
}

public abstract class IncomeSource {
    private String incomeSourceName;
    private Double incomeHeading1, incomeHeading2, incomeHeading3;
    private Double totalIncome = incomeHeading1 + incomeHeading2 + incomeHeading3;
}

Там может быть больше уровней IncomeSource наследования с разными заголовками дохода. Аналогичным образом тип налогоплательщика может быть смоделирован в следующую структуру наследования

Base Class: Taxpayer
    * IndividualPerson
        * Male, Female, OldAge
    * Business
        * Bank, ITIndustry, HydroElectricIndustry
    * TaxFree
        * SocialOrganization, ReligiousOrganization, PoliticalParty etc.

Подклассы TaxPayer обычно taxRate применяемый к taxableIncome а иногда и изменяют taxableIncome с некоторой логикой. Например:

abstract class IndividualPerson extends TaxPayer{
    if (incomeSource.taxableIncome > 250000) taxRate = ratex;
    if (incomeSource.taxableIncome > 500000) taxRate = ratey;
    @override
    public getTaxRate() {
        return taxRate;
    }
}
class Female extends IndividualPerson {
    if (incomeSource.getNumberOfIncomeSource() > 1) taxRate = taxRate + rate1;
    else taxRate = taxRate - rate2
    if (address.isRural() = true) taxRate = taxRate - rate3;
    if (attributeX = true) taxRate = taxRate + rate4;
    if ("Some other attribute" = true) taxableIncome = taxableIncome - someAmount;
}

Мы должны проверить другие атрибуты Taxpayer и IncomeSource для определения taxRate. В основном, taxRate отличается для различной логики, но иногда, taxableIncome можно сбрасывать со счетов.

Я пытаюсь вернуть ставку налога в соответствии с типом TaxPayer и taxableIncome. Я смущен, как объединить уровни нижнего уровня вместе.

  • 2
    Почему у вас такая сложная иерархия - например, как классы Male и Female Taxpayer что-то добавить? Я думаю, что вам нужно переосмыслить свои классы - вы должны подумать, когда у вас может быть параметр. Эффективная Java (большой pdf). Пункт 16. Композиция Favour по сравнению с наследованием. Например, в вашем случае Male / Female используйте enum .
  • 1
    Мужчины и женщины будут иметь разные налоговые ставки. Поэтому я подумал, что так будет лучше. Как это может быть изменено на состав, а не наследование?
Показать ещё 3 комментария
Теги:
oop
design-patterns
inheritance

1 ответ

1

Создайте Taxpayer как parent interface а три ниже в иерархии реализуют его. Этот интерфейс taxpayer будет иметь метод getTaxRate() который должен быть реализован всеми дочерними классами.

Вы можете сделать business класс еще одним интерфейсом, расширяющим интерфейс материнского taxpayer и сделать bank,hydroelectricity класс bank,hydroelectricity расширить business интерфейс.

каждый из bank,hydroelectricity т.д. будет иметь final float с желаемой ставкой налога.

Предположим, что A - это класс человека, который имеет бизнес в Банке, поэтому в этом случае

A implements Bank

Это обеспечит конкретный налог для банка в A.

Но лучшим вариантом было бы иметь bank,hydroelectricity и т.д., как ENUMS в рамках business - класса, который должен реализующими Taxpayer интерфейс.

Лучший подход

public enum Business {
        BANK(10.1), ITINDUSTRY(8.1), HYDROELECTRICITY(1.3);
        private float value;

        private Business(int value) {
           this.value = value;
        public float getTaxRate(){
           return this.value;
        }
};   

class A implements TaxPayer{
     public String occupation = "BANK";

    //implemented from parent taxpayer 
    public float getTaxRate(){
        return Business.BANK.getTaxRate();
    }
}

И если сегрегация у налогоплательщика не важна, вы можете объединить все классы самого низкого уровня под единым ENUM.

Сделайте что-то вроде выше. Надеюсь, это даст вам более четкую идею.

Поделиться
  • 1
    Я не думаю, что это вообще правильно. taxRate - это переменная, а не поведение - использование иерархии классов для этого не является правильным подходом.
  • 0
    Согласованное использование иерархии не является подходящим подходом, поэтому в конце я предложил использовать ENUMS. Я также объяснил это как иерархию, так как человек, задающий вопрос, хотел смоделировать его таким образом. По крайней мере, это то, что я понял из вопроса.
Показать ещё 6 комментариев

Ещё вопросы

Сообщество Overcoder
Наверх
Меню