Oh yeah, religious territory for some.

In your example, is the 'intent' really that obscured when we change (set) the 'Value' of a 'Value Object'

I am wondering if you're overthinking it a little.

Keep going and we may realize we don't identify why a person's address changes. So we go into the territory of ...

Customer.MovedTo()  

just my opinion too. DDD is good but still needs some balance.

It all depends on where you draw the line at data abstraction. Abstract to a high enough level too soon and you create unflexible classes.

I would prefer to use getters and setters early on in design when the level of abstraction required is unclear and then refactor to common methods when the design becomes stable.

In an ideal world I would abolish all getters and setters, or use a language such as Eiffel if I wanted OO purity.

In the real world this is just too hardcore for some, as most people still think procedurally. As long as the Domain Model doesn't become too 'Anemic', I would allow getters and setters for the sake of getting work done.

Personally, I don't think the issue is whether to not use getters and setters, but that each bit of client code using a getter or setter is creating a coupling point.

Any approach early on in a solution where there isn't much implementation done yet is going to appear flexible.  

Behavioral programming typically reduces the amount of coupling points, and this leaves the design more supple.

John,

If Customer.MovedTo() is appropriate to the ubiquitous language of the domain and closer to the intent, then it's a good name.

Pingback from  Reflective Perspective - Chris Alcock  » The Morning Brew #132

Not using NHibernate, are you?

wow... why stop there. why not make the whole entity immutable. whenever you want to change anything just mark the old one as inactive and create a new replacement. or better yet, just tell the customer they aren't allowed to move.

The point I take from this post is that developers should give more thought to this than automatically using setters - which is probably the norm, especially when you consider how easy this is with automatic properties or via resharper.

Frequently a setter doesn't covey the intent nearly as well as as a method would. As Scott points out, setters and getters also introduce coupling.

Now, do I think we should completely stop using setters? No. But people really need to start thinking about what they are trying to do.

If I was building a billing system (say for a telephone company or something), you bet your ass that I'd use:

customer.MovedTo(newAddress);

rather than

custome.Address = newAddress;

Even if MoveTo did nothing more than set a private field.

@Gabriel:

What does NHibernate have to do with the discussion? I map to private fields all the time.

I noticed you said "Entities should not use set mutators" so Value objects still would use setters. I mean, you have to "set" the city, state, zip, etc. of an Address object right?

A question though about when you need to change the first name of the customer for example.

Is customer.ChangeFirstName("John") more descriptive than customer.FirstName = "John"? How would you handle the simple changes, things that don't involve other Entities or Value objects?

I'm not sure I see the distinction - "ChangeAddress" mutates the object just as the setter does.

All you've done is introduce a different way of saying the same thing - "change an internal value of this already-constructed object".

The subtle difference is that you don't allow the reader to leverage their existing knowledge of the meaning of "="; instead, you choose an arbitrary name for that concept (why not "Update" or "Alter" or even "Mutate"?)

What if the C# compiler team had chosen "change_" instead of "set_" and called them changers? Either the concept behind "=" then becomes palatable, or you pick another redundant term for it (maybe "Set"?)

I am not arguing against convenience methods like ChangeName(first, last, prefix, suffix). They add value. Redefining "=" just increases the mental flotsam/jetsam that the readers of your code must harbor.

To avoid being labeled "religious", I'd like to point out that Occam's razor clearly puts your approach on the losing side of "postulates the fewest entities".

This seems fine within a single application boundary.

Serializing an object requires you have both a setter and getter for each property. Method behavior doesn't serialize unless you control both the caller and callee where they can both reference the same assembly.

Also, I forgot to mention that I understand your position on the semantic difference of an Action<T> versus a setter in a behavioral object - it is perceived as "more explicit".

The "act of setting" is the command, not the structural element representing its invocation. If you can set a value on an object, that is as much impetus as is needed to infer work may be done.

And just to be pedantic, a setter is an Action<T> :-)

Pingback from  Dew Drop - July 9, 2008 | Alvin Ashcraft's Morning Dew

Great stuff, another good discussion on the general topic:

peripateticaxiom.blogspot.com/.../tdd-mocks-and-design.html

@Dave

"c.ChangeAddress(aNewAddressValueObject);"

