.NET Resource Management - Effective C# - page 109

public decimal CurrentPayAmount
{
get ;
set ;
}
public virtual void Pay( BankAccount b)
{
b.Balance += CurrentPayAmount;
}
}
That breaks much of the existing code that uses your customer struct.
Return by value becomes return by reference. Parameters that were passed
by value are now passed by reference. The behavior of this little snippet
changed drastically:
Employee e1 = Employees.Find(e => e.Position == "CEO" );
BankAccount CEOBankAccount = new BankAccount ();
decimal Bonus = 10000 ;
e1.CurrentPayAmount += Bonus; // Add one time bonus.
e1.Pay(CEOBankAccount);
What was a one-time bump in pay to add a bonus just became a perma-
nent raise. Where a copy by value had been used, a reference is now in
place. The compiler happily makes the changes for you. The CEO is prob-
ably happy, too. The CFO, on the other hand, will report the bug. You just
can't change your mind about value and reference types after the fact: It
changes behavior.
This problem occurred because the Employee type no longer follows the
guidelines for a value type. In addition to storing the data elements that
define an employee, you've added responsibilities—in this example, pay-
ing the employee. Responsibilities are the domain of class types. Classes
can define polymorphic implementations of common responsibilities eas-
ily; structs cannot and should be limited to storing values.
The documentation for .NET recommends that you consider the size of a
type as a determining factor between value types and reference types. In
reality, a much better factor is the use of the type. Types that are simple
structures or data carriers are excellent candidates for value types. It's true
that value types are more efficient in terms of memory management: