多くのプログラマーは抽象度をコントロールできていないのでは？説
「抽象化」って結構揺れが有る言葉ですね。
抽象化 (計算機科学) - Wikipedia
今特に言いたいのは主に共通化です。
例えば、ある処理をメソッドにするか、メソッドにする場合どのくらいの抽象度にするか、どこを共通化するか。
など、抽象度を選択するシーンは常に存在します。
抽象度を高くすると、より汎用的に、何でもできるようになります。
抽象度を低くすると、より具体的に、それしかできないようになります。
これを適切に判断、コントロールしているケースをあまり見かけません。
（固定抽象度になっている）
抽象度が高い＝善ではない
抽象度は使いやすさとトレードオフします。
具体的な方が「それしかできない」ため理解しやすく、「その他」について論じる必要がありません。
| what | 汎用 | 専用 |
|---|---|---|
| 将来に対して | 開いている（発展） | 閉じている（収束） |
| 作るのは | 難しい | 簡単 |
| 考えることが | 増える、難しくなる | 減る、簡単になる |
| 新しいものを追加する時 | 足並みを揃える必要がある | 足並みをそろえる必要は少ない |
| 必要なシーンは | ライブラリ、ユーティリティ、パーツなど | 製品、具体的な画面など |
「オレの最強抽象度」を持ってはいけない
デザインパターンやイケてるコードにこだわりすぎると、抽象度はいたずらに上がってしまいます。
抽象度が上がると、すべてのパターンを網羅するのが大変になります。
簡単な例を考えてみます。
ある四角形の面積が100だとして、「100」という数字を使いたいとします。
仕様上、四角形が1つしかなくて固定である場合は、「100」を定義しても良いと思います。
代わりの案として、四角形が長方形なら、100ではなく「縦と横」を定義する方法です。
我々は長方形の面積が縦×横だと分かっているので、面積を直接定義するのと大差はありません。
抽象度の高く、行き過ぎた案としては、あらゆる四角形の面積を求める関数を作成することです。
100という数字が欲しいだけなのに、関数が正しいことをテストしたり、不必要な想定に対処しなければなりません。
動くのにバグが有る状態になって、バグが潜伏したりもします。
いつ抽象度を上げ、いつ抽象度を下げるのか
例えば汚いコードをキレイにしていくときは、抽象度を下げるべきだと思います。余計に混乱を生んでしまいます。
ライブラリを作る際には抽象度を上げるべきでしょう。より汎用的なものになります。
あとから抽象度を上げられるなら、まずは抽象度を下げて取り組むべきでしょう。
・・・と、これ以上はまだちゃんと考えていないんですが（本題の「なるには」の部分）
「抽象度は選択するもので、利便性とはトレードオフである」っていうの、どう思われてるんだろうとの疑問でした。
また考えが進んだら書きます。
