Considering I have a service to calculate a customer account balance with the interface
public interface ICustomerAccountCalculation
{
Decimal Balance(int customerId);
}
is it better style to rather than pass in the customer id to pass the customer object like this
public interface ICustomerAccountCalculation
{
Decimal Balance(Customer customer);
}
More natural thing to do would be to pass the entity but this usually causes performance problems, so in most practical scenarios you would pass just the key.
Pass only the values that are going to be used in the function. If the customerid is enough for you to carry out further computation then pass only that much - if any other field is required pass it as a different parameter to the function.
It is a good practice to abstract the function from the object. A function should only be concerned with input VS output. For example if your function is float computeBalance(float, float) then it should be able to take any two float values and carry out the computation. Passing the object means you have read the object and extract the desired fields ... not a good thing to do :)
I think it is really a question you need to answer because it depends. What is the cost vs benefit of passing the entity vs just passing the id? In the case of your service contract it looks like an id would be sufficient information (I know I am making an assumption) to get the account balance for a customer. Some other things to consider are the cost to serialize/deserialize your entity, etc...
But in another case it may make sense depending on the operation you are performing. Lets say the operation needs more information from the caller about the customer, it doesn't make sense to go to the database to get that information within the operation if you already have it loaded from within the caller...
So, it depends.
If the purpose of the function is to calculate the account balance of the customer, I am going to assume that the customer is already created and contains an account balance. I am also going to assume that customerId is unique for each customer, so the account balance can be calculated (retrieved) by just using the customerId. Having said all this, if all you need is the customerId to create the balance, then just passing the id in is fine, but if you need other properties on the customer object, then passing in the whole customer may be a better idea or you may pass in multiple parameters instead.
As an example, if you were to create the balance solely based on the customerId, you might do something like this in your Balance() method (this looks more like a retrieval than a calculation though):
decimal balance = from c in Customers
where c.CustomerId == customerId
select c.Balance;
As shown above in the linq query, if all you need is customerId, then go ahead and just pass that in, but if you need other properties, pass in the whole customer or pass in more parameters. Looking at it further, you mentioned that this is for calculating the balance, so that would tell me that you might need more than just the customerId, so maybe passing more parameters or the whole object would be better in that case.
Lets break down the responsibilities for both implementations.
As you can see the first version does more than perform calculation. As such, it's a violation of Single Responsibility Principle. The second version should be your first attempt, and only change to the version taking ID if there is an explicit need for it. Even still, if for some reason you need to do calculation by ID, you can always retrieve it from the Customer instance.