Domain model without setters

[ssozonoff]

Hi All,

After much more reading I only have more questions.. Lets say I have defined a bunch of Entities in my domain model. To help me create a rich domain model I have removed all setters and getters and for the moment I have a protected constructor. Not a problem for hibernate since it can still access the fields.
(Some setters/getters might come back but this helps me think about the methods of entity a little better)

One of my entities is a User class. It has things like firstnam, lastname, address etc...
So now I need to create a new user and to do so I need to pass the required information into the class one way or the other, here are my alternatives:

1. Put some setters back
2. Use a constructor
3. Create a "VO" and pass that as an argument to a method of User
4. Add various methods to the User class which take "groups" of fields as arguments. For example a method for address(address1, address2, city, zip, country) and one for fullname(firstname, lastnam)

Hmmmm are there other options?
3. might be an option but now I creating more work for myself, do I really need to do this.. 1. might be ok as long as it makes sense.

So I have 1 and 4 to think about, anyone have any thoughts so far?

An additional problem is what if I would like to bind my forms directly to domain entities? Is this a no no?
OK So here again I can create these sort of "proxy" value objects that get bound to the form and are used to populate an Entity class, but do I really need to?

I have read lots of discussions in the forums and in some books but there does not seem to be a simple guideline that attacks the problem from start to finnish... sighhhh

I would be most greatful for any comments.

Thanks,
Serge

[karldmoore]

I don't think its bad form to have getters and setter on your domain model. As far as I understand, if that is all you have on your domain model, its not much of a model. Adding behaviour to the model allows reuse. There are lots of threads on the forum about your other points though.

http://www.martinfowler.com/bliki/An...mainModel.html
http://forum.springframework.org/showthread.php?t=29694
http://forum.springframework.org/showthread.php?t=30251
http://forum.springframework.org/showthread.php?t=19429

Hope that helps.

[ssozonoff]

Hi,

Yes, I will keep on reading. It might be about finding a nice balance. Use setters when it makes sense but avoid them if you can... or something like that. I will keep reading.

Thanks,
Serge

[Andreas Senft]

One rule of thumb concerning setters: Use constructor arguments for mandatory parameters and setters for optional ones. That way you can also have some sensible validation mechanism on construction.

Regards,
Andreas

[karldmoore]

One rule of thumb concerning setters: Use constructor arguments for mandatory parameters and setters for optional ones. That way you can also have some sensible validation mechanism on construction.

Regards,
Andreas

Agreed, anything that is immutable should be set in the constructor. Some ORM tools need the getters/setters though unless they can use field access. In this case you would just have to make the method scope as restrictive as possible.

[karldmoore]

There are some interesting articles about the whole getter/setter thing. I just typed getters and setters are evil into google. I understand where the author is coming from and his general point but I'm not convinced. Its such a generalization.

http://www.javaworld.com/javaworld/j...5-toolbox.html
http://www.theserverside.com/news/th...hread_id=21310

[debasishg]

A practical suggestion from ground zero .. Please do not get carried away with so much theory. Think in terms of a pragmatic implementation. Design interfaces keeping business use cases in mind and use the UBIQUITOUS LANGUAGE. Hide implementation as much as you can and things will automatically fall in place.

HTH

[ssozonoff]

Thanks,

This confirms what I have sort of concluded myself...

Serge

[Andreas Senft]

and use the UBIQUITOUS LANGUAGE. Hide implementation

I see you also read "Domain Driven Design" by Eric Evans.
A very good book!

Regards,
Andreas

[karldmoore]

+1 its just one of those books that you should read, regardless of your opinions you'll get something out of it.