That example is full of state. There's nothing to prevent you from calling any of those setX methods at a later point in time and changing the object's state. T

That example is full of state. There's nothing to prevent you from calling any of those setX methods at a later point in time and changing the object's state. That interface very well could avoid state, but Swiftmailer doesn't seem to be implemented in that way. [1] The stateless way would be to return an entirely new Swift_Message instance with each setX method. In languages that aren't built with immutability in mind, like PHP and Java, you end up instantiating and throwing away a lot of objects. Sometimes it doesn't matter, but when it does you use a mutable Builder to create the immutable instances. [1] http://swiftmailer.org/docs/messages.html http://swiftmailer.org/docs/messages.html