Beck on Test Driven Design

http://www.threeriversinstitute.org/AbstractVsConcreteParameters.html
This is an interesting blog post. After reading it, I did asked myself, which of these approaches leads to a better design?
Take the example that Beck mentions on the JUnit mailing list, he suggests to "objectify" the integers into a SocketConnection:
class Client { Client(int address, int port) { this(new SocketConnection(address, port)); } }
He then goes on to say that it will be easy to inject an impostor and then you will have more control over the interaction between a socket connection and the client. The problem however is the "cost of modifying the client" because of the lack of flexibility one has when working with a language like Java.
This is not a problem when working with a dynamically typed language like Groovy or Ruby because clients are free to open classes, which makes it easier to remove dependencies. This eliminates the need to make any changes to the client code in order to make it more "testable". This leads me to the conclusion that "good design" changes depending on the language you are using. It seems to me that the more flexibility you have the less it matters how concrete things are in the system... NOT!
Using a flexible language does not excuse you from authoring tightly coupled code. This is something I often observe in CRUD applications because they are generally not designed using a tell don't ask, demeter abiding, publish-subscribe style. If you are lucky the team may use life-cycle hooks like before_save or @PrePersist but chances are your controllers are acting as mediators instead of view components.