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
> 
> 

Reply via email to