Temporal aspect is a good argument, for sure, but it can be handled to some extent even if you use setters. Having said that I might well use "c.ChangeAddress(aNewAddressValueObject);" but you'd probably have an associated getter (or getter method) so it's not really changing the design that much (though I get you about intention revealing interfaces).

Actually though I wouldn't necessarily put this sort of member directly on Customer. VERY debatable but often I find its better if (for example) a Customer exposed a custom collection (AddressCollection) with the extra methods on it. Why, well because a key entity like Customer probably has a relationships to a few other VALUE OBJECTS/ENTITIES and if you put all the methods for those other entities on the Customer then it's interface gets a little confused (GetCurrentName, GetCurrentAddres, FindAddressAt(Date),...).

"In working with a team, allowing setters creates a crutch that can create weird orchestrations _outside_ of your model."

Agreed, but then even when we have setters/getters I've found good developers will write good code inside the domain and bad developers...you get the idea :)

"I cannot stress enough: entities are behavioral objects and, for my money, Action<T> where T is some value object fits the notion of command rather elegantly."

Huh :)

It's not an either/or decision on setters.  You could keep the setters on the entities to make test automation scenarios and NHibernate usage easy.  Then apply the Interface Segregation Principle.  Lift an interface off of the entity that ONLY contains the methods that change state in a coarse grained manner like Dave is talking about.  Have the service layer only consume the interfaces sans setters.

Udi Dahan does something like this when he writes services over the top of a domain model.

After reading this (and some comments) I'm sure glad i don't work on your projects.

I think this is going too far, are these measures really saving time/effort/maintenance?

"All entities should be immutable" - have you considered what that would do to performance?  Everytime you required to change any field you would need a new allocation.  Existing references would be invalidated - so all references would need to go through an indirection.  

Why is ChangeXXXX better than XXX = value?  What if one project uses Change and another uses Set and another uses Modify?  

I can see the value of providing a method to wrap up an atomic operation - but then you hit the issue of dealing with large parameter lists.  It's much less readable and there are lots of issues with optional fields, breaking changes over time etc.

@Jeremy & @ Dave

I like that. Nothing says you have to only have a single interface implemented on an object.

Cross-boundary uses properties with both accessors, internal uses an interface with a more ubiquitous language. Heuristic works for me.

Interesting discussion, although, I'm having trouble getting past the fact that you're really comparing:

c.ChangeAddress(aNewAddressValueObject);

and (under the covers)

c.set_Address(aNewAddressValueObject);

This seems like a sugar thing to me.

@Jeremy @Dave

Do either of you have a good example of the approach where you extract an interface at a higher level of abstraction. I get the idea but am having trouble working out how you would go about it in practice.

100% agree with avoiding mutating setters.

I just did some training for my current team, and we got to the point where we were assigning managers to departments in the org chart that we were writing for the class. I immediately created a "Department.AssignManager()" method, and the internals of the method did nothing more than call a private setter on the .Manager property.

You're post here does a much better job of describing why I did that, and I've forwarded the link to my team.

@Dave,

I completely agree with you about changing state with methods like that.  Part of the fallout from the EF controversy last week has been some discussions about what goes into setters.  I've found that putting any nontrivial logic into setters is problematic.  

@Colin,

I don't really think it's a higher abstraction level.  It's just the role that the domain object plays in a particular context.

@Dave

Excellent thanks, I thought it might be that one but I wasn't 100% sure. Have to say I find these sorts of topics very interesting, which probably says nothing good about me.

@Jeremy

Ta for replying.

I've definitely done what you suggest in places, but I'm just thinking if you apply that approach quite widely (so upper layers don't really see the setters) then it might expand the interface of your entities quite rapidly and you'd end up with quite a lot of overlap between getters/setters and related coarse grained methods.

You've been kicked (a good thing) - Trackback from DotNetKicks.com

Say goodbye to serialization and databinding (well, two way at least)!

I Feel c.Address is for the initial setting of the state from the DB.

while

c.ChangeAddress(aNewAddressValueObject)

better supports adding new requirements in the future (Audit trails), and is more descriptive of the action performed.

And I don't think this is in religious territory, I think ChangeAddress is the best approach.

I go a step further and claim getters are just as bad as setters ... Getting rid of them is quite a bit more difficult though :-)

