Are you really using JUnit during your development?

[Rutherford, Michael]

Interesting that you (or they at least) consider avoiding patterns to be
programming to the LCD.
 
I've found that so long as you avoid getting pattern happy the benefits to
even novice programmers include less time spent having to recognise what
many classes or methods do in relatation to "nearby" classes. eg the
judicious use of factory methods to encapsulate logic for object creation.
This leads to faster maintenance and better understanding of the overall
system as there is actually less to learn at any one time.
 
Having said that Pattern Abuse *is* rife eg the prevalent use of the
Abstract Factory pattern outside of generic APIs, this pattern is major
overkill for most application programming in my experience.
 
In my opinion it is similiar to the prevalent architectural design (which
*seems* to be lessening) of specifying the use of EJBs for everything. I've
had major knock-down drag-out fights over that one :-) EJBs have their uses
but the default choice should be to not use them.
 
Michael Rutherfurd
 
 

-----Original Message-----
From: junit@... [mailto:junit@...] On Behalf Of
Michael Feathers
Sent: Tuesday, 29 August 2006 10:31 PM
To: junit@...
Subject: [POLICY P1] Re: [junit] Test-friendly, but not caller-friendly?



Elliotte Harold wrote:

>J. B. Rainsberger wrote:
>
>
>
>>I find it difficult not to interpret this as a (very mild) personal
>>attack. You seem to imply that we are not also practitioners. I suspect
>>you're not an asshole, so I imagine you mean something else. I would
>>appreciate you clarifying this position. Is it necessarily the case,
>>then, that "the sort of programmers who... hang out on lists like this
>>one" don't know what we're talking about, because I kinda think I do and
>>I kinda think I've proven that.
>>
>>
>
>You do know what you're talking about, and you are practitioners, as am
>I. However you're making the classic mistake of assuming that everyone
>else is just like you, and that what works for you works for them. This
>is a *HUGE* and unrecognized fallacy that underlies a lot more than
>programming methodologies. For instance, it's largely responsible for
>the failure of modern elementary and secondary education, which works
>for maybe 5% of children. However that's those 5% that go onto become
>teachers and principles and propagate the same techniques to future
>generations, while ignoring the failure of 95% of their students.
>
>The simple fact is that people learn and think differently. No one
>technique works for everyone, but some techniques do work for more
>people. We tend to self-select into groups that think similarly and
>learn similarly to ourselves. The people who like interfaces are a
>self-selected group of programmers who think at a very high degree of
>abstraction, even for programmers (already a self-selected and abstract
>bunch). This doesn't mean they don't produce quality software. It does
>mean that you can't expect what works for them to work for all or even
>most developers.
>
>

I think you're mixing pedagogical techniques with working techniques.
Average programmers can think in terms of interfaces.. it's a matter of
acclimation. Note, I'm talking about average programmers. There are,
unfortunately, some people who really shouldn't be programming at all.

I know that there are cases where you know that the people who come
after you in a project are going to be of uncertain caliber. I was
talking to a friend a month ago who was part of a small team that
deliberately didn't use patterns. They programmed for the least common
denominator because that was all that they could count on for
maintenance. They made a calculated bet. The thing is, though, that
I've seen enough teams raise their level of practice to bet on that when
I know that they have the opportunity.

Michael Feathers
www.objectmentor.com



 



**************   IMPORTANT MESSAGE  **************
This e-mail message is intended only for the addressee(s) and contains information which may be confidential.
If you are not the intended recipient please advise the sender by return email, do not use or disclose the contents, and delete the message and any attachments from your system. Unless specifically indicated, this email does not constitute formal advice or commitment by the sender or the Commonwealth Bank of Australia (ABN 48 123 123 124) or its subsidiaries.
We can be contacted through our web site: commbank.com.au.
If you no longer wish to receive commercial electronic messages from us, please reply to this e-mail by typing Unsubscribe in the subject line.
***************************************************************



[Non-text portions of this message have been removed]



 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/junit/

<*> To unsubscribe from this group, send an email to:
    junit-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 

[hari_mourya]

<whole bunch of text deleted by moderator >


hi....

can u tell me how to make suits in junit.
thanks
harry







 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/junit/

