I have a task where I need to implement a basic shopping cart system. In this shopping cart, there will be different type of campaigns which is applicable to category of products. These campaigns is going to apply different kind of discounts. To achieve this, I decided to implement the factory pattern.
Lets start with the base class for all discount types;
public abstract class Discount
{
public Category Category { get; set; }
public int MinimumItems { get; set; }
public Discount(Category category, int minItems)
{
Category = category;
MinimumItems = minItems;
}
}
The campaign interface;
public interface ICampaign
{
void ApplyDiscount(ShoppingCart card);
}
The Campaign type which is applied based on a money amount(e.g. 100 USD discount over the price);
public class AmountDiscount : Discount, ICampaign
{
public decimal DiscountAmount { get; set; }
public AmountDiscountGenerator(Category category, int minItems, decimal discountAmount) : base(category, minItems)
{
DiscountAmount = discountAmount;
}
public void ApplyDiscount(ShoppingCart card)
{
card.TotalPrice() -= DiscountAmount;
}
The Campaign type which is applied based on the rate (e.g. %20 discount over the price);
public class RateDiscountGenerator : Discount, ICampaignGenerator
{
public double DiscountRate { get; set; }
public RateDiscountGenerator(Category category, int minItems, double discountRate) : base(category, minItems)
{
DiscountRate = discountRate;
}
public void ApplyDiscount(ShoppingCart card)
{
card.TotalPrice() -= card.TotalPrice() * DiscountRate / 100;
}
As you can see, the different campaign classes differs on the ApplyDiscount() method's algorithm. But also, it differs about one of them has the data member named DiscountAmount and the other has DiscountRate.
Here is the factory class which I implemented;
public static class CampaignFactory
{
public static ICampaign GenerateCampaign(Category category, int minItems, int amountOrRate, DiscountType discountType)
{
if(discountType == DiscountType.Amount)
{
return new AmountDiscountGenerator(category, minItems, amountOrRate);
}
else if(discountType == DiscountType.Rate)
{
return new RateDiscountGenerator(category, minItems, amountOrRate);
}
}
}
The problem with my factory class is the parameter named amountOrRate. To initialize the properties DiscountAmount or DiscountRate, I need to have a common parameter in my factory class, but since this properties are semantically different, it looks wrong to me to accept a common parameter in my factory method and both campaign class constructors is going to share it(you can understand my confusion from the naming of the parameter amountOrRate).
Can you help me to implement the pattern on this particular example? You can also advice me if I need to implement different design patterns with factory pattern(e.g. strategy pattern). Any help is appreciated, thanks.
It may be overkill, but one approach would be to have an IInitializer interface, derived with initialization data for each discount type:
public interface IInitializer
{
}
public class AmountInitializer : IInitializer
{
public decimal Amount {get; set;}
}
public class RateInitializer : IInitializer
{
public double Rate{get; set;}
}
public static ICampaign GenerateCampaign(Category category, int minItems, IInitializer init)
{
if(init is AmountInitializer )
return new AmountDiscountGenerator(category, minItems, (AmountInitializer)init);
else if(init is RateInitializer)
return new RateDiscountGenerator(category, minItems, (RateInitializer)init);
}
I've not shown everything, but you should be able to fill in the gaps. Also, the actual factory could be done more neatly than an if/else chain.
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.
First of all let's say I have two separated aggregates Basket and Order in an e-commerece website.
Basket aggregate has two entities Basket(which is the aggregate root) and BaskItem defined as following(I have removed factories and other aggregate methods for simplicity):
public class Basket : BaseEntity, IAggregateRoot
{
public int Id { get; set; }
public string BuyerId { get; private set; }
private readonly List<BasketItem> items = new List<BasketItem>();
public IReadOnlyCollection<BasketItem> Items
{
get
{
return items.AsReadOnly();
}
}
}
public class BasketItem : BaseEntity
{
public int Id { get; set; }
public decimal UnitPrice { get; private set; }
public int Quantity { get; private set; }
public string CatalogItemId { get; private set; }
}
The second aggregate which is Order has Order as aggregate root and OrderItem as entity and Address and CatalogueItemOrdered as value objects defined as following:
public class Order : BaseEntity, IAggregateRoot
{
public int Id { get; set; }
public string BuyerId { get; private set; }
public readonly List<OrderItem> orderItems = new List<OrderItem>();
public IReadOnlyCollection<OrderItem> OrderItems
{
get
{
return orderItems.AsReadOnly();
}
}
public DateTimeOffset OrderDate { get; private set; } = DateTimeOffset.Now;
public Address DeliverToAddress { get; private set; }
public string Notes { get; private set; }
}
public class OrderItem : BaseEntity
{
public int Id { get; set; }
public CatalogItemOrdered ItemOrdered { get; private set; }
public decimal Price { get; private set; }
public int Quantity { get; private set; }
}
public class CatalogItemOrdered
{
public int CatalogItemId { get; private set; }
public string CatalogItemName { get; private set; }
public string PictureUri { get; private set; }
}
public class Address
{
public string Street { get; private set; }
public string City { get; private set; }
public string State { get; private set; }
public string Country { get; private set; }
public string ZipCode { get; private set; }
}
Now If the user wants to checkout after adding several items to basket there are several actions should be applied:
Updating Basket(maybe some items' quantity has been changed)
Adding/Setting new Order
Deleting the basket(or flag as deleted in DB)
Paying via CreditCard using specific Payment gateway.
As I can see there are several transactions should be executed because depending on DDD in every transaction only one aggregate should be changed.
So could you please guide me to how can I implement that(maybe by using Eventual consistency) in a way I don't break DDD principles?
PS:
I appreciate any references or resources
The most important thing that your model is missing is behavior. Your classes are holding only data, sometimes with public setters when they shouldn't (like Basket.Id). Domain entities must define methods to operate on their data.
What you got right is that you have the aggregate root enclosing its children (e.g. Basket with a private list of Items). An aggregate is supposed to be treated like an atom, so everytime you load or persist a basket to the database, you'll be treating the Basket and Items as a single whole. This will even make things as lot easier for you.
This is a model of mine for a very similar domain:
public class Cart : AggregateRoot
{
private const int maxQuantityPerProduct = 10;
private const decimal minCartAmountForCheckout = 50m;
private readonly List<CartItem> items = new List<CartItem>();
public Cart(EntityId customerId) : base(customerId)
{
CustomerId = customerId;
IsClosed = false;
}
public EntityId CustomerId { get; }
public bool IsClosed { get; private set; }
public IReadOnlyList<CartItem> Items => items;
public decimal TotalAmount => items.Sum(item => item.TotalAmount);
public Result CanAdd(Product product, Quantity quantity)
{
var newQuantity = quantity;
var existing = items.SingleOrDefault(item => item.Product == product);
if (existing != null)
newQuantity += existing.Quantity;
if (newQuantity > maxQuantityPerProduct)
return Result.Fail("Cannot add more than 10 units of each product.");
return Result.Ok();
}
public void Add(Product product, Quantity quantity)
{
CanAdd(product, quantity)
.OnFailure(error => throw new Exception(error));
for (int i = 0; i < items.Count; i++)
{
if (items[i].Product == product)
{
items[i] = items[i].Add(quantity);
return;
}
}
items.Add(new CartItem(product, quantity));
}
public void Remove(Product product)
{
var existing = items.SingleOrDefault(item => item.Product == product);
if (existing != null)
items.Remove(existing);
}
public void Remove(Product product, Quantity quantity)
{
var existing = items.SingleOrDefault(item => item.Product == product);
for (int i = 0; i < items.Count; i++)
{
if (items[i].Product == product)
{
items[i] = items[i].Remove(quantity);
return;
}
}
if (existing != null)
existing = existing.Remove(quantity);
}
public Result CanCloseForCheckout()
{
if (IsClosed)
return Result.Fail("The cart is already closed.");
if (TotalAmount < minCartAmountForCheckout)
return Result.Fail("The total amount should be at least 50 dollars in order to proceed to checkout.");
return Result.Ok();
}
public void CloseForCheckout()
{
CanCloseForCheckout()
.OnFailure(error => throw new Exception(error));
IsClosed = true;
AddDomainEvent(new CartClosedForCheckout(this));
}
public override string ToString()
{
return $"{CustomerId}, Items {items.Count}, Total {TotalAmount}";
}
}
And the class for the Items:
public class CartItem : ValueObject<CartItem>
{
internal CartItem(Product product, Quantity quantity)
{
Product = product;
Quantity = quantity;
}
public Product Product { get; }
public Quantity Quantity { get; }
public decimal TotalAmount => Product.UnitPrice * Quantity;
public CartItem Add(Quantity quantity)
{
return new CartItem(Product, Quantity + quantity);
}
public CartItem Remove(Quantity quantity)
{
return new CartItem(Product, Quantity - quantity);
}
public override string ToString()
{
return $"{Product}, Quantity {Quantity}";
}
protected override bool EqualsCore(CartItem other)
{
return Product == other.Product && Quantity == other.Quantity;
}
protected override int GetHashCodeCore()
{
return Product.GetHashCode() ^ Quantity.GetHashCode();
}
}
Some important things to note:
Cart and CartItem are one thing. They are loaded from the database as a single unit, then persisted back as such, in one transaction;
Data and Operations (behavior) are close together. This is actually not a DDD rule or guideline, but an Object Oriented programming principle. This is what OO is all about;
Every operation someone can do with the model is expressed as a method in the aggregate root, and the aggreate root takes care of it all when it comes to dealing with its internal objects. It controls everything, every operation must go through the root;
For every operation that can potentially go wrong, there's a validation method. For example, you have the CanAdd and the Add methods. Consumers of this class should first call CanAdd and propagate possible errors up to the user. If Add is called without prior validation, than Add will check with CanAdd and throw an exception if any invariant were to be violated, and throwing an exception is the right thing to do here because getting to Add without first checking with CanAdd represents a bug in the software, an error by committed the programmers;
Cart is an entity, it has an Id, but CartItem is a ValueObject an has no Id. A customer could repeat a purchase with the same items and it would still be a different Cart, but a CartItem with the same properties (quantity, price, itemname) is always the same - it is the combination of its properties that make up its identity.
So, consider the rules of my domain:
The user can't add more than 10 units of each product to the cart;
The user can only proceed to checkout if they have at least 50 USD of products in the cart.
These are enforced by the aggregate root and there's no way of misusing the classes in any way that would allow breaking the invariants.
You can see the full model here: Shopping Cart Model
Back to your question
Updating Basket (maybe some items' quantity has been changed)
Have a method in the Basket class that will be responsible for operating changes to the basket items (adding, removing, changing quantity).
Adding/Setting new Order
It seems like an Order would reside in another Bounded Context. In that case, you would have a method like Basket.ProceedToCheckout that would mark itself as closed and would propagate a DomainEvent, which would in turn be picked up in the Order Bounded Context and an Order would be added/created.
But if you decide that the Order in your domain is part of the same BC as the Basket, you can have a DomainService that will deal with two aggregates at once: it would call Basket.ProceedToCheckout and, if no error is thrown, it would the create an Order aggregate from it. Note that this is an operation that spans two aggregates, and so it has been moved from the aggregate to the DomainService.
Note that a database transaction is not needed here in order the ensure the correctness of the state of the domain.
You can call Basket.ProceedToCheckout, which would change its internal state by setting a Closed property to true. Then the creation of the Order could go wrong and you would not need to rollback the Basket.
You could fix the error in the software, the customer could attempt to checkout once more and your logic would simply check whether the Basket is already closed and has a corresponding Order. If not, it would carry out only the necessary steps, skipping those already completed. This is what we call Idempotency.
Deleting the basket(or flag as deleted in DB)
You should really think more about that. Talk to the domain experts, because we don't delete anything the real world, and you probably shouldn't delete a basket in your domain. Because this is information that most likely has value to the business, like knowing which baskets were abandoned and then the marketing dept. could promote an action with discounts to bring back these customers so that they can buy.
I recommend you read this article: Don't Delete - Just Don't, by Udi Dahan. He dives deep in the subject.
Paying via CreditCard using specific Payment gateway
Payment Gateway is infrastructure, your Domain should not know anything about it (even interfaces should be declared in another layer). In terms of software architecture, more specifically in the Onion Architecture, I recommend you define these classes:
namespace Domain
{
public class PayOrderCommand : ICommand
{
public Guid OrderId { get; }
public PaymentInformation PaymentInformation { get; }
public PayOrderCommand(Guid orderId, PaymentInformation paymentInformation)
{
OrderId = orderId;
PaymentInformation = paymentInformation;
}
}
}
namespace Application
{
public class PayOrderCommandHandler : ICommandHandler<PayOrderCommand>
{
private readonly IPaymentGateway paymentGateway;
private readonly IOrderRepository orderRepository;
public PayOrderCommandHandler(IPaymentGateway paymentGateway, IOrderRepository orderRepository)
{
this.paymentGateway = paymentGateway;
this.orderRepository = orderRepository;
}
public Result Handle(PayOrderCommand command)
{
var order = orderRepository.Find(command.OrderId);
var items = GetPaymentItems(order);
var result = paymentGateway.Pay(command.PaymentInformation, items);
if (result.IsFailure)
return result;
order.MarkAsPaid();
orderRepository.Save(order);
return Result.Ok();
}
private List<PaymentItems> GetPaymentItems(Order order)
{
// TODO: convert order items to payment items.
}
}
public interface IPaymentGateway
{
Result Pay(PaymentInformation paymentInformation, IEnumerable<PaymentItems> paymentItems);
}
}
I hope this has given you some insight.
I am struggling with understanding C# interfaces. I understand that they allow for multiple inheritance. I'm trying to code for a scenario: Employees can view their own data, but not others. Managers can view and edit Employee information, if the Employee reports to that Manager.
So I start with an abstract class, since everyone is a User and takes vacation the same.
public abstract class User {
string _id;
string _firstName;
string _lastName;
double _salaryAmount;
double _bonusAmount;
int _vacationBalance;
public void TakeVacation(int hours) {
_vacationBalance -= hours;
}
//do I implement this here?
/*
public int SalaryAmount{ }
*/
}
Should I use an interface to define IEditable and IViewable?
Could I do something like this?
public interface IEditable {
double SalaryAmount { get; set; }
}
public class Employee : User, IEditable {
public double SalaryAmount {
get {
return base._salaryAmount;
}
set {
base._salaryAmount = value;
}
}
}
//Will I need a ReadOnlyEmployee or something?
I'm just not sure how to block a Manager from editing a User, or how to write an interface for this type of situation.
I'm not sure I'd say that Interfaces allow multiple inheritance (not in the true C++ form). An interface provides an abstraction which allows multiple implementations to behave consistently via a predefined set of methods/properties.
Often this is used as a general abstraction, for example say you want to get some data. You can create an Interface that surfaces a method that returns a Stream. Then based on the implementation of the object you can return the stream from a file or websocket or pipe, etc. without the consumer of the interface knowing/caring where it's coming from.
In your example you don't have to do anything in the User class, because it doesn't implement the IEditable interface, only the Employee class does.
Here's what I think you are looking for. This uses Explicit interface syntax (IEditable.Name) because the base method name and the interface name are the same but need to act differently.
public abstract class User {
public String Id { get; protected set; }
public String FirstName { get; protected set; }
public String LastName { get; protected set; }
// ...
public Double SalaryAmount { get; protected set; }
// ...
public Int32 VacationBalance { get; protected set; }
public void TakeVacation(int hours) {
VacationBalance -= hours;
}
}
public interface IEditable {
Double SalaryAmount { get; set; }
}
public class Employee: User, IEditable {
#region IEditable Members
double IEditable.SalaryAmount {
get { return base.SalaryAmount; }
set { base.SalaryAmount = value; }
}
#endregion
}
class Program {
static void Main(string[] args) {
var emp = new Employee();
emp.SalaryAmount = 3; // ERROR!
((IEditable) emp).SalaryAmount = 3; // GOOD!
}
}
When you read this you'll be awfully tempted to give advice like "this is a bad idea for the following reason..."
Bear with me. I know there are other ways to approach this. This question should be considered trivia.
Lets say you have a class "Transaction" that has properties common to all transactions such as Invoice, Purchase Order, and Sales Receipt.
Let's take the simple example of Transaction "Amount", which is the most important monetary amount for a given transaction.
public class Transaction
{
public double Amount { get; set; }
public TxnTypeEnum TransactionType { get; set; }
}
This Amount may have a more specific name in a derived type... at least in the real world. For example, the following values are all actually the same thing:
Transaction - Amount
Invoice - Subtotal
PurchaseOrder - Total
Sales Receipt - Amount
So now I want a derived class "Invoice" that has a Subtotal rather than the generically-named Amount. Ideally both of the following would be true:
In an instance of Transaction, the Amount property would be visible.
In an instance of Invoice, the Amount property would be hidden, but the Subtotal property would refer to it internally.
Invoice looks like this:
public class Invoice : Transaction
{
new private double? Amount
{
get
{
return base.Amount;
}
set
{
base.Amount = value;
}
}
// This property should hide the generic property "Amount" on Transaction
public double? SubTotal
{
get
{
return Amount;
}
set
{
Amount = value;
}
}
public double RemainingBalance { get; set; }
}
But of course Transaction.Amount is still visible on any instance of Invoice.
Thanks for taking a look!
Thanks for all the help.
OK, of course you cannot "hide" public properties on the base class when the derived class IS a base instance. Somewhere deep in my brain I already knew that. Doh!
I wound up getting the syntactic sugar to behave the way I wanted for the consumer by using a third class called TransactionBase. This class is abstract and contains the shared, non-aliased stuff that exists for all transactions like currency, exchange rate, created/modified date and time, transaction date, etc... in addition to aliased stuff like Amount.
Here, I just show the Amount property in question:
public abstract class TransactionBase
{
protected virtual double Amount { get; set; }
}
Then Transaction looks like this:
public class Transaction : TransactionBase
{
public new double Amount
{
get
{
return base.Amount;
}
set
{
base.Amount = value;
}
}
}
And Invoice:
public class Invoice : TransactionBase
{
public double SubTotal
{
get
{
return Amount;
}
set
{
Amount = value;
}
}
}
And access works the way I wanted:
var transaction = new Transaction();
// This line works fine:
var transactionAmount = transaction.Amount;
var invoice = new Invoice();
// This line works fine:
var invoiceSubtotal = invoice.SubTotal;
// This line won't compile.
// Error: TransactionBase.Amount is inaccessible due to its protection level.
var invoiceAmount = invoice.Amount;
So the answer to my original question was, "no" you cannot hide public inherited members. The above solution fakes it with accessing the protected member directly in the derived types, but it still sort of sucks. Too much typing.
Of course, now that I fiddled and piddled with all that, I'm seeing that a better solution throws out the protected members altogether and saves me some typing. By the way, YES I am embarrassed that I didn't jump immediately to this solution.
EDIT: Actually, the first appraoch in my answer might be better. With the 2nd one, I'd lose the "Amount" or "Subtotal" when casting from a Transaction to an Invoice.
public abstract class TransactionBase
{
// There are some shared properties here.
}
public class Transaction : TransactionBase
{
public double Amount { get; set; }
}
public class Invoice : TransactionBase
{
public double SubTotal { get; set; }
}
In short, you can't do this.
In long, you can emulate this by coding to interfaces!
public class Transaction
{
public double Amount { get; set; }
}
public interface IInvoice
{
public double? SubTotal { get; set; }
}
public class Invoice : Transaction, IInvoice
{
public double? SubTotal
{
get
{
return Amount;
}
set
{
Amount = value ?? 0.0f;
}
}
}
I would recommend using composition over inheritance in this instance. The main reason is that the base implementation of Transaction seems to possibly never be used in the way intended through inheritance. You can hide the transaction as a protected or private member of the Invoice and expose / manipulate it using the public properties of Invoice.
One such example could look like:
public class Invoice
{
private readonly Transaction _transaction;
public Invoice():this(new Transaction())
{
}
public Invoice(Transaction transaction)
{
_transaction = transaction;
}
// This property should hide the generic property "Amount" on Transaction
public double? SubTotal
{
get
{
return _transaction.Amount;
}
set
{
_transaction.Amount = value ?? 0.0f;
}
}
public double RemainingBalance { get; set; }
}
The exact behavior you're looking for doesn't make sense syntactically. If Invoice inherits Transaction, then it is a kind of transaction, and the compiler requires it to inherit all of its properties.
The general behavior you're looking for is, I think, encapsulation, which can be accomplished with interfaces.
public interface IInvoice
{
double? Amount { get; set; }
}
public interface ITransaction
{
double? SubTotal { get; set; }
}
Require the consumers of your code to use these interfaces, and then the implementation details are hidden to them.
So now, the classes can behave the way you want. SubTotal will still be visible to the class (Invoice), but will be hidden to the interface (IInvoice).
public class Transaction : ITransaction
{
public double? SubTotal { get; set; }
}
public class Invoice : IInvoice
{
public double? Amount
{
get { return base.SubTotal; }
set { base.SubTotal = value; }
}
}
How about using an implicit conversion operator?
class Program
{
static void Main(string[] args)
{
var transaction = new Transaction();
var transactionAmount = transaction.Amount;
var invoice = new Invoice();
var invoiceSubTotal = invoice.SubTotal;
Transaction fromInvoiceToTrans = invoice;
var fromInvoiceToTransAmount = fromInvoiceToTrans.Amount;
}
}
public class Transaction
{
public decimal Amount {get; set;}
}
public class Invoice
{
public decimal SubTotal
{
get;
set;
}
public static implicit operator Transaction(Invoice invoice)
{
return new Transaction
{
Amount = invoice.SubTotal
};
}
}
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;