Блог

Способ, которым вы вычисляете цену для данного участка, — это ответственность, которая не должна принадлежать объекту данных.

Учитывая то, что вы мне сказали, вот как я бы реализовал, чтобы попытаться учесть будущие соображения:

 public interface IParcel {
    int SourceCode { get; set; }
    int DesinationCode { get; set; }
    int Weight { get; set; }
}

public class PricingCondition {
    //some conditions that you care about for calculations, maybe the amount of bulk or the date of the sale
    //might possibly be just an enum depending on complexity
}

public static class PricingConditions {
    public static readonly PricingCondition FourthOfJulyPricingCondition = new PricingCondition();
    public static readonly PricingCondition BulkOrderPricingCondition = new PricingCondition();
    //these could alternatively come from a database depending on your requirements
}

public interface IParcelBasePriceLookupService {
    decimal GetBasePrice(IParcel parcel);
    //probably some sort of caching
}

public class ParcelPriceCalculator {
    IParcelBasePriceLookupService _basePriceLookupService;

    decimal CalculatePrice(IParcel parcel, IEnumerable<PricingCondition> pricingConditions = new List<PricingCondition>()) {
        //do some stuff
    }
    decimal CalculatePrice(IEnumerable<IParcel> parcels, IEnumerable<PricingCondition> pricingConditions = new List<PricingCondition>()) {
        //do some stuff, probably a loop calling the first method
    }
}
  

Это IPriceCalculator было бы лучшей практикой для принципа единой ответственности.

Но изменение подписи метода на decimal CalculatePrice(IParcel parcel); метод вызывает метод CalculatePrice() IParcel, чтобы получить базовую цену для каждой посылки.

Совет, который я бы предложил, будет в некоторой степени зависеть от того, как вы собираетесь генерировать и использовать полиморфы участков. Я имею в виду, что мы не можем видеть, какие критерии используются для определения того, является ли что-то «Экспресс» или «Особенным», и связаны ли эти критерии со свойствами самого участка или с каким-либо внешним фактором.

Сказав это, я думаю, что ваша интуиция хороша в том, чтобы отделить расчет цены от самого объекта посылки. Как указал kmkemp, посылка не должна выяснять, как рассчитать цену посылки в зависимости от типа посылки. Посылка — это объект типа передачи данных / POCO, по крайней мере, как указано в вашем указании веса, источника и т. Д.

Однако я не совсем понимаю, почему вы используете эти интерфейсы. Не поймите меня неправильно — интерфейс хорош для развязки и тестируемости, но зачем нужен интерфейс parcel в дополнение к абстрактному базовому классу с абстрактным методом. Лично, исходя только из имеющейся у меня информации, я бы сделал это:

 public class Parcel
{
    int SourceCode { get; set; }
    int DestinationCode { get; set; }
    int weight { get; set; }
}

public abstract class GeneralCalculator
{
    //Statics go here, or you can inject them as instance variables
    //and they make sense here, since this is presumably data for price calculation
    protected static ReadOnlyDictionary<int, List<int>> _States_neighboureness;
    protected static ReadOnlyCollection<City> _Citieslist;
    protected static ReadOnlyCollection<Province> _Provinceslist;
    //.... etc

    public abstract Decimal CalculatePrice(Parcel parcel);
}

public class ExpressCalculator : GeneralCalculator
{
    public override decimal CalculatePrice(Parcel parcel)
    {
        return 0.0M;
    }
}

public class SpecialCalculator : GeneralCalculator
{
    public override decimal CalculatePrice(Parcel parcel)
    {
        return 0.0M;
    }
}
  

Но, опять же, я не знаю, как на самом деле обрабатываются посылки. Вам может потребоваться некоторая модификация этой концепции в зависимости от того, как вы генерируете, а затем обрабатываете посылки. Например, если тип участка зависит от значений свойств участка, вы можете определить фабричный метод или класс, который принимает участок и возвращает соответствующий экземпляр калькулятора.

Но, как бы вы его ни модифицировали, я бы определенно проголосовал за вашу мысль о том, чтобы отделить определение участка от схемы расчета его цены. Хранение и обработка данных — это отдельные проблемы. Я бы также не стал голосовать за статический класс где-нибудь, содержащий глобальные настройки, но это мой личный вкус — такие вещи слишком легко приобретают сеттер и становятся глобальной переменной в будущем.

Как вы говорите, эти статические свойства на самом деле не являются частью GeneralParcel класса. Переместите их в статический класс «ListsOfThings».

Затем вы можете использовать код, который ссылается на ListsOfThings.ProvincesList и т.д.