<*> To unsubscribe from this group, send an email to:
    junit-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 

[Michael Feathers]

Elliotte Harold wrote:

>Michael Feathers wrote:
>
>  
>
>>Nope.  We wrapped it.  Yes, we had system tests, but in order to test
>>our logic independently, we pretty much had to wrap it.
>>    
>>
>
>I don't want the tests to be independent of the libraries they depend
>on. I want them to depend on exactly what the code depends on: no more;
>no less. That way you find bugs in the boundaries between model classes
>and libraries as well as in the model classes and libraries themselves.
>  
>

That's fine as a personal preference.  The question is, whether as an
API developer, you should make that choice for other people.

>  
>
>>>Now if the library had a legitimate need to create documents in memory
>>>for reasons other than testing, then I would add such functions. However
>>>I wouldn't do it just for testing.
>>>
>>>
>>>      
>>>
>>The fact is, testing is a legitmate need.  Designing for testability is
>>simply good engineering.
>>
>>    
>>
>
>The tail is wagging the dog. Testing is done to support the project. It
>is not the project, and it should not control the project.
>

Okay.  Nobody has said that testing should control the project.  If
you're designing an API, testability of client code is just another
feature that you offer the user.  It's not unprecendented.  Automobiles,
phone switches, etc, they all design in test points.

>I am willing
>to consider that a library might need to adjust itself to enable client
>applications to test *themselves* (Testing the library is the library
>vendor's responsibility) but I still haven't seen a detailed, worked out
>example demonstrating how a library might prevent client applications
>from testing themselves. Pithy sayings are well and good; but they need
>to be backed up by case studies with enough detail to allow them to be
>independently verified.
>  
>

I visit work with roughly 10-15 teams a year, and the problems are
pretty common, especially now that the profile of testing has been
raised.  The most recent one is a team that writes trading software.  
They don't want to issue trades to a real exchange so it's mocked.  
Testing would bankrupt the company if their software issued testing
trades to a real exchange. :-)

I've never thought about case studies to show people who've never
encountered the problem, that there is a problem.  I'm not sure what it
would achieve really.  If you haven't encountered it, you're lucky.  
What domain do you work in?

>I'll keep an eye out for such a case in the future, but I don;t recall
>ever noticing one. I do recall numerous examples where I had trouble
>testing code that wasn't intended to be used as a library in the first
>place. However in all cases I can think of the problems that prevented
>testing also prevented library usage. The problems were in no way unique
>to testability, nor did you have to resort to testability to justify
>fixing the problems,
>
>  
>

Again, you're lucky.  

Michael Feathers
www.objectmentor.com




 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/junit/

<*> To unsubscribe from this group, send an email to:
    junit-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 

[Michael Feathers]

Elliotte Harold wrote:

>Michael Feathers wrote:
>
>  
>
>>No actually, we couldn't write automated tests.  There was no path back
>>to check results, just instrument actions.
>>    
>>
>
>I suspect in that case the library is dysfunctional irrespective of
>testing. There should be some form of return value, error code, or
>callback that indicates whether the instrument took the action. That's
>useful for a lot more than just testing.
>  
>

If I remember correctly there were error returns, but error returns
don't tell you whether the software performed exactly the steps you
wanted to have performed.  We didn't want to run the instrumentation
over and over again for testing because it consumed some expensive
material.  Mocking would've helped.

>Perhaps the instrument only had a one-way communication channel? I've
>seen a few like that. If so, you could add a pass-through device that
>logs all the requests, or use some other device to check what the
>instrument does. That's certainly non-trivial, but not impossible
>either. Furthermore the test would be of the instrument itself rather
>than of what the instrument is supposed to do.
>  
>
What you're talking about is a choice, and it's nice to make it freely,
not to have it forced upon you by a framework.  Like I said earlier, I
do like having system tests, but tests that test logic independently
have value and they can be much less expensive on a number of fronts.

Michael Feathers
www.objectmentor.com




 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/junit/

<*> To unsubscribe from this group, send an email to:
    junit-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 

[Michael Feathers]

Cédric Beust ♔ wrote:

