|Think about Loose Coupling|
Answer quickly! Does the following set the name or not?
Well, its not clear to me that this behaviour is a bad thing at all. As written its conceptually similar to
You could keep the dual purpose behaviour but make it more sensitive to this type of error quite simply:
Your point about using id() as a setter when it isnt meant to be used that way doesnt do much for me either. If the id() sub isnt meant to set the value then it shouldn't and it should throw an error when its asked to. Which puts the dual-use solution in the same position as set_id() would be. (IE it would be a run time error, one caught by the code, one caught by perl).
Also the two method approach has a problem that the dual use approach doesnt that you havent mentioned at all: in the two method approach you have two code stubs whose responsibility it is to operate on the same data. This means that if you change the field name or the objects construction you have to change two subroutines. With the dual use approach all of the logic to manipulate a given atttribute of an object is encapsulated in one sub. That means that things like validation rules are right next to the fetch logic, which means that when you are reviewing code you can see all of the "rules" that pertain to a given attribute in one place. You don't have to remember to review both. You don't have to independently review the setters validation logic in order to determine what the fetcher will return.
Personally i find the encapsulation offered by the dual-use approach combined with careful construction to be better practice than separate-subs.
Updated: to add the missing defined, as noted by radiantmatrix.