We have talked about this in the past ... will try to put a post with some diagrams of how to do it.

Curious about a term Scott used: "sounds like a sugar thing"

What is a 'sugar thing'?  I've not heard that term used before.

Thanks

@markwriter

Scott is talking about "sugar" in a similar way we use the term "syntax sugar" when talking about language features.

Syntax sugar is a feature added to a language to make it possible to do something that was already possible in a way that is more pleasant / intuitive / concise / elegant / whatever to certain developers' sensibilities.

In this case, I think maybe we're talking about "code standards sugar".  The effect achieved is the same: in Dave's own words, using an explicit method rather than a property setter is more intuitive and transparent of purpose, coming from a Domain-Driven Development (DDD) mindset.

For what it's worth, I agree with Scott.  It's sugar.  That doesn't mean it's pointless....  Just that it probably shouldn't be a blanket rule, or even a "best practice".  But it may make great sense in a Dave's DDD context.  He noted himself, he's talking in particular about the "model" layer, which generally is the portion of your app that most closely models the domain regardless what your driving development philosophy is.

Wow look at all these comments, now I *know * this is religious topic.

Sometimes using a property setter is completely appropriate, like when a class has a sensible default value but you can override it using a simple setter.  I prefer to use methods like in your example when there's a verb involved, some action, not just simple data assignment (although under the covers maybe that's all that is happening).  

If you're doing something other than a simple assignment I tend to lean towards methods.  I think the FCL has guidance for this, at least for getters?

This seems to go hand in hand with some guidance I read regarding immutable objects, prefer readonly fields/properties and objects over mutable ones.  I can't remember where I read this...

Anyway, I'm glad I'm not the only one who worries about intent and naming.

Thanks for the clarification, Chris! For whatever reason, I hadn't come across that term before.

Programming links 07.11.2008

@Dave

I'm right there with ya..this helps keep the LOC in the service layer (controllers, etc) from becoming huge..

And it doesn't add a smell if the aggregate root needs to add additional behavior when "changing addresses".  This is doubly true if the logic may throw an exception.  Catching an exception from a setter just feels icky.

Pingback from  NHibernate &laquo; Beautiful code

I would be a happy person if my guys wrote code like c.ChangeAddress(newAddress) rather than c.Address = newAddress;

For me, it's all about intent revealing code. You may argue it's sugar, but without the sugar we're dealing with raw materials and frankly who codes in assembler or p-code anymore?

We've been debating BDD syntax for months now, and it's all about readability. I agree that when you go down the evil path of logic in setters, you're just setting yourself up for failure later. Hiding code behind a setter because there are curly brackets is no different than writing SQL in your webpage codebehind. You're hiding the intent and while it might come out in a peer review, it's something that could be buried deep in the system.

I'm all for using auto-properties in 3.5 for this sole purpose. Give them a single responsibiity. Set a value and that's it. Don't do any rounding, don't do any null checks or lookups or whatever. Let it do what it was designed for. Leave a method like ChangeAddress() to handle logic which can be tested (and might change) and let setters set and getters get.

For a DDD perspective I would rather see methods on models that mean something rather than properties that I have to interpret what might happen if I set that value to something. Let field access control NH and you're done. Later this won't come back to bite you and say "Aha, I'm a setter but I also do 'other' things, but you didn't know that did you?". When the intent of the domain changes (ChangeAddress becomes more than just changing an address but auto-routing mail to the new address) then update the method and rename it (maybe introducing new properties to handle it).

Pingback from  It&#8217;s my blog and I&#8217;ll OCD if I want to &laquo; I Built His Cage

I’ve been reading quite a bit lately about setters and encapsulation , but for whatever reason, it never

Pingback from  Axe.writesSmellyCode() == true &laquo; I Built His Cage

I have an idea.

Why don't we get rid of the syntactic sugar and use set_Address and get_Address methods? ;-)

I mean set_Address() is far closer semantically to your ChangeAddress method.

This post was mentioned on Twitter by lazycoder: Why entities shouldn't have setters. (by @laribee ) http://bit.ly/CGgSL