>On 8/29/06, Elliotte Harold <elharo@...> wrote:
>  
>
>>Now if the library had a legitimate need to create documents in memory
>>for reasons other than testing, then I would add such functions. However
>>I wouldn't do it just for testing.
>>    
>>
>
>
>I would.  When you're an API writer, it behooves you to make your library
>general enough that it can be used for cases you didn't envision, or you'll
>make the life of your users harder (such as the situation mentioned by
>Michael earlier where the vendor didn't make their member functions virtual,
>a bad habit that has irked me on more than one occasion with C++ libraries).
>
>Same thing if your API will be reading data:  make it possible for this data
>to come from virtually any possible source:  file, stream, iterator,
>network, database, etc...
>  
>

Yup. API designers ultimately work for the people who use their APIs. I
don't think that the testability things I've been mentioning are
malicious omissions, and I do see more API designers factoring
testability in. Raising awareness is key.

Michael Feathers
www.objectmentor.com





 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/junit/

<*> To unsubscribe from this group, send an email to:
    junit-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 

[Michael Feathers]

Elliotte Harold wrote:

>Cédric Beust ♔ wrote:
>
>  
>
>>I would.  When you're an API writer, it behooves you to make your library
>>general enough that it can be used for cases you didn't envision, or you'll
>>make the life of your users harder
>>    
>>
>
>I'm sorry, but I flat out disagree. You should put in what is currently
>needed, no more. Do not try to support use cases you do not envision and
>do not understand. The bottom line is that if you leave something out,
>you can always add it later. However, once you've shipped API it becomes
>impossible to take it away, even if you later realize you were mistaken
>or your design is poor. (Just look at the Java class libraries.)
>  
>

Personally, I think that API designers should anticipate that people
would want to test their code.  In general, the things that you have to
do to support that aren't too severe.  Your provide facilities for
mocking, etc.  Most of those things can be discovered by attempting to
write unit tests for code that uses your API.

Re changing things in published APIs.  Yes, it can be hard but it is
doable.  It's really a social issue rather than a technical issue.

Michael Feathers
www.objectmentor.com




 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/junit/

<*> To unsubscribe from this group, send an email to:
    junit-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 

[Lasse Koskela]

Harry,

First of all, please don't reply to ongoing discussions with
completely unrelated questions. It only serves to annoy those who are
trying to follow the original discussion and actually decreases your
chances of getting replies to your question.

On 8/30/06, hari_mourya <hari_mourya@...> wrote:
>  can u tell me how to make suits in junit.

I presume you mean test suites? Did you try to google for "junit" and "suite"?

    http://www.google.com/search?q=junit+suite

The first two hits, for example, seem to answer your question
reasonably well for both 3.8 and 4.x versions of JUnit.

-Lasse-


 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/junit/

<*> To unsubscribe from this group, send an email to:
    junit-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 

[J. B. Rainsberger]

Elliotte Harold wrote:

> Michael Feathers wrote:
>
>  > Unfortunately, programmers who want to unit test their code suffer. API
>  > designers rarely think about testability of client code. I see the
>  > effect nearly every week at client sites.
>
> What sort of problems do you see? I admit I don;t think much about the
> testability of client code either, but I'm not sure how that practically
> impacts anything. Can you elaborate on these problems you've seen?

Mike, you should send Elliotte a review copy of Working Effectively with
Legacy Code. :)
--
J. B. (Joe) Rainsberger :: http://www.jbrains.ca
Your guide to software craftsmanship
JUnit Recipes: Practical Methods for Programmer Testing
2005 Gordon Pask Award for contribution Agile Software Practice


 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/junit/

<*> To unsubscribe from this group, send an email to:
    junit-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 

[J. B. Rainsberger]

Elliotte Harold wrote:

>  > I used a DOM parsing
>  > library a few months ago which, by all appearances, didn't let you
>  > create a document in memory. You had to either point it to a URL or the
>  > disk. So, to write tests that could otherwise easily be written in
>  > memory, you needed either a server or a scattering of files on disk.
>
> That seems OK to me. If the library doesn't need a means of creating
> documents in memory for its own purposes, then it shouldn't add those
> just for testing. Had it done so, you would have used those functions.
> However, because it didn't you tested the code in a more realistic
> fashion that is more likely to expose bugs. That's a good thing.

