Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>The advice I'd offer would depend to a degree on how you go about generating and using the Parcel polymorphs. What I mean is, we can't see what criteria are used to determine whether something is "Express" or "Special" and whether those criteria have to do with the properties of the parcel itself or some external factor. </p> <p>Having said that, I think your intuition is a good one about separating the price calculation from the Parcel object itself. As kmkemp pointed out, a parcel shouldn't be figuring out how to calculate the price of a parcel depending on what type of parcel it is. A parcel is a data transfer/POCO type object, at least as indicated in your giving it a weight, source, etc.</p> <p>However, I'm not clear on why you're using these interfaces. Don't get me wrong -- interfacing is nice for decoupling and testability, but why is there a parcel interface in addition to an abstract base class with an abstract method. Personally, going on just the information that I have, I'd do this:</p> <pre><code>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&lt;int, List&lt;int&gt;&gt; _States_neighboureness; protected static ReadOnlyCollection&lt;City&gt; _Citieslist; protected static ReadOnlyCollection&lt;Province&gt; _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; } } </code></pre> <p>But, again, I don't know how the parcels are actually being processed. You may need some kind of modification to this concept depending on how you generate and then process the parcels. For instance, if the kind of parcel it is depends on the property values of the parcel, you might want to define a factory method or class that takes a parcel and returns an appropriate instance of the calculator. </p> <p>But, however you modify it, I'd definitely cast my vote for your thought of decoupling the definition of the parcel from the scheme for calculating its price. Data storage and data processing are separate concerns. I'd also not vote in favor of a static class somewhere containing global settings, but that's my own personal taste -- that kind of thing too easily acquires a setter and becomes a global variable down the road.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload