I am reading Test Driven Development: By Example. I am on chapter 13. Chapter 12 and 13 introduced Plus operation to Money object. A Money object can plus by other Money object.
The author added two classes (Bank and Sum) and one interface (IExpression) to the solution. This is the class diagram of the final solution.
Money store amount and currency for example 10 USD, 5 BAHT, 20 CHF. The Plus method returns Sum object.
public class Money : IExpression
{
private const string USD = "USD";
private const string CHF = "CHF";
public int Amount { get; protected set; }
public string Currency { get; private set; }
public Money(int value, string currency)
{
this.Amount = value;
this.Currency = currency;
}
public static Money Dollar(int amount)
{
return new Money(amount, USD);
}
public static Money Franc(int amount)
{
return new Money(amount, CHF);
}
public Money Times(int times)
{
return new Money(this.Amount * times, this.Currency);
}
public IExpression Plus(Money money)
{
return new Sum(this, money);
}
public Money Reduce(string to)
{
return this;
}
public override bool Equals(object obj)
{
var money = obj as Money;
if (money == null)
{
throw new ArgumentNullException("obj");
}
return this.Amount == money.Amount &&
this.Currency == money.Currency;
}
public override string ToString()
{
return string.Format("Amount: {0} {1}", this.Amount, this.Currency);
}
}
Sum store two Money objects which come from constructor arguments. It has one method Reduce that return new Money object (create new object by add amount of two object)
public class Sum : IExpression
{
public Money Augend { get; set; }
public Money Addend { get; set; }
public Sum(Money augend, Money addend)
{
this.Augend = augend;
this.Addend = addend;
}
public Money Reduce(string to)
{
var amount = this.Augend.Amount + this.Addend.Amount;
return new Money(amount, to);
}
}
Bank has one method - Reduce. It just call Reduce method of incoming IExpression argument.
public class Bank
{
public Money Reduce(IExpression source, string to)
{
return source.Reduce(to);
}
}
IExpression is an interface that implemented by Money and Sum.
public interface IExpression
{
Money Reduce(string to);
}
These are my questions.
Bank does nothing good for the solution at this stage. Why do I need it?
Why do I need Sum since I can create and return Money object inside Plus of the class Money (Like what the author did with Times)?
What is the purpose of Bank and Sum? (Right now, it doesn't make any sense for me)
I think Reduce sound strange for me as the method name. Do you think it is a good name? (please suggest)
Keep reading. Kent Beck is a very smart guy. He either has a very good reason why he created the example that way, and it will be clear later on, or it's a poor solution.
"Reduce" is a very good name if map-reduce is the ultimate goal.
Related
Repost model class:
public class TransactionDayReport
{
public Decimal TotalAmount { get; set; }
public ICollection<TransactionResponse> TransactionResponses { get; set; } = null!;
}
This is my repository method
public async Task<IEnumerable<Transaction>> SearchTransactionAsync(SearchTransaction search)
{
var query = _context.Transactions
.Include(t => t.Branch)
.Include(t => t.Customer)
.AsQueryable();
if (search.CIN != null)
query = query.Where(t => t.Customer.CIN.Contains(search.CIN));
if (search.ValueDate != null)
query = query.Where(t => t.ValueDate.Date == search.ValueDate.Date);
return await query.ToListAsync();
}
Service method:
public async Task<TransactionResponse> SearchTransactions(SearchTransaction search)
{
var transactionList = await _unitOfWork.Transactions.SearchTransactionAsync(search);
var mapped = ObjectMapper.Mapper.Map<TransactionDayReport>(transactionList);
return mapped;
}
I need to send total amount in service class..
am looking similar to this
But I am confused how to get addition sum added to my dto. Please can anyone suggest a solution? Thanks
The only way to also calculate the sum on the DB is to run another query on the DB, unless the DB query can be re-written to return both the sum and the data.
If you're ok with calculating the Sum on the client, it's more straightforward. Here are some options I could think of:
You could configure the mapper to set the sum.
You could set the sum after performing the mapping in SearchTransactions().
You could change the DTO to calculate the Sum (in which case it wouldn't be a POCO anymore, but I think this is a reasonable approach too):
public class TransactionDayReport
{
private decimal? _totalAmount = null;
public decimal TotalAmount { get {
if(_totalAmount is not null) return _totalAmount; // new C# 9 feature :)
_totalAmount = // calculate total amount here
return _totalAmount;
}
public ICollection<TransactionResponse> TransactionResponses { get; set; } = null!;
}
Imagine that we have an Aggregate that has a life cycle, such that it can change its behavior during its lifetime. During the first part of its life, it can do some things and during the second part, it can do other things.
I´d like to hear opinions on how should we restrict what the aggregate can do on each phase.
To make it a little more tangible, lets take an financial trade as an aggreagate example.
A trader creates a trade informing the contract, and its price.
A risk manager validates a trade, giving a reason for such.
The BackOffice can submit the trade to the ledger, providing accounting information.
After the trade is submitted, the accounting information can never be changed.
The trade clearly has 3 distinct phases, which I´ll call Typed, Validated and Submitted
My first thought is to pollute the aggregate with InvalidOperationExceptions, which I really don´t like:
public class Trade
{
private enum State { Typed, Validated, Submited }
private State _state = State.Typed;
public Guid Id { get; }
public Contract Contract { get; }
public decimal Price { get; }
public Trade (Guid id, Contract contract, decimal price) { ... }
private string _validationReason = null;
private AccountingInformation _accInfo = null;
public void Validate(string reason) {
if (_state != State.Typed)
throw new InvalidOperationException (..)
...
_validationReason = reason;
_state = State.Validated;
}
public string GetValidationReason() {
if (_state == State.Typed)
throw new InvalidOperationException (..)
return _validationReason;
}
public void SubmitToLedger(AccountingInformation info) {
if ((_state != State.Validated))
throw new InvalidOperationException (..)
...
}
public AccountingInfo GetAccountingInfo() { .. }
}
I can do something like a Maybe pattern, to avoid the exceptions on the Get... methods. But that would not work for the behavior methods (Validate, SubmitToLedger, etc)
Oddly, if I were to be working on a functional language (such as F#), I would probably create a different type for each state.
type TypedTrade = { Id : Guid; Contract: Contract; Price : decimal }
type ValidatedTrade = { Id : Guid;
Contract: Contract;
Price : decimal;
ValidationReason : string}
type SubmittedTrade = { Id : Guid;
Contract: Contract;
Price : decimal;
ValidationReason : string;
AccInfo : AccountingInfo }
// TypedTrade -> string -> ValidatedTrade
let validateTrade typedTrade reason =
...
{ Id = typedTrade.Id; Contract = typedTrade.Contract;
Price = typedTrade.Price; Reason = reason }
// ValidatedTrade -> AccountingInfo -> SubmittedTrade
let submitTrade validatedTrade accInfo =
...
{ Id = validatedTrade.Id;
Contract = validatedTrade.Contract;
Price = validatedTrade.Price;
Reason = validatedTrad.Reason;
AccInfo = accInfo }
And the problem would gracefully go away. But to do that in OO, I would have to make my aggregate immutable and maybe create some kind o hierarchy (in which I would have to hide base methods !? ouch!).
I just wanted an opinion on what you guys do on these situations, and if there is a better way.
I like the idea of having different types for each state. Its a clean design in my opinion. From a logical view a newly created trade is definitly something different than a submitted trade.
public Interface ITrade
{
Guid Id { get; }
Contract Contract { get; }
decimal Price { get; }
}
public class Trade : ITrade
{
public Trade(Guid id, Contract contract, decimal price)
{
Id = id;
Contract = contract;
Price = price;
}
Guid Id { get; }
Contract Contract { get; }
decimal Price { get; }
public ValidatedTrade Validate(string reason)
{
return new ValidatedTrade(this, reason);
}
}
public class ValidatedTrade : ITrade
{
private ITrade trade;
private string validationReason;
public ValidatedTrade(Trade trade, string validationReason)
{
this.trade = trade;
this.validationReason = validationReason;
}
Guid Id { get { return trade.Id; } }
Contract Contract { get { return trade.Contract ; } }
decimal Price { get { return trade.Price ; } }
public string GetValidationReason()
{
return validationReason;
}
public SubmittedTrade SubmitToLedger(AccountingInfo accountingInfo)
{
return new SubmittedTrade(this, accountingInfo);
}
}
public class SubmittedTrade : ITrade
{
private ITrade trade;
private AccountingInfo accountingInfo;
public SubmittedTrade(ValidatedTrade trade, AccountingInfo accountingInfo)
{
this.trade = trade;
this.accountingInfo = accountingInfo;
}
Guid Id { get { return trade.Id; } }
Contract Contract { get { return trade.Contract ; } }
decimal Price { get { return trade.Price ; } }
public AccountingInfo GetAccountingInfo() { .. }
}
You could have one class per state instead of a single class. See this post by Greg Young : http://codebetter.com/gregyoung/2010/03/09/state-pattern-misuse/
The usual problem with the State pattern is the friction with persistence concerns and especially ORMs. It's up to you to decide if the better robustness and type safety is worth the trouble.
Objective: Use the model to show total sales of an id and total sales difference for multiple periods.
Issue: Using MVC4 I have a model for a report that displays total sales. I know I can add a variable for each additional period, but I have many periods that I'd like to use to compare and show a difference. How can this be done avoiding needless repetition?
public class Report
{
public long ID { get; set }
public long TotalSales { get; set}
public long TotalSales2 { get; set}
public long TotalSalesDiff { get; set}
}
Thank you in advance for any suggestions and/or comments
If I understood your scenario you have two option either create a dictionary that can create properties or use Dynamic object class
For dictionary
public class DictionaryProperty
{
Dictionary<string, object> Yourproperties = new Dictionary<string, object>( );
public object this[ string name ]
{
get
{
if ( Yourproperties.ContainsKey( name ) )
{
return Yourproperties[ name ];
}
return null;
}
set
{
Yourproperties[ name ] = value;
}
}
}
}
And for the Dynamic object please refer following link
http://msdn.microsoft.com/en-us/library/system.dynamic.dynamicobject.aspx
cheers
I don’t have enough points to add a comments that’s the why I make this is an answer.
I wonder how to add state to the chain of decorators that will be available to the consumer. Given this simplified model:
abstract class AbstractPizza
{
public abstract print(...);
}
class Pizza : AbstractPizza
{
public int Size { get; set; }
public print(...);
}
abstract class AbstractPizzaDecorator
{
public Pizza:AbstractPizza;
public abstract print();
}
class HotPizzaDecorator : AbstractPizzaDecorator
{
public int Hotness { get; set; }
public print(...);
}
class CheesyPizzaDecorator : AbstractPizzaDecorator
{
public string Cheese { get; set; }
public print(...);
}
void Main()
{
BigPizza = new Pizza();
BigPizza.Size = 36;
HotBigPizza = new HotPizzaDecorator();
HotBigPizza.Pizza = BigPizza;
HotBigPizza.Hotness = 3;
HotBigCheesyPizza = new CheesyPizzaDecorator();
HotBigCheesyPizza.Pizza = HotBigPizza;
HotBigCheesyPizza.Cheese = "Blue";
HotBigCheesyPizza.print();
HotBigCheesyPizza.size = 28; // ERRRRRR !
}
Now if they all implement the print method and propagate that though the chain, it's all good. But how does that work for the state? I can't access the size property on the HotBigCheesyPizza.
What's the part that I'm missing? Wrong pattern?
Thanks for helping!
Cheers
The decorator pattern is for adding additional behavior to the decorated class without the client needing to adjust. Thus it is not intended for adding a new interface (e.g. hotness, cheese) to the thing being decorated.
A somewhat bad example of what it might be used for is where you want to change how size is calculated: you could create a MetricSizePizzaDecorator that converts the size to/from English/metric units. The client would not know the pizza has been decorated - it just calls getSize() and does whatever it needs to do with the result (for example, to calculate the price).
I would probably not use the decorator in my example, but the point is: it does not alter the interface. In fact, nearly all design patterns come down to that - adding variability to a design without changing interfaces.
one way of adding state is by using a self referential data structure (a list). but this uses the visitor pattern and does more than you probably want. this code is rewritten from A little Java, a few patterns
// a self referential data structure with different types of nodes
abstract class Pie
{
abstract Object accept(PieVisitor ask);
}
class Bottom extends Pie
{
Object accept(PieVisitor ask) { return ask.forBottom(this); }
public String toString() { return "crust"; }
}
class Topping extends Pie
{
Object topping;
Pie rest;
Topping(Object topping,Pie rest) { this.topping=topping; this.rest=rest; }
Object accept(PieVisitor ask) { return ask.forTopping(this); }
public String toString() { return topping+" "+rest.toString(); }
}
//a class to manage the data structure
interface PieManager
{
int addTopping(Object t);
int removeTopping(Object t);
int substituteTopping(Object n,Object o);
int occursTopping(Object o);
}
class APieManager implements PieManager
{
Pie p=new Bottom();
// note: any object that implements a rational version of equal() will work
public int addTopping(Object t)
{
p=new Topping(t,p);
return occursTopping(t);
}
public int removeTopping(Object t)
{
p=(Pie)p.accept(new RemoveVisitor(t));
return occursTopping(t);
}
public int substituteTopping(Object n,Object o)
{
p=(Pie)p.accept(new SubstituteVisitor(n,o));
return occursTopping(n);
}
public int occursTopping(Object o)
{
return ((Integer)p.accept(new OccursVisitor(o))).intValue();
}
public String toString() { return p.toString(); }
}
//these are the visitors
interface PieVisitor
{
Object forBottom(Bottom that);
Object forTopping(Topping that);
}
class OccursVisitor implements PieVisitor
{
Object a;
OccursVisitor(Object a) { this.a=a; }
public Object forBottom(Bottom that) { return new Integer(0); }
public Object forTopping(Topping that)
{
if(that.topping.equals(a))
return new Integer(((Integer)(that.rest.accept(this))).intValue()+1);
else return that.rest.accept(this);
}
}
class SubstituteVisitor implements PieVisitor
{
Object n,o;
SubstituteVisitor(Object n,Object o) { this.n=n; this.o=o; }
public Object forBottom(Bottom that) { return that; }
public Object forTopping(Topping that)
{
if(o.equals(that.topping))
that.topping=n;
that.rest.accept(this);
return that;
}
}
class RemoveVisitor implements PieVisitor
{
Object o;
RemoveVisitor(Object o) { this.o=o; }
public Object forBottom(Bottom that) { return new Bottom(); }
public Object forTopping(Topping that)
{
if(o.equals(that.topping))
return that.rest.accept(this);
else return new Topping(that.topping,(Pie)that.rest.accept(this));
}
}
public class TestVisitor
{
public static void main(String[] args)
{
// make a PieManager
PieManager pieManager=new APieManager();
// add some toppings
pieManager.addTopping(new Float(1.2));
pieManager.addTopping(new String("cheese"));
pieManager.addTopping(new String("onions"));
pieManager.addTopping(new String("cheese"));
pieManager.addTopping(new String("onions"));
pieManager.addTopping(new String("peperoni"));
System.out.println("pieManager="+pieManager);
// substitute anchovies for onions
int n=pieManager.substituteTopping(new String("anchovies"),new String("onions"));
System.out.println(n+" pieManager="+pieManager);
// remove the 1.2's
n=pieManager.removeTopping(new Float(1.2));
System.out.println(n+" pieManager="+pieManager);
// how many anchovies do we have?
System.out.println(pieManager.occursTopping(new String("anchovies"))+" anchovies");
}
}
I believe your component Pizza and your abstract decorator PizzaDecorator are supposed to share the same interface, that way each instance of the decorator is capable of the same operations as the core component Pizza.
I have spent some time writing code for my application assuming that the serialisation bit would be the easiest part of it. Pretty much both sides (client and server) are done and all I need to do is passing a class AccountInfo from the service to the client... The problem is that AccountInfo inherits List and therefore [DataContract] attribute is not valid. I tried using the [CollectionDataContract] attribute but then the class that is received on the other side (client) contains only generic List methods without my custom implemented properties such as GroupTitle...I have worked out a solution for this problem but I don't know how to apply it.
Basically everything works when I make a property instead of inheriting a List but then I can't bind this class to LongListSelector (WP7) because it's not a collection type.
There are three classes I'm on about. AccountInfo that contains multiple instances of: AccountInfoGroup that contains multiple instances of:AccountInfoEntry (this one does not inherit list therefore there are no problems serialising it and all properties are accessible).
Could someone help me using right attributes to serialise and transfer these classes using a WCF method?
Here is the code of 2 of these collection classes:
public class AccountInfo : List<AccountInfoGroup>
{
public AccountInfo()
{
UpdateTime = DateTime.UtcNow;
EntryID = Guid.NewGuid();
}
public bool HasItems
{
get
{
return (Count != 0);
}
private set
{
}
}
public Guid EntryID
{
get;
set;
}
public decimal GetTotalCredit()
{
decimal credit = 0;
foreach (AccountInfoGroup acg in this.Where(item => item.Class == AccountInfoEntry.EntryType.Credit))
{
acg.Where(item => item.ItemClass == AccountInfoEntry.EntryType.Credit).ToList().ForEach(entry =>
{ credit += entry.Remaining; }
);
}
return credit;
}
public bool UsedForCreditComparison = false;
public DateTime UpdateTime { get; private set; }
}
public class AccountInfoGroup : List<AccountInfoEntry>
{
public AccountInfoEntry.EntryType Class
{
get;
private set;
}
public string Title
{
get
{
return AccountInfoEntry.ClassToString(Class);
}
}
public AccountInfoGroup(AccountInfoEntry.EntryType groupClass)
{
this.#Class = groupClass;
}
public bool HasItems
{
get
{
return (Count != 0);
}
private set
{
}
}
}
Thank you for any suggestions... :)
The sample you had is quite painful for WCF in serialization.
What I suggest is you to revised and have a common models for your WCF messages (That means it only contains properties with getter and setter, serialization attributes).
If you have a problem in LongListSelector binding in WP7, you might want to convert the message to the actual type the WP7 object supports to use in binding.