A while ago Peter said something about DTOs violating data hiding or encapsulation and I decided that if you think of the DTO as a primitive data type they don’t. Following this line of thinking (which I have not been able to try out in practice, just as thought experiments) you’d have
public class SomeDTO extends DTO { public String foo; public String bar; } public interface SomeInterface { SomeDTO data(); //I’m not sure this is needed String calculateFooBar(); } public class SomeImpl { final SomeDTO data; public SomeImpl(SomeDTO data) {this.data = data;} public SomeDTO data() {return data;} public String calculateFooBar() {return data.foo + “:” + data.bar;} } I’m curious how this would work out in an actual situation, especially in knowing fi the “data()” accessor is needed. I’d hope it would only be needed for serialization purposes. thanks david jencks > On Oct 14, 2016, at 9:52 PM, David Leangen <apa...@leangen.net> wrote: > > > Hi! > > I only noticed now that according to the RFC, DTOs cannot contain methods. I > can understand why this is so, and I do not object. > > However, I have found a very practical design pattern whereby I use classes > that act both as DTOs and domain value objects. In effect, this means that > they are DTOs with methods. I am willing to pay the price of having “bloated” > DTOs for this convenience. > > > Would there be any way to allow configuration to permit this? > > If that is out of the question then any suggestions as to what I could do so > as to not have to have “duplicate” classes (DTOs and domain VOs)? > > > Example: > > Domain object API > > public interface SomeObject { > String foo(); > String bar(); > String calculateFoobar(); > } > > Implementation > > public class SomeObjectDTO extends DTO implements SomeObject { > public String foo; > public String bar; > > public SomeObjectDTO() {} > > public SomeObjectDTO( String aFoo, String aBar ) { > foo = aFoo; bar = aBar; > } > > @Override public String foo() { return foo; } > @Override public String bar() { return bar; } > @Override public String calculateFoobar() { return foo + “:” + bar; } > } > > > I like the above because: > * No duplication > * As a DTO, can be sent over the wire and serialised > * Implements the domain API > > > Cheers, > =David > >