Why are you modifying the salary? General raise or promotion? How do you tell your mutator which reason and apply the business rules as needed?

With completely seperate methods for each, the reason will be blindingly obvious. You don't even need a conditional to figure it out in the object's code.

But as I already said in the thread with dragonchild, he's missed a few reasons for changing the salary and he's missed a couple of methods of calculating the new salary. So basically what you'll end up with is a combinatorial explosion of salary adjusting methods. n methods where n = (# reasons) * (# ways of calculating new salary).

So lets refactor slightly and have a business level interface (where changes to salary require a reason). You may have several specific methods and probably one that says "just set it to this much and here's a piece of text for the audit log about why I did it". All of these will need to call the actuall Salary method on a lower level object and also put something in the log. It should not be the responsibilty of the Employee object to handle logging.

Moving away from Salary and business rules, it's quite possible that you just want to change a field's value without supplying any other information. As someone else pointed out, the object may then need to signal observers to update the gui or whatever but the thing requesting the change just wants to treat it like a struct.

A demotion is a negative promotion. A salary cutback is a negative raise. Or, rather, you could choose to deal with it that way. There are others.

What I laid out was not meant to be the final word on salary adjustments. The point was this: Any time you use a mutator, it can be rewritten as a series of methods based on business rules instead of fiddilng with internals.

More importantly, and this is something everyone in this and related threads is missnig - Every single technique mentioned is valid. TMTOWTDI, for crying out loud. Maybe type-based validation is appropriate here and maybe it needs value-based validation there. Maybe a mixture of both plus other techniques is valid in this other place.

Maybe mutators are better used in area A and maybe business-rule-based methods are better in area B. My argument is that mutators can be wholly replaced with business-rule-based methods. I'm not saying that you should do that in every case - that would be cargo-cult stupidity.

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.