Closures vs Lambdas

Where closures go beyond lambdas is that they bind or "close over" variables that are not explicitly defined in the closure's scope.

http://dublintech.blogspot.com/2014/05/groovy-closures-this-owner-delegate.html

Use lots of small simple classes instead of big complex classes

Favor complex network of simple objects over a simple network of complex objects

http://stackoverflow.com/a/2947823

That's one more voice in favor of the "tiny pieces" method of breaking down applications.

When to use 'new'

Now, this isn't to say that you can never use new manually -- but you should reserve that for value-type objects that don't have external dependencies. (And in those cases, I'd argue that you're often better off with a static factory method than a public constructor anyway, but that's beside the point.)

http://stackoverflow.com/a/28749192

Why not to use PowerMock

In my opionion [sic], creating a new collaborating service is not bad primarily because it's untestable, but because it introduces coupling and undermines polymorphism, and similarly for the static invocations of the Database class. 

 http://blog.xebia.com/mocking-the-unmockable-too-much-of-a-good-thing/

So "testability" has always been more than just whether a class is literally testable in terms of lack of technical limitations. Author seems to suggest "testability" has really been a proxy argument for good OOP design.

Having realized this, I now understand what Misko Hevery meant when he said the following (unfortunately without elaborating):

 Yes I am aware of them, and I think it is a bad idea. You are trying to compensate bad design with Monkey Patching.

http://misko.hevery.com/2008/12/15/static-methods-are-death-to-testability/