I'm not sure that's true: I'm pretty sure the bugs are more likely to be
in the DOM processing than in the routines to read and write documents
from/to disk. At a minimum, that's where I'd prefer to look first.
--
J. B. (Joe) Rainsberger :: http://www.jbrains.ca
Your guide to software craftsmanship
JUnit Recipes: Practical Methods for Programmer Testing
2005 Gordon Pask Award for contribution Agile Software Practice


 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/junit/

<*> To unsubscribe from this group, send an email to:
    junit-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 

[J. B. Rainsberger]

Elliotte Harold wrote:

>
>
> Michael Feathers wrote:
>
>  > No actually, we couldn't write automated tests. There was no path back
>  > to check results, just instrument actions.
>
> I suspect in that case the library is dysfunctional irrespective of
> testing. There should be some form of return value, error code, or
> callback that indicates whether the instrument took the action. That's
> useful for a lot more than just testing.

I think this is a little definition chasing. If the library returns
information about what happened, that's only useful if you plan to react
to that information somehow. I believe in the vernacular you would be
checking the result code or error code. Isn't that essentially testing?
>
> Perhaps the instrument only had a one-way communication channel? I've
> seen a few like that. If so, you could add a pass-through device that
> logs all the requests, or use some other device to check what the
> instrument does. That's certainly non-trivial, but not impossible
> either. Furthermore the test would be of the instrument itself rather
> than of what the instrument is supposed to do.

What if, with just a little more effort, it was trivially easy? Why not
just do that?
--
J. B. (Joe) Rainsberger :: http://www.jbrains.ca
Your guide to software craftsmanship
JUnit Recipes: Practical Methods for Programmer Testing
2005 Gordon Pask Award for contribution Agile Software Practice


 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/junit/

<*> To unsubscribe from this group, send an email to:
    junit-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 

[J. B. Rainsberger]

Elliotte Harold wrote:

> Michael Feathers wrote:
>
>  > Nope. We wrapped it. Yes, we had system tests, but in order to test
>  > our logic independently, we pretty much had to wrap it.
>
> I don't want the tests to be independent of the libraries they depend
> on. I want them to depend on exactly what the code depends on: no more;
> no less. That way you find bugs in the boundaries between model classes
> and libraries as well as in the model classes and libraries themselves.

You seem to think that's (1) the only way to do it and (2) the best way
to do it. I'm not sure that's always true, which is why I use contract
tests and interaction tests to perform the same task you perform by
testing against the real thing. I do what I do because of the
improvements in my design; you what do you do (I presume) because it's
closer to how the thing will be used and you don't mind the extra cost
of testing against the real thing. It would be interesting to get to the
bottom of why so many of us feel testing against the real thing is too
expensive and why so many of you feel testing against the real thing is
worth the cost.

>  > The fact is, testing is a legitmate need. Designing for testability is
>  > simply good engineering.
>
> The tail is wagging the dog. Testing is done to support the project. It
> is not the project, and it should not control the project.

I find this interesting, considering that many projects do not ship
until their testing phase is complete /or/ feel bad that they ship
before their testing phase is complete. Many projects that do ship
before their testing phase is complete end up shipping shit.

It seems testing is more than something that supports the project.

> I'll keep an eye out for such a case in the future, but I don;t recall
> ever noticing one. I do recall numerous examples where I had trouble
> testing code that wasn't intended to be used as a library in the first
> place. However in all cases I can think of the problems that prevented
> testing also prevented library usage. The problems were in no way unique
> to testability, nor did you have to resort to testability to justify
> fixing the problems,

So this is one point of commonality: we say "Testable designs tend to be
good designs"; you say "Difficult-to-test libraries tend to be
difficult-to-use libraries". Those sound pretty equivalent to me.
--
J. B. (Joe) Rainsberger :: http://www.jbrains.ca
Your guide to software craftsmanship
JUnit Recipes: Practical Methods for Programmer Testing
2005 Gordon Pask Award for contribution Agile Software Practice


 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/junit/

<*> To unsubscribe from this group, send an email to:
    junit-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 

