中の実装を読まないと、使い方や用途が分からないメソッドにしばしば遭遇します。
本来は、中身を読まなくても使い方や用途が分かるのがメソッドのあるべき姿です。
例えるなら、リモコンのボタンやキーボードのキーだと考えてください。
中の仕組みを知らなくても、どのキーやボタンを押せば何が起こるか分かるはずです。
例えば、引数で受け取ったフラグでの条件分岐が随所に入っているメソッドを想像してみてください。
そのフラグがどういうときにtrueにすべきものなのか、変数名やコメントで明確に分かっていればいいのですが、そうでない場合、そのメソッドを使う度にいちいちロジックを読まないと、パラメータに何を渡せばいいのか分かりません。
（条件分岐が「随所に」入るのはそもそもメソッドの長さがおかしいのですが、それはまた別の話です）
また、PHPのように変数の型が厳格でない言語でありがちなのですが、無作為に何でもかんでも突っ込んだ配列をパラメータとして受け取っているメソッドも同様です。
この場合も、配列に何を入れてパラメータとして渡せばいいのか、メソッドの中身を読まないと分かりません。
メソッドの呼び元で安易に配列の構成を変えてしまったことにより、呼んでいたメソッドが動かなくなった、というようなバグの原因にもなり得ます。
「指定された必要なものをメソッドに渡せば、中で何をやってるかは分からないけど必要な結果を返してくれる」というのが、メソッドの理想的な状態です。
中身をちゃんと見ずにメソッドを使うことに抵抗を感じるかもしれませんが、インプットとアウトプットが明確になっていて、単体テストが正しく実施済みであれば何も問題はありません。
メソッドというのは正しいパラメータを渡せば、誰がどこから呼んでも同じ結果を返すはずだからです。
インプットとアウトプットが明確なブラックボックス部品を呼び出して、結果を受け取って、というのを繰り返すのがオブジェクト指向における処理のあるべき流れです。
「似たようなメソッドを２つ作るより、パラメータでフラグを渡して分岐を入れた方が汎用性の高いメソッドになる」という意見を聞いたことがありますが、それは半分正解で半分間違いです。
外からメソッドの動作を制御するのではありません。発想が逆です。
イメージとしては、「パラメータで○○フラグを渡してくれれば、～な結果を返しますよ」という情報を、メソッドの側から使う側に向けて提示するのが正解です。
メソッドを使う側は単純に、提示された情報に従ってパラメータを渡すだけです。
中で、そのパラメータがどう使われているかを意識する必要はありません。
これらのことを踏まえてコーディングをすると、メソッド一個一個の役割がより明確になり、汎用性も高くなってくると思います。
最初の話に戻りますが、リモコンのボタンやキーボードのキーのように、中身を知らなくても必要なときに押しさえすれば求める結果が返ってくる、というのが理想的な姿です。