When not to use interfaces?
in [OOP]
|
From: frebe73 on 4 Nov 2006 02:16 > 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. No other behavior resides in a DTO. It is not possible to do very different implementations of a DTO. > /* doh! can't substitute stubs or mocks for the DTOs because they're > concrete! we have > * to run this against the DB now, and it'll be slow! > */ A DTO does not access the DB. A DTO is used for transfering data between different layers. > it takes 10 minutes for your suite of unit tests to run because you > have to fix the state of the database between each test run, than the > example isn't very convincing. It test performance is important, use an embedded all-in-memory database like hsqldb for your unit tests. Trying to mock the database is very time consuming. A lot of database logic has to be emulated if you want realistic tests. Fredrik Bertilsson http://frebe.php0h.com
From: sjdevnull@yahoo.com on 4 Nov 2006 04:28 frebe73(a)gmail.com wrote: > > 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.
From: frebe73 on 4 Nov 2006 06:18 > > > 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
From: Matt McGill on 4 Nov 2006 12:48 frebe73(a)gmail.com wrote: > > 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. No other behavior resides > in a DTO. It is not possible to do very different implementations of a > DTO. > > > /* doh! can't substitute stubs or mocks for the DTOs because they're > > concrete! we have > > * to run this against the DB now, and it'll be slow! > > */ > > A DTO does not access the DB. A DTO is used for transfering data > between different layers. Eesh, you're right. I mixed up my acronyms. I was thinking D/A/O. Thank you for the sanity check.
First
|
Prev
|
Pages: 1 2 3 Prev: MSI WindowsInstaller.Installer List of products Next: Definition of Abstract Data Type |