[J. B. Rainsberger]

Elliotte Harold wrote:

> Michael Feathers wrote:
>
>  > Nope. We wrapped it. Yes, we had system tests, but in order to test
>  > our logic independently, we pretty much had to wrap it.
>
> I don't want the tests to be independent of the libraries they depend
> on. I want them to depend on exactly what the code depends on: no more;
> no less. That way you find bugs in the boundaries between model classes
> and libraries as well as in the model classes and libraries themselves.

I find this statement curious. Let me explore a specific example: JDBC.

JDBC consists of a generic API, mostly interfaces, and vendors implement
those interfaces. The idea is that, at least in the broad strokes,
different JDBC drivers implement the same basic concepts the same way
(setting prepared statement parameters, getting connections, that kind
of thing... differences in SQL are another story altogether).

Now if I want to know whether I'm using the JDBC API properly, it seems
to be that testing against one vendor's implementation has the
limitation of assuming that the vendor has implemented the JDBC
interfaces properly. If I write a test against my code (using their JDBC
driver) and the test fails, where is the defect? In my code? In theirs?
Hunting that defect down takes time.

Consider an alternative: I write interaction tests for my code that mock
the JDBC interfaces, based on commonly-accepted understanding of how the
JDBC interface methods behave. Again, I'm assuming that the vendor
implements the interfaces correctly; however, I also write a Contract
Test that checks whether the JDBC driver indeed implements the interface
correctly. When I write a test against my code and the test fails, the
defect is certainly in my code, because I'm incorrectly using the JDBC
interfaces. When a Contract Test for the vendor's JDBC driver fails, the
defect is certainly in the vendor's driver. There is no need to look
further.

Given that my project's System Tests will check our use of JDBC and our
vendor's driver in the context of realistic business transactions, I see
no need to duplicate that effort in my object tests.
--
J. B. (Joe) Rainsberger :: http://www.jbrains.ca
Your guide to software craftsmanship
JUnit Recipes: Practical Methods for Programmer Testing
2005 Gordon Pask Award for contribution Agile Software Practice


 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/junit/

<*> To unsubscribe from this group, send an email to:
    junit-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 

[J. B. Rainsberger]

Elliotte Harold wrote:

>
>
> J. B. Rainsberger wrote:
>
>  > I find it difficult not to interpret this as a (very mild) personal
>  > attack. You seem to imply that we are not also practitioners. I suspect
>  > you're not an asshole, so I imagine you mean something else. I would
>  > appreciate you clarifying this position. Is it necessarily the case,
>  > then, that "the sort of programmers who... hang out on lists like this
>  > one" don't know what we're talking about, because I kinda think I do and
>  > I kinda think I've proven that.
>
> You do know what you're talking about, and you are practitioners, as am
> I. However you're making the classic mistake of assuming that everyone
> else is just like you, and that what works for you works for them.

Thanks. I wanted to be sure that was the case before I moved much
further forward. I appreciate the clarification.

> This
> is a *HUGE* and unrecognized fallacy that underlies a lot more than
> programming methodologies. For instance, it's largely responsible for
> the failure of modern elementary and secondary education, which works
> for maybe 5% of children. However that's those 5% that go onto become
> teachers and principles and propagate the same techniques to future
> generations, while ignoring the failure of 95% of their students.

I think I understand exactly where you're coming from here.

> The simple fact is that people learn and think differently. No one
> technique works for everyone, but some techniques do work for more
> people. We tend to self-select into groups that think similarly and
> learn similarly to ourselves. The people who like interfaces are a
> self-selected group of programmers who think at a very high degree of
> abstraction, even for programmers (already a self-selected and abstract
> bunch). This doesn't mean they don't produce quality software. It does
> mean that you can't expect what works for them to work for all or even
> most developers.

Thank you, Elliotte, for making that clearer.
--
J. B. (Joe) Rainsberger :: http://www.jbrains.ca
Your guide to software craftsmanship
JUnit Recipes: Practical Methods for Programmer Testing
2005 Gordon Pask Award for contribution Agile Software Practice


 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/junit/

<*> To unsubscribe from this group, send an email to:
    junit-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 

[Elliotte Harold]

