Re: When not to use interfaces?

If you agree with the idea of unit tests as specifications of behavior
(and I do!), then I would say having an interface (or abstract class)
for even a DTO is important.

A DTO object is an object with member variables and getters and setters
for reading and writing the member variables.

This is a very language-implementation view that is not true in general
(and is quite often untrue in, say, Python or C#). A DTO wraps
multiple discrete values as a single discrete object. Whether it uses
member variables, getters/setters, properties, or any other method of
accomplishing that task is an implementation detail and not a
consequence of the DTO concept.

My point is that a DTO contains very little behavior. The DTO is mainly
a datastructure and the implementation is very simple. Regardsless what
language that is used, there are no point in creating a mock
implementation of a DTO. The purpose with a mock is to have a simpler
implementation fullfilling the same contract/interface. If the
implementation is already as simple as possible, the mock would not be
very different from the real implementation.

Fredrik Bertilsson
http://frebe.php0h.com

.

Relevant Pages

  • Re: When not to use interfaces?
    ... A DTO object is an object with member variables and getters and setters ... database like hsqldb for your unit tests. ...
    (comp.object)
  • Re: When not to use interfaces?
    ... A DTO object is an object with member variables and getters and setters ... multiple discrete values as a single discrete object. ...
    (comp.object)
  • Re: When not to use interfaces?
    ... then I would say having an interface (or abstract class) ... A DTO object is an object with member variables and getters and setters ...
    (comp.object)