Question: I notice that when I code I often use a pattern that calls a class method and that method will call a number of private functions in the same class to do the work. The private functions do one thing only. The code looks like this:

```
public void callThisMethod(MyObject myObject) {
    methodA(myObject);
    methodB(myObject);  // was mehtodB before
}

private void methodA(MyObject myObject) {
    //do something
}

 private void methodB(MyObject myObject) {
    //do something
}

```

Sometimes there are 5 or more private methods, in the past I have moved some of the private methods into another class, but there are occasions when doing so would be creating needless complexity. 

The main reason I don't like this pattern is that is not very testable, I would like to be able to test all of the methods individually, sometimes I will make all of the methods public so can I can write tests for them. 

Is there a better design I can use?

Answer: 
I believe that the pattern in question is known as composed method and it is mentioned in Kent Becks Smalltalk Best practice patterns [1]. Further, he mentions that each method does one identifiable thing and that the methods called within a method should all be at the same level of abstraction.

[1] [http://www.amazon.com/Smalltalk-Best-Practice-Patterns-Kent/dp/013476904X](http://rads.stackoverflow.com/amzn/click/013476904X)
For me this seems like a bad practice for two reasons. 

It is unclear how those methods depend on each other. If there is an order to strictly adhere to then this order should be reflected in the code. Otherwise a *hidden temporal coupling* ([see item G31 in Clean Code](http://books.google.de/books?id=_i6bDeoCQzsC&pg=PT575&lpg=PT575&dq=hidden%20temporal%20coupling&source=bl&ots=en9KAi4f48&sig=_CklftR0XkV46L8zZGNMcfZzCIA&hl=de&sa=X&ei=2J6tUaXUHYPRtAazhYDwDg&ved=0CE8Q6AEwAw)) is introduced. Making the coupling obvious can be achieved by returning an object from every method and passing that on to the next method. 

If those methods don't really depend on each other an interface should be introduced with a single method. The different implementations should be kept in a collection in a field of the owning class of `callThisMethod` and that method should only iterate through that collection and invoke the collection elements method. This way you are adhering more to the *open closed principle*, because adding another functionality is just the matter of configuring another interface implementation to be kept in that list and not changing the owning class of `callThisMethod`