J. B. Rainsberger wrote:

> JDBC consists of a generic API, mostly interfaces, and vendors implement
> those interfaces. The idea is that, at least in the broad strokes,
> different JDBC drivers implement the same basic concepts the same way
> (setting prepared statement parameters, getting connections, that kind
> of thing... differences in SQL are another story altogether).
>

JDBC is one of the rare cases where interfaces do make sense because
there really are multiple independent implementations, and the same code
may even need to work against more than one of them over time.
Supporting this flexibility doesn't come without severe costs, but in
the case of JDBC I think those costs are worth paying. This is really
the classic example to demonstrate why we need interfaces.

However, far too commonly people extrapolate from JDBC and similar
examples to use cases where interfaces simply don't make sense. The vast
majority of code and classes never needs more than a single
implementation. The division of code into separate modules for interface
and implementation is needless abstraction most of the time. The costs
are high, and very little if any benefit is achieved.

Interfaces are a special purpose solution for a few uncommon but
important use cases. They are not the first thing you should pull out of
your toolbox. They should not be the default way you design a class
absent an obvious need.

--
Elliotte Rusty Harold  elharo@...
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/


 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/junit/

<*> To unsubscribe from this group, send an email to:
    junit-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 

[Michael Feathers]

Elliotte Harold wrote:

>J. B. Rainsberger wrote:
>
>  
>
>>JDBC consists of a generic API, mostly interfaces, and vendors implement
>>those interfaces. The idea is that, at least in the broad strokes,
>>different JDBC drivers implement the same basic concepts the same way
>>(setting prepared statement parameters, getting connections, that kind
>>of thing... differences in SQL are another story altogether).
>>
>>    
>>
>
>JDBC is one of the rare cases where interfaces do make sense because
>there really are multiple independent implementations, and the same code
>may even need to work against more than one of them over time.
>Supporting this flexibility doesn't come without severe costs, but in
>the case of JDBC I think those costs are worth paying. This is really
>the classic example to demonstrate why we need interfaces.
>

Elliotte, what are the downsides of interfaces, in your opinion?  I know
you don't like to use them as much as many other people do, but I don't
know why.

Michael Feathers
www.objectmentor.com




 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/junit/

<*> To unsubscribe from this group, send an email to:
    junit-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 

[Elliotte Harold]

Michael Feathers wrote:

> Elliotte, what are the downsides of interfaces, in your opinion?  I know
> you don't like to use them as much as many other people do, but I don't
> know why.

1. Excess complexity

2. No precondition, postcondition, or class invariant validation

3. Cannot add new methods to an existing interface in a later version
without breaking all existing code


--
Elliotte Rusty Harold  elharo@...
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/


 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/junit/

<*> To unsubscribe from this group, send an email to:
    junit-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 

[Cédric Beust ♔]

Hi Elliotte,

On 9/1/06, Elliotte Harold <elharo@...> wrote:

>
> Michael Feathers wrote:
>
> > Elliotte, what are the downsides of interfaces, in your opinion?  I know
> > you don't like to use them as much as many other people do, but I don't
> > know why.
>
> 1. Excess complexity
>
> 2. No precondition, postcondition, or class invariant validation
>
> 3. Cannot add new methods to an existing interface in a later version
> without breaking all existing code

Fair points.

Interfaces do add some complexity, but they also buy you flexibility and
extensibility, so I'd be sure to always weigh these different aspects before
choosing (or not) to introduce an interface.

I would argue that concrete classes suffer from 2) as well, and the only way
you can guarantee that the orchestration of your classes/interfaces is
respected is...  with tests.

Indeed, interfaces should become immutable once they are published, but
there are ways to support interfaces with added methods without breaking
backward compatibility.  Here is how.

Suppose you publish an interface:

public interface IAccount {
  public void processCash();
}

In v2, you decide your account needs to support credit cards as well, so you
create the following interface:

public interface IAccount2 extends IAccount {
  public void processCreditCard();
}

Now, your business code needs to use the following trick:

IAccount a = ...;

if (a instanceof IAccount2) {
  IAccount2 a2 = (IAccount2) a;
  a2.processCreditCard();
}

