Announcement Announcement Module
Collapse
No announcement yet.
Domain model without setters Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Domain model without setters

    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

  • #2
    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.

    Comment


    • #3
      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

      Comment


      • #4
        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

        Comment


        • #5
          Originally posted by Andreas Senft View Post
          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.

          Comment


          • #6
            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

            Comment


            • #7
              I remember reading the articles before. In my opinion it is here like everywhere: don't go to the extremes.
              A model providing only getters and setters without additional functionality might not be the best choice. A model generally lacking getters and setters might be problematic as well. It is important to achieve a healthy balance.

              Just my 2 cents,
              Andreas

              Comment


              • #8
                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

                Comment


                • #9
                  Originally posted by Andreas Senft View Post
                  I remember reading the articles before. In my opinion it is here like everywhere: don't go to the extremes.
                  A model providing only getters and setters without additional functionality might not be the best choice. A model generally lacking getters and setters might be problematic as well. It is important to achieve a healthy balance.

                  Just my 2 cents,
                  Andreas
                  +1 from me

                  Comment


                  • #10
                    Thanks,

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

                    Serge

                    Comment


                    • #11
                      Originally posted by debasishg View Post
                      and use the UBIQUITOUS LANGUAGE. Hide implementation
                      I see you also read "Domain Driven Design" by Eric Evans.
                      A very good book!

                      Regards,
                      Andreas

                      Comment


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

                        Comment

                        Working...
                        X