> Notice I say DTO because I actually think there's a subtle but not > insignificant difference between an object exposing behavior and a > data structure encapsulating state - again even if Java puts both into > the same camp. On the one hand, you can easily add new methods all > over without every touching the DTO itself. On the other hand, through > polymorphism you can easily introduce new objects without ever > changing existing methods. > > Double dispatch is handy but it requires the gift of foresight (back > to design again) and effectively breaks encapsulation Not so fast. double dispatch does *not* break encapsulation. For example, serialization shows us that encapsulation is preserved. There are a number of software metrics such as package stability shows us that encapsulation is preserved. The package stability of your application is 1 in regards to a refactoring of Serialization. Also, the stability of serialization is 1 in regards to the refactoring of your application. This perfect score can only happen is encapsulation is respected. Stability is is completely dependent upon the Serializable interface.
One other small nit, I don't like parallel marshalling schemes such as DTO. DTO is a hack to get around limitations of earlier EJB implementations. When I now run into them I see they've almost become a code smell or design anti-pattern. Regards, Kirk --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