This code is guaranteed to be fully backward compatible and yet allow for
your interfaces to grow with your needs.  This trick is used extensively in
COM and Eclipse, so while the instanceof is still a bit annoying, it's still
important to be aware of such a possibility.

--
Cédric
http://testng.org


[Non-text portions of this message have been removed]



 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/junit/

<*> To unsubscribe from this group, send an email to:
    junit-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 

[Elliotte Harold]

Cédric Beust ♔ wrote:

> I would argue that concrete classes suffer from 2) as well, and the only way
> you can guarantee that the orchestration of your classes/interfaces is
> respected is...  with tests.
>

No, they don't. The checking isn't as clean as it is in a language like
Eiffel that makes these parts of the language, but it's absolutely
possible. For instance, suppose there's a precondition that the argument
to the setHours() method is between 1 and 12. We check it thusly:

public void setHours(int hours) {
   if (hours < 1 || hours > 12) {
     throw new IllegalArgumentException("Hours out of bounds: " + hours);
   }
   this.hours = hours;
}

With an interface, anyone can pass anything that meets the type
requirements.

If Java were extended so that preconditions and class invariants could
be declared and enforced on interfaces, then I'd have a lot less
objection to them. This is not logically impossible or inconsistent.
It's just that Java is not currently designed like this.

--
Elliotte Rusty Harold  elharo@...
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/


 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/junit/

<*> To unsubscribe from this group, send an email to:
    junit-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 

[unclebob]

> > Elliotte, what are the downsides of interfaces, in your opinion?
>
> 1. Excess complexity

They make receiving a message more complex, it's true.  They make  
sending a message much simpler.  Or rather, they add more lines of  
code on the receiving side; but they eliminate dependencies on the  
sending side.  The benefit of those eliminated dependencies is very  
powerful.

> 2. No precondition, postcondition, or class invariant validation

I think unit tests are a better way to ensure this kind of  
validation.  However, if you must have them in line, then put them in  
the derived classes where they belong.

> 3. Cannot add new methods to an existing interface in a later version
> without breaking all existing code

Interface Segregation Principle.

Elliotte, I think there's a Ruby programmer inside you trying to get  
out.  There are no interfaces in Ruby, but all classes act as though  
they had them.  Senders have no dependency on receivers.



----
Robert C. Martin (Uncle Bob)  | email: unclebob@...
Object Mentor Inc.            | blog:  www.butunclebob.com
The Agile Transition Experts  | web:   www.objectmentor.com
800-338-6716                  |






 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/junit/

<*> To unsubscribe from this group, send an email to:
    junit-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 

[unclebob]

> Indeed, interfaces should become immutable once they are published,  
> but
> there are ways to support interfaces with added methods without  
> breaking
> backward compatibility. Here is how.
>
> Suppose you publish an interface:
>
> public interface IAccount {
>   public void processCash();
> }
>
> In v2, you decide your account needs to support credit cards as  
> well, so you
> create the following interface:
>
> public interface IAccount2 extends IAccount {
>   public void processCreditCard();
> }

This path leads to madness.

Every class that you'd like to extend, without modifying, will result  
in a hierarchy.  If these classes are already in a hierarchy then  
you'll have a two dimensional hierarchy, or a ladder.  e.g.

Employee<|--------------Employee2
    A                        A
    |                        |
SalariedEmp<|---------SalariedEmp2
    A                        A
    |                        |
CommissionedEmp<|---CommissionedEmp2

I HOPE that the trick used in COM and Eclipse that you were referring  
to was:

      |IAccount|    |IAccount2|
          A              A
          |              |
          +------+-------+
                 |
              |MyAccount|

(i.e. the Interface Segregation Principle) Which satisfies Elliotte's  
third point since users of IAccount do not need to know about  
IAccount2 unless they want to call processCreditCard.


----
Robert C. Martin (Uncle Bob)  | email: unclebob@...
Object Mentor Inc.            | blog:  www.butunclebob.com
The Agile Transition Experts  | web:   www.objectmentor.com
800-338-6716                  |






[Non-text portions of this message have been removed]



 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/junit/

<*> To unsubscribe from this group, send an email to:
    junit-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/