Re: Agents commission - seperate commission class or not?

"Dion" wrote
> the commission by Agent.GetCommission(DatePeriod) or
> Comission.GetCommission(Agent, DatePeriod).

First, there's the question of responsibility: is it the agent's job to
calculate a commission, or the commission's job to know how it needs to be
calculated? I'm suspicious of either answer, but the second (an object doing
something to itself) looks preferable as a first impression.

Then,
  Any agents who are not on commission?
  Any commissions that aren't paid to agents?
  Is it possible or probable that you'd ever write an app that would need
one class but not the other?
These are meant to question whether the two classes are really inherently
connected and can legitimately know about each other. I could easily see an
application that would manage agent sales call schedules and not have to
know about commissions at all, so the method Agent.GetCommission looks out
of place--it would force us to drag code into applications that shouldn't be
dependent on that code at all.

Finally, if we think in detail about calculating a commission, what exactly
to we need to know about the agent to calculate properly? Seniority, rate
schedule, bonus schedule? What else? Are these actually properties of the
agent at all? Or do they belong somewhere else and the agent just knows how
to get them? To really modularize things, we should only pass what we really
need, so that suggests a call more like
Commission.GetCommission(calcParams : TCommissionCalcParameters);
and a call structure like

// this assumes that the relative source information exists
// in the agent

parms := TCommissionCalcParameters.Create(agent);
try
  parms.DateSpan := datespan;
  commission := TCommission.GetCommission(parms);
finally
  parms.Free;
end;

Now a commission doesn't have to know about agents, and agents don't have to
know about commissions.

bobD

"Joanna Carter [TeamB]" wrote
> the only real difference I would suggest is that the calculator is
> totally responsible for gathering all the information

And I like to distinguish sharply between (1) what info do I require and (2)
where does it come from; so I end up with a class that knows all the
required info (the calculation parameter class) and perhaps where to get it,
and another class that actually uses that info. That allows for switching
information soruces much easier.

bobD

On Thu, 14 Feb 2008 21:35:08 +0200, Dion wrote:

> Commission caculation for agents is fairly complex. What reasoning(if 
> aforementioned is not reaon enough) do I use in deciding if I should access

> the commission by Agent.GetCommission(DatePeriod) or 
> Comission.GetCommission(Agent, DatePeriod).

I would think that the calculation should be done by an entity like
the Payroll system.

-- 
Marc Rohloff [TeamB]

Dion a écrit :

> Commission caculation for agents is fairly complex. What reasoning(if 
> aforementioned is not reaon enough) do I use in deciding if I should access

> the commission by Agent.GetCommission(DatePeriod) or 
> Comission.GetCommission(Agent, DatePeriod).

Like Bob, I feel that the responsibility for calculating lies neither 
with the Agent nor the Commission.

One of the most common mistakes made in OO design is to only think of 
the "noun" classes and forget the "verb" classes (sometimes
called actors).

In this case, I would suggest a CommissionCalculator similar to Bob's; 
the only real difference I would suggest is that the calculator is 
totally responsible for gathering all the information from wherever it 
needs to perform the calculation, including querying the Agent and 
possibly the SalesLedger, etc, in order to create a Commission instance 
that represents the result of the calculation.

Joanna

-- 
Joanna Carter [TeamB]

Hi,

Commission caculation for agents is fairly complex. What reasoning(if 
aforementioned is not reaon enough) do I use in deciding if I should access 
the commission by Agent.GetCommission(DatePeriod) or 
Comission.GetCommission(Agent, DatePeriod).

Thanks,
Dion.