Loading ...
Sorry, an error occurred while loading the content.

Re: [madshoppers] static v. dynamic

Expand Messages
  • J. David Beutel
    ... That s a good alternative that I hadn t considered! Mixing constructor for required and setter for optional parameters would let me avoid having multiple
    Message 1 of 3 , Nov 1, 2005
    View Source
    • 0 Attachment
      NICK HOLT wrote:

      > My rule of thumb is a parameter in the constructor for anything that
      > can't be defaulted, what you're calling 'static' initialization.


      That's a good alternative that I hadn't considered! Mixing constructor
      for required and setter for optional parameters would let me avoid
      having multiple constructors. I always approached it from the opposite
      direction, starting with a constructor with all the parameters and then
      refactoring calls to it with duplicate parameters into another
      constructor that defaults those parameters (calling the original
      constructor).

      > The reason for this is that it make's it impossible to create an
      > object in an invalid state because the constructor enforces what must
      > be set. With the setter method there's no way of knowing this without
      > looking at the docs and that introduces room for error.
      >
      > The more nasty side effect of what you're calling 'dynamic'
      > initialization is that incorrect initialization of an object surfaces
      > as a bug at another point in the code, ie: when attempting to use the
      > uninitialized property and this is where the debugging time gets lost,
      > tracing back to the invalid initialization.
      >
      > My feeling is that 'dynamic' initialization is normally a constraint
      > placed on a class by the persistence mechanisms, in that they require
      > a default (empty) constructor so that they can instantiate an object.
      > This doesn't have to be the way, but it's certainly the case in the
      > frameworks I've used such as Hibernate (at which point Phillippe will
      > probably prove me wrong :-).
      >


      I don't like that constraint. That's one advantage that I thought JDO
      had over Hibernate. The persistence layer should be orthogonal, like
      serialization in Java. Some define transparency to mean that the class
      doesn't need to implement any interface explicitly. But even implicit
      interfaces, like JavaBeans, are a burden (e.g., not allowing setters to
      validate based on other properties). However, I've heard that now
      Hibernate can persist fields without getters and setters (using bytecode
      enhancement like JDO), although it still requires a no-arg constructor,
      which I don't mind since it can be private. So, I guess it's time I
      took Hibernate for a spin.

      I would say the same thing about dependency injection frameworks, except
      that they can automatically mimic the way that a class would be
      initialized manually, so I don't mind if they're not orthogonal.

      Cheers,
      11011011
    • Seth Ladd
      ... Actually, it uses pure reflection to set fields, no bytecode enhancement needed. Hiberate can and will use bytecode enhancement, but only for things like
      Message 2 of 3 , Nov 1, 2005
      View Source
      • 0 Attachment
        > validate based on other properties). However, I've heard that now
        > Hibernate can persist fields without getters and setters (using bytecode
        > enhancement like JDO),

        Actually, it uses pure reflection to set fields, no bytecode enhancement needed.

        Hiberate can and will use bytecode enhancement, but only for things
        like lazy loading one-to-one relationships, or lazy loading particular
        fields (an unusual use case at best).

        > although it still requires a no-arg constructor,
        > which I don't mind since it can be private. So, I guess it's time I
        > took Hibernate for a spin.

        If you /really/ have having a no-arg constructor, then it's possible
        to work with hibernate still. You'll need to create a Hibernate
        Interceptor and be responsible for creating new instances yourself.

        Of course, you can have Spring be responsible for creating new
        instances of your objects that Hibernate will populate. Then you get
        the best of both worlds: Hibernate for persistence and Spring for
        object creation and DI.

        With Spring's support for Factory Beans, you definitely don't need a
        no-arg constructor anywhere.

        Seth
      • J. David Beutel
        ... Oops, I read about the bytecode enhancement in regards to lazy loading, but then I over-generalized. ... Thanks, I didn t know that. It sounds good to
        Message 3 of 3 , Nov 1, 2005
        View Source
        • 0 Attachment
          Seth Ladd wrote:

          >>validate based on other properties). However, I've heard that now
          >>Hibernate can persist fields without getters and setters (using bytecode
          >>enhancement like JDO),
          >>
          >>
          >
          >Actually, it uses pure reflection to set fields, no bytecode enhancement needed.
          >
          >Hiberate can and will use bytecode enhancement, but only for things
          >like lazy loading one-to-one relationships, or lazy loading particular
          >fields (an unusual use case at best).
          >
          >
          >

          Oops, I read about the bytecode enhancement in regards to lazy loading,
          but then I over-generalized.

          >>although it still requires a no-arg constructor,
          >>which I don't mind since it can be private. So, I guess it's time I
          >>took Hibernate for a spin.
          >>
          >>
          >
          >If you /really/ have having a no-arg constructor, then it's possible
          >to work with hibernate still. You'll need to create a Hibernate
          >Interceptor and be responsible for creating new instances yourself.
          >
          >Of course, you can have Spring be responsible for creating new
          >instances of your objects that Hibernate will populate. Then you get
          >the best of both worlds: Hibernate for persistence and Spring for
          >object creation and DI.
          >
          >With Spring's support for Factory Beans, you definitely don't need a
          >no-arg constructor anywhere.
          >
          >

          Thanks, I didn't know that. It sounds good to keep in mind. But
          ironically I might prefer a no-arg constructor for the persistence
          layer, if it's private, for the orthogonality. Then the public
          constructor could have different validation logic for initialization
          than the setters have for changing, and the persistence layer can bypass
          all of it.

          Cheers,
          11011011
        Your message has been successfully submitted and would be delivered to recipients shortly.