Prev: MSI WindowsInstaller.Installer List of products
Next: Definition of Abstract Data Type
From: moop? on 3 Nov 2006 04:15
Hi all,
Programming to interfaces rather than objects do benefit a lot, but it
is not always a good idea to have everything implements from
interfaces, sometime we just need classes without obeying any
interfaces, such as entity (DTO, whatever), some other things. I wonder
in what siutations, we would like to use pure object without using
interfaces.

From: frebe73 on 3 Nov 2006 04:29
> Hi all,
> Programming to interfaces rather than objects do benefit a lot, but it
> is not always a good idea to have everything implements from
> interfaces, sometime we just need classes without obeying any
> interfaces, such as entity (DTO, whatever), some other things. I wonder
> in what siutations, we would like to use pure object without using
> interfaces.

Interfaces should be used if you have multiple implementations
(classes), or think that you might have multiple implementations in the
future. DTO are data centric by nature with minimal behavoir, which
makes the probability for multiple implementations very low.

Fredrik Bertilsson

From: raxitsheth2000 on 3 Nov 2006 06:06
when you are sure that there will no more change,

search archive of this group (i m replying from google-group) for
discussion/example

--raxit

From: raxitsheth2000 on 3 Nov 2006 06:09
i was in hurry,

ignore my following answer.

--raxit

raxitsheth2...(a)yahoo.co.in wrote:
> when you are sure that there will no more change,
>
> search archive of this group (i m replying from google-group) for
> discussion/example
>
> --raxit

From: Matt McGill on 3 Nov 2006 08:38
moop? wrote:
> Hi all,
> Programming to interfaces rather than objects do benefit a lot, but it
> is not always a good idea to have everything implements from
> interfaces, sometime we just need classes without obeying any
> interfaces, such as entity (DTO, whatever), some other things. I wonder
> in what siutations, we would like to use pure object without using
> 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. Let's say we're writing code for some
course registration program, and we need a Registrar object that can
add a Student to a CourseSection, assuming we know the student's id and
the Course Reference Number (CRN) of the course section the student is
registering for. Those values are, say, coming off a paper form and
being entered by someone in the registrar's office. If we have concrete
classes for our DTOs:

public class CourseSectionDTO {...}
public class StudentDTO{...}

....

public void testRegistrarShouldAddStudentToCourseSection() {
/* 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!
*/
registrar.add('<student id>', '<CRN>');
/* doh! we can only verify correct behavior by retrieving the
CourseSection from the DB
* checking it's internal state!
*/
}

Then how will we easily write unit test specifications of the behavior
of the Registrar object which don't depend on the database? If, on the
other hand, our DTOs have interfaces, we could, for example, use a mock
object framework to write a test which accomplishes the same thing but
does not have a database dependency. This example uses EasyMock:

public interface CourseSectionDTO {...}
public interface StudentDTO {...}

....
protected void setUp() {
student = createMock(Student.class);
courseSection = createMock(CourseSection.class);
studentDto = createMock(StudentDTO.class);
courseSectionDto = createMock(CourseSectionDTO.class);
}

public void testRegistrarShouldAddStudentToCourseSection() {
expect(studentDto.loadStudent('<id>')).andReturn(student);

expect(courseSectionDto.loadSection('<crn>')).andReturn(courseSection);
expect(courseSection.add(student));
replay(studentDto, courseSectionDto, student, courseSection);

registrar.add('<id>', '<crn>');
verify(studentDto, courseSectionDto, student, courseSection);
}

This concept applies to any object which has clients, not just DTOs. Of
course, if you're not big on unit testing, or if you consider unit
testing to be more an 'after-the-fact' thing, or if you don't care that
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.

 |  Next  |  Last
Pages: 1 2 3
Prev: MSI WindowsInstaller.Installer List of products
Next: Definition of Abstract Data Type