Scenario
I have a single base class and 2 (possibly 3) other classes that derive from that base class.
//Base Class
class RateInstrument
{
public string Ric { get; set; }
public string Tenor { get; set; }
public double Rate { get; set; }
public DateTime Date { get; set; }
public double Price { get; set; }
public double Bid { get; set; }
public double Ask { get; set; }
public RateInstrument(string tenor, double rate)
{
Tenor = tenor;
Rate = rate;
}
public RateInstrument(DateTime date, double price)
{
Date= date;
Price = price;
}
}
//Derived Class 1
class Swap : RateInstrument
{
public Swap(string tenor, double rate): base(tenor,rate)
{
}
}
//Derived Class 2
class Future: RateInstrument
{
public Future(DateTime date, double price): base(date,price)
{
}
}
Question
On occasions I may need to have a collection of ALL Rate Instruments, and sometimes just a collection of each individual RateInstrument itself.
Realistically what I wanted was to employ some methods in the Base class to do this however I'm not entirely sure how to go about it. It is important to me to structure the code well to help my learning etc. Any help would be greatly appreciated.
EDIT----------
Sorry I meant to say in the essence of being able to instantiate a collection of objects in shorthand. Particularly if I have to create say 100 at a time.
In C# 3.5 you don't really need to do anything in particular for that. IEnumerable<RateInstrument> will do fine.
If you want only particular subtypes, you can use the OfType extension method:
var swaps = instruments.OfType<Swap>();
Doesn't your existing code do the trick?
List<RateInstrument> instruments = new List<RateInstrument>();
instruments.Add(new Swap("bla", 100));
instruments.Add(new OtherSwap("bla2", 200));
var swapInstruments = from instrument in instruments where instrument Is Swap select instrument;
Related
I am tasked with creating a payment module which consists of different types of payment methods.
There are different kind of objects that can go in each which can slightly change how some formulas are calculated. IE if a certain property is present, no tax is taken out. This is how I am currently going about it.
public abstract class Payment
{
private readonly PersonToPay _personToPay;
public Payment (PersonToPay personToPay)
{
_personToPay = personToPay;
}
public decimal PayFrom {get; set;}
public decimal PayTo {get; set;}
public decimal PayRate {get; set;}
public decimal Gross {get; set;}
public decimal Tax {get; set;}
public void CalculateGross()
{
return PayRate * [days in period]
}
public void CalculateTax()
{
if (_personToPay.IsTypeOfX)
Tax = 0;
else
Tax = PayRate * .1;
}
public virtual int GetDaysToPay()
{
int totalDays = 0;
for (var x in _personToPay.ListOfItems)
{
if (x == someTypeOfValue)
totalDays++;
}
return totalDays;
}
}
I am trying to take all of the functionality in this class and pass it to other classes but since all of the functionality is tied to the 'PersonToThePay' object that is injected, how can I do as such in the derived classes? An example would be the following:
public PaymentMethodA : Payment
{
private readonly PersonToPay _personToPay;
public PaymentMethodA(PersonToPay personToPay)
{
_personToPay = personToPay; // this personToPay would set the parent classes PersonToPay above to this
}
public int PaymentMethodAProperty;
public override int GetDaysToPay()
{
return PaymentMethodAProperty * 2;
//do PaymentMethodA logic here
}
}
I was thinking I could just make the PersonToPay a property but if you can't make a payment without a payee, doesn't it make more sense for it to be injected? I was also looking into the strategy pattern for this but to me the template seems to make more sense. Although the functionality is largely the same now, I am trying to make it as adaptable to change as possible hence the separate classes.
Any insight into what would be best to do here would be greatly appreciated.
I see two questions here: The first is what's a good pattern. It's subjective but I'd use a strategy pattern as well. Something to allow the implementation to be something that doesn't care what the payment is:
IPayment payment = new Payment() { PaymentAmount = 100 };
IPayment nonProfitPayment = new NonProfitPayment() { PaymentAmount = 100 };
Console.WriteLine($"Total for 100 payment: ${payment.TotalPayment()}");
Console.WriteLine($"Total for 100 payment: ${nonProfitPayment.TotalPayment()}");
Which of course gives: $106.00 and $100.
The class definitions being:
public interface IPayment
{
decimal TaxRate { get; set; }
decimal PaymentAmount { get; set; }
decimal TotalPayment();
}
public class Payment : IPayment
{
public Payment()
{
TaxRate = 0.06M;
}
public decimal TaxRate { get; set; }
public decimal PaymentAmount { get; set; }
public decimal TotalPayment()
{
return PaymentAmount + (PaymentAmount * TaxRate);
}
}
public class NonProfitPayment : Payment
{
public NonProfitPayment()
{
TaxRate = 0;
}
}
And then for the second question: A Payee and a Payor.
IMO these should be two additional classes, passed to a PostPayment class / Method. A Quick Pseudo class:
public class PostPayment: IPostPayment
{
public PaymentResponse PostPayment(IPayee payee, IPayor payor, IPayment payment)
{
var totalPayment = payment.TotalPayment();
var payorStatus = payor.Charge(totalPayment);
if (payorStatus == ChargeStatus.InsuffucientFunds)
{
return PaymentResponse.InsuffificientCredit;
}
return payee.Credit(totalAmount).PaymentStatus;
}
}
This ultimately ensures that any weird things for a Type of a thing, is handled by the correct thing. For additional thoughts:
public class ReallyWeirdPayeeCase : IPayee
{
public PaymentStatus Credit(decimal paymentAmount)
{
var approval = new ApprovalRequired()
{
ApprovalRequired = true,
Amount = paymentAmount,
DaysHoldRequired = 30
};
dbContext.CorporateApproval.Add(approvalRequired);
return PaymentStatus.ThirtyDayApprovalQueued;
}
}
Shooting from the hip but, I think it shows one good approach to refactoring the existing code for Single Responsibility and meeting your needs.
My program contains two different classes. I want to combine the values of both, only to show the resulting information in a ListBox. The information is stored in a database, the classes in my code have been created by a LINQ to SQL DataClass.
First class (ReactorParameters)
This class contains information about the reactor at a specific time, like the flame temperature, amount of oil, amount of air...
Class definition:
public class ReactorParameters
{
public TimeSpan Time
{ get; set; }
public double Temperature
{ get; set; }
public double Oil
{ get; set; }
public double Air
{ get; set; }
}
Example data:
Second class (ProductInformation)
The ProductInformation class stores information about which product has been produced by the reactor at what time period.
Class definition:
public class ProductInformation
{
public TimeSpan Time_From
{ get; set; }
public TimeSpan Time_To
{ get; set; }
public Product Product
{ get; set; }
}
Example data:
What do I want the result to look like?
What I want to acheive is to combine the reactor parameters with the product that has been produced at the given time.
This is an easy task. Why are you asking?
Of course, I can make a new class, create an instance for each ReactorParameters and store the relevant Product in it. But since this is just for UI purposes (I don't need the extra class for anything else), I'm not sure if there is a better way to reach the goal. I've heard about CompositeCollection and CollectionView, but I'm not sure if this is helpful for me.
So, is there any other way than a separate class to populate my ListBox?
You have to create view class to bind it.
Try following code (I replaced Product with string for test):
public class ReactorParameters
{
public TimeSpan Time { get; set; }
public double Temperature { get; set; }
public double Oil { get; set; }
public double Air { get; set; }
}
public class ProductInformation
{
public TimeSpan Time_From { get; set; }
public TimeSpan Time_To { get; set; }
public string Product { get; set; }
}
public class ReactorView
{
public ReactorParameters Parameters { get; set; }
public ProductInformation Product { get; set; }
}
/// <summary>
/// entry point
/// </summary>
public void Test()
{
Random rnd = new Random(1000);
// random parameters
List<ReactorParameters> parameters = (from i in Enumerable.Range(0, 24)
select new ReactorParameters
{
Time = TimeSpan.FromHours(i),
Temperature = rnd.NextDouble() * 50.0,
Oil = rnd.NextDouble() * 20.0,
Air = rnd.NextDouble() * 30.0,
}).ToList();
// product information
List<ProductInformation> products = (from i in Enumerable.Range(0, 4)
select new ProductInformation
{
Time_From = TimeSpan.FromHours(i * 6),
Time_To = TimeSpan.FromHours(i * 6 + 6),
Product = "Product " + (char)('A' + i),
}).ToList();
// combine
var result = parameters.SelectMany(param => from product in products
where param.Time >= product.Time_From && param.Time <= product.Time_To
select new ReactorView
{
Parameters = param,
Product = product
});
// alternative query
var resultAlt = from param in parameters
from product in products
where param.Time >= product.Time_From && param.Time <= product.Time_To
select new ReactorView
{
Parameters = param,
Product = product
};
// print result
foreach (var item in result)
{
Console.WriteLine("{0,-5} {1,-8:0.00} {2,-8:0.00} {3,-8:0.00} {4,-10}",
item.Parameters.Time, item.Parameters.Temperature, item.Parameters.Air, item.Parameters.Oil, item.Product.Product);
}
}
In my opinion i should go for an new class containing those classes as a property. This way allows you to extend in the furture in case you need some more properties.
public class ProductReactorModel
{
public ReactorParameters ReactorParameters {get;set;}
public ProductInformation ProductInformation {get;set;}
}
Then create a list of the new created class List<ProductReactorModel>. Bind this list to the ListBox. With this class you can access both classes and properties to display in you're ListBox. Binding on the following way inside the ListBox.
{Binding ReactorParameters.Time}
My application's front end is a DataGrid whose contents are passed to an Excel-generating method.
The catch is that the DataGrid deals with 13 columns: 10 of them are fixed (i.e., passed to Excel) while each of the last 3 is optional.
public class GridModel
{
public string Item { get; set; }
public string ItemName { get; set; }
public double TotalHeight { get; set; }
public double AGLheight { get; set; }
public double Embedment { get; set; }
public string Shape { get; set; }
public double TipDiameter { get; set; }
public double BaseDiameter { get; set; }
public double Taper { get; set; }
public double ShearReaction { get; set; }
// The following are optional, in 8 combinations, from all present to all absent
public double Camber { get; set; }
public double Rake { get; set; }
public double Angle { get; set; }
}
Being a C# newbie, I am considering the different approaches.
How would you folks deal with this? The simplest idea that comes to mind is to add 3 flags to the model:
bool IsColumn1Present;
bool IsColumn2Present;
bool IsColumn3Present;
Another way would be to add a level to the hierarchy, so each of the 'special' columns contains its own embedded flag:
if (Camber.flag) add(Camber.value);
That said, I would like to have the ability to somehow remove those 3 properties, so any attempt to access them would result in an error or impossibility.
If such thing exists, I guess it would be called "Variant Properties".
TIA
Note: I have solved this already by the manipulation of the Visibility.Visible field at the GUI level. Gurus, however, tell us that this is a bad idea. Best practices dictate that this facility should be part of the Model.
You could use nullable properties:
public double? Camber { get; set; }
Then check them for a value in your business logic:
if (thing.Camber.HasValue)
{
DoSomething(thing.Camber.Value);
}
It sounds like this might be exactly what you're after, given your comment on "variant" properties.
More info: http://msdn.microsoft.com/en-us/library/1t3y8s4s.aspx
Update: If you need to switch them off application-wide (as per your comment), you could either avoid setting the value in the first place when it's not wanted (this would be preferable as this is, as far as I'm concerned, business logic and doesn't belong in your dumb model classes) or extend this with a custom accessor:
private double? _camber;
public double? Camber
{
get
{
return ModelSettings.CamberEnabled
? _camber
: null;
}
set;
}
Then have some static/constant property somewhere:
public static class ModelSettings
{
public const bool CamberEnabled = true;
}
If the number of columns is constant (meaning the user can't add 'custom' columns), I would suggest a bit-field enum value like so:
[Flags]
public enum ColumnFlags
{
None = 0,
Camber = 0x1,
Rake = 0x2,
Angle = 0x4,
// Other optional columns here, keep them powers of 2!
}
Then in your Model class, keep a value such as:
public ColumnFlags ColumnFlags { get; set; }
Then you can use...
if(model.ColumnFlags.HasFlag(ColumnFlags.Camber))
{
// Do something here...
}
if(model.ColumnFlags.HasFlag(ColumnFlags.Rake))
{
// Do something here...
}
EDIT: Alternatively, you can use the Nullable<T> types to specify a "missing" or "empty" value.
I'm currently developing an app using ASP.NET MVC3 and Entity Framework 4.1 Code First and also trying to apply DDD little by little since I'm only began learning it.
I have a model of :
public class ClassA
{
public decimal MonthlyRate { get; set; }
public virtual decimal DailyRate
{
get { return this.MonthlyRate / 30; }
private set { }
}
}
Right now, this code works but what if I'll be having a flag (which will be checked by user) on the View triggering for a new computation. Let's say the flag instead of dividing it by 30, monthly rate now will be divided by 5. Any suggestions? Thanks.
interface IDivideLogic
{
int DivideNumber{get;set;}
}
class DivideLogic : IDivideLogic
{
public DivideLogic()
{
DivideNumber = 30;
}
public DivideLogic(int divideNumber)
{
DivideNumber = divideNumber;
}
public int DivideNumber{get;set;}
}
public class ClassA
{
public IDivideLogic DivideLogic {get;set;}
public decimal MonthlyRate { get; set; }
public virtual decimal DailyRate
{
get { return this.MonthlyRate / DivideLogic.DivideNumber; }
private set { }
}
}
then you can switch this when you want
ClassA obj = new ClassA();
obj.DivideLogic = new DivideLogic(5);
This works well for more complicated situations. In your situation it may be too over designed. Hope you get the point
You could use a strategy pattern for this. You could use various implementations of your division logic. Assuming you want to anticipate further change this would be a good way to solve this problem. This way you abstract the division logic from the other logic making it easy to implement different implementations of the division logic.
You can declare the value as a property and assign it from UI.
public class ClassA
{
public decimal MonthlyRate { get; set; }
public int YourProperty {get; set;}
public ClassA(int yourProperty)
{
YourProperty = yourProperty;
}
public virtual decimal DailyRate
{
get { return this.MonthlyRate / YourProperty; }
private set { }
}
}
I have an application that I'm trying to build with at least a nominally DDD-type domain model, and am struggling with a certain piece.
My entity has some business logic that uses some financial calculations and rate calculations that I currently have inside some domain services, as well as some constant values I'm putting in a value object.
I'm struggling with how to have the entity use the logic inside the domain services, or whether the logic inside those services even belongs there. This is what I have so far:
public class Ticket
{
public Ticket(int id, ConstantRates constantRates, FinancialCalculationService f, RateCalculationService r)
{
Id = id;
ConstantRates = constantRates;
FinancialCalculator = f;
RateCalculator = r;
}
private FinancialCalculationService FinancialCalculator { get; set; }
private RateCalculationService RateCalculator { get; set; }
private ConstantRates ConstantRates { get; set; }
public int Id { get; private set; }
public double ProjectedCosts { get; set; }
public double ProjectedBenefits { get; set; }
public double CalculateFinancialGain()
{
var discountRate = RateCalculator.CalculateDiscountRate(ConstantRates.Rate1, ConstantRates.Rate2,
ConstantRates.Rate3);
return FinancialCalculator.CalculateNetPresentValue(discountRate,
new[] {ProjectedCosts*-1, ProjectedBenefits});
}
}
public class ConstantRates
{
public double Rate1 { get; set; }
public double Rate2 { get; set; }
public double Rate3 { get; set; }
}
public class RateCalculationService
{
public double CalculateDiscountRate(double rate1, double rate2, double rate3 )
{
//do some jibba jabba
return 8.0;
}
}
public class FinancialCalculationService
{
public double CalculateNetPresentValue(double rate, params double[] values)
{
return Microsoft.VisualBasic.Financial.NPV(rate, ref values);
}
}
I feel like some of that calculation logic does belong in those domain services, but don't really like that I'll have to manually inject those dependencies from my Repository. Is there an alternate way that this should be modeled? Am I wrong in not liking that?
Having read the Blue Book but not really built anything in this style before, I'm looking for guidance.
EDIT
Thanks all for the feedback! Based on what I'm hearing, it sounds like my model should look more like the following. This look better?
public class Ticket
{
public Ticket(int id)
{
Id = id;
}
private ConstantRates ConstantRates { get; set; }
public int Id { get; private set; }
public double ProjectedCosts { get; set; }
public double ProjectedBenefits { get; set; }
public double FinancialGain { get; set; }
}
public class ConstantRates
{
public double Rate1 { get; set; }
public double Rate2 { get; set; }
public double Rate3 { get; set; }
}
public class FinancialGainCalculationService
{
public FinancialGainCalculationService(RateCalculationService rateCalculator,
FinancialCalculationService financialCalculator,
ConstantRateFactory rateFactory)
{
RateCalculator = rateCalculator;
FinancialCalculator = financialCalculator;
RateFactory = rateFactory;
}
private RateCalculationService RateCalculator { get; set; }
private FinancialCalculationService FinancialCalculator { get; set; }
private ConstantRateFactory RateFactory { get; set; }
public void CalculateFinancialGainFor(Ticket ticket)
{
var constantRates = RateFactory.Create();
var discountRate = RateCalculator.CalculateDiscountRate(constantRates.Rate1, constantRates.Rate2,
constantRates.Rate3);
ticket.FinancialGain = FinancialCalculator.CalculateNetPresentValue(discountRate,
new[] {ticket.ProjectedCosts*-1, ticket.ProjectedBenefits});
}
}
public class ConstantRateFactory
{
public ConstantRates Create()
{
return new ConstantRates();
}
}
public class RateCalculationService
{
public double CalculateDiscountRate(double rate1, double rate2, double rate3 )
{
//do some jibba jabba
return 8.0;
}
}
public class FinancialCalculationService
{
public double CalculateNetPresentValue(double rate, params double[] values)
{
return Microsoft.VisualBasic.Financial.NPV(rate, ref values);
}
}
The domain model ends up being fairly anemic at this point, but as I add features maybe it'll have more to it.
EDIT 2
Okay, I got some more feedback that perhaps my 'calculation' services are more like strategy objects that it's okay for my Entity to depend on. Here's another take at it with more of the logic back in the Entity, and making use of those strategy objects. Thoughts on this? Any issues with instantiating those helpers directly in the Entity? I don't think I'll want to mock those out in my tests, but OTOH I can't test the CalculateFinancialGain method without testing those strategy objects, either.
public class Ticket
{
public Ticket(int id, ConstantRates constantRates)
{
Id = id;
ConstantRates = constantRates;
}
private ConstantRates ConstantRates { get; set; }
public int Id { get; private set; }
public double ProjectedCosts { get; set; }
public double ProjectedBenefits { get; set; }
public double CalculateFinancialGain()
{
var rateCalculator = new RateCalculator();
var financeCalculator = new FinanceCalculator();
var discountRate = rateCalculator.CalculateDiscountRate(ConstantRates.Rate1, ConstantRates.Rate2,
ConstantRates.Rate3);
return financeCalculator.CalculateNetPresentValue(discountRate,
ProjectedCosts*-1,
ProjectedBenefits);
}
}
public class ConstantRates
{
public double Rate1 { get; set; }
public double Rate2 { get; set; }
public double Rate3 { get; set; }
}
public class RateCalculator
{
public double CalculateDiscountRate(double rate1, double rate2, double rate3 )
{
//do some jibba jabba
return 8.0;
}
}
public class FinanceCalculator
{
public double CalculateNetPresentValue(double rate, params double[] values)
{
return Microsoft.VisualBasic.Financial.NPV(rate, ref values);
}
}
Have your service accept the Ticket entity as a parameter. Services should be stateless and the same service should be able to provide its services to any number of entities.
In your situation I would pull the FinancialCalculatorService and RateCalculatorService out of your entity and make the methods on each service accept the Ticket entity as a parameter.
Take a second and read pg. 105 of Domain-Driven Design by Eric Evans
Given what we've seen of the classes, I don't think they're really services in the blue book sense, and I would keep the calculators in Ticket.
Neither FinancialCalculatorService or RateCalculationService has dependencies on domain entities - they both operate on primitive values. Applications shouldn't have to worry about how to calculate the financial gain that would result from a ticket, so it's valuable to encapsulate that information inside the ticket itself.
If they really don't have dependencies on domain entities, consider thinking of them as 'standalone classes' rather than 'services' (once again, in blue book terminology). It's certainly appropriate for Ticket depend on strategy objects (FinancialCalculator and RateCalculator) that do not themselves have exotic dependencies and do not themselves modify the state of domain entities.
Update for Edit 2. I think one of the advantages of making the calculators separate classes is that you can test them independently of Ticket. Strictly speaking, tickets aren't responsible for performing those calculations, they're responsible for making the right calls to those collaborating classes. So I'd be inclined to make them inject-able / mock-able as they were in your initial example.
i would say services use entities, not the other way around.
another thing, not sure on your domain, but are you certain ticket is an entity and not a value object?
You've actually struck on a question that there has been quite a bit of discussion on. There are believers on both sides of the tracks so you need to decide for yourself what makes the most sense.
Personally I don't have my entities use services as it creates a whole lot of work around the "How do I cleanly get services into my entities?" question.
It looks to me like CalculateFinancialGains() is more of a service level call. This does lead to Ticket being very anemic but I assume it has other behavior? And if it doesn't that's probably a smell...
This question is actually an example of a discussion that is in the book "Clean Code" (pp 96-97). The underlying question is whether or not to use a procedural approach or a object oriented approach. Hope I'm not in violation repeating a couple parts here, but here is what Bob Martin states for guidance:
Procedural code (code using data structures) makes it easy to add new functions without changing the existing data structures. OO code, on the other hand, makes it easy to add new classes without changing existing functions.
The compliment is also true:
Procedural code makes it hard to add new data structures because all the functions must change. OO code makes it hard to add new functions because all the classes must change.
My understanding that a DDD "Value type" would be what Bob Martin calls a data structure.
Hope this helps and doesn't just add to the noise :)