Decompose and Expose

Large, complex private methods are a code smell. An implementation which is so complex that it cannot be usefully decomposed into component parts (with public interfaces) is a problem in testability that reveals potential design and architectural problems. The 1% of cases where the private code is huge will usually benefit from rework to decompose and expose. – S.Lott Feb 14 '12 at 20:06

http://softwareengineering.stackexchange.com/questions/135047/new-to-tdd-should-i-avoid-private-methods-now#comment253312_135049

Continuous Delivery Quotes

...a suite of tests is run, optimized to execute very quickly. We refer to this suite of tests as commit stage tests rather than unit tests, it is useful to include a small selection of tests of other types at this stage...
Begin the design of your commit test suite by running all unit tests. Later, as you learn more about what types of failure are common in acceptance test runs ... you should add specific tests to your commit test suite to try and find them early on.

Acceptance tests written without developer involvement also tend to be tightly coupled to the UI and thus brittle and badly factored, because the testers don't have any insight into the UI's underlying design and lack the skills to create abstraction layers or run acceptance tests against a public API. 

- Continuous Delivery
- Jez Humble, 2011

The "Ultimate Configurability" Antipattern

The desire to achieve flexibility may lead to the common antipattern of "ultimate configurability" which is, all too frequently, stated as a requirement for software projects. It is at best unhelpful, and at worst, this one requirement can kill a project.

Continuous Delivery - Addison-Wesley 2012 p. 40

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/

APIs should be impossible to misuse

It should hard or impossible to misuse a good API

Josh Block
https://www.youtube.com/watch?v=aAb7hSCtvGw

The above statement validates my preference for using the Builder Pattern to facilitate clients to provide named constructor arguments in a sense. E.g. if a constructor has several string parameters, rather than rely on flaky javadocs and parameter names to inform the user what to provide, I would prefer to provide builder methods that unambiguously let the user know what to provide. For validation of inputs, I make the null checks, etc, in the private constructor. That makes it about as hard to misuse the API/constructor as possible in Java.

Constructor Parameters known only at Runtime

it's assumed here that your Factory knows what the parameters for the constructors should be. If this is only known by the client of the Create method, then I would say the indirection isn't necessary and the client should construct the rule itself

http://stackoverflow.com/a/23765599

So, Factory Pattern may not be appropriate when the constructor parameters need to be provided by the client.

As for "DI abuse," see http://stackoverflow.com/a/1056229 on direct instantiation rather than injection of stateless services:

The abuse of DI leads to stateless objects which really should be stateful ... such code is by nature domain/use-case specific. In such a case ... it makes much more sense to have the [client] directly instantiate the business service class, passing data provided by the user through a constructor

Abstract Factory and "DI Explosion"

On the problem of creating objects from both stateless services and runtime values, Mark Seemann suggests the standard Abstract Factory pattern while seeming to acknowledge that it may be overkill for simple cases (i.e. say we have a lot of these objects to create, e.g. subclasses of say HystrixCommand, do we really want to create a Factory implementation for each subclass?)

Yes I know this, though in my case I hesitate because for simple cases it's overkill to duplicate constructor with interface, factory, factory's constructor, Create method, etc. While good for complex cases, it's too "DI explosion" for simple things I think. And the question remains about automatic registration DI container. – queen3 Nov 6 '09 at 11:16 @queen3: I understand what you mean, but I'm not aware of any DI Containers that can do what you ask.

http://stackoverflow.com/questions/1686760/which-di-container-will-satisfy-this/1686887#1686887

The Pareto Principle applied in Spring JDBC

The Pareto Principle in action: going the extra mile to automate the extraction process makes the framework much more complex and delivers little real benefit

http://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/jdbc/object/MappingSqlQueryWithParameters.html

Here the Pareto Principle (or 80/20 rule) is applied via this Spring JDBC mapper.

I would argue that this notion should be considered before embarking on any major automation project, e.g. writing a framework to automate the generation of forms and form fields rather then writing static views.

Downsides of Inheritance

...using inheritance is too tightly coupled with the implementation. That is, the actual implementation is written so that one of the public methods actually use another. If you override both, and you call super, then you might get unwanted side-effects. If the implementation changes in a later version, then you will have to update your handling of it as well.

http://stackoverflow.com/questions/23121890/difference-between-delegate-mixin-and-traits-in-groovy

Unit Testing: When You're not really Testing Your Logic

However if I am working on a PR for the winrm ruby gem that implements the winrm protocol or I am working on provisioning a VM or am leaning heavily on something that uses the windows registry, if I mock away all of these layers, I may fall into the trap where I am not really testing my logic.

If I mock everything out I may just end up testing that I am calling the correct API endpoints with the expected parameters. This can be useful to some extent but can quickly start to smell like the tests just repeat the implementation. 

Unit tests play the part of the compiler for interpreted languages:

If anything, unit tests that do no more than merely walk all possible code paths can protect code from randomly blowing up. 

http://www.hurryupandwait.io/blog/why-tdd-for-powershell-or-why-pester-or-why-unit-test-scripting-language

Large Conditionals in Static Factory Methods

Create a static factory method with the same parameters as the superclass constructor. It must contain the parameter that will take the starting values of the coded type. Depending on this parameter, the factory method will create objects of various subclasses. To do so, in its code you must create a large conditional but, at least, it will be the only one when it is truly necessary; otherwise, subclasses and polymorphism will do.

https://sourcemaking.com/refactoring/replace-type-code-with-subclasses

Validation via Static Typing

Furthermore, most type system lack means to statically describe types such as “a list with at least two elements” or “a floating-point number larger than or equal to zero”.
Such requirements should be described as far as possible using static typing; anything else has to be worked around via run-time validation. 

http://programmers.stackexchange.com/a/258281