コード抽象化の 3 つの原則

この記事はRuan Yifengのブログから転載したものです。元の内容は次のとおりです。

ソフトウェア開発は「抽象化」（Abstraction）の原理の現れです。 いわゆる「抽象化」とは、特定の問題から共通のパターンを抽出し、共通の解決策を使用してそれらに対処することを指します。

ソフトウェアを開発するとき、私たちは常に他の人が書いたコードを使いたいと思う一方で、自分が書いたコードをできるだけ再利用できることを望みます。作業負荷を軽減します。この 2 つの目標を達成するには、「抽象化」が必要です。 最近、アメリカのプログラマー、デリック・ベイリー氏の「抽象化」が従うべき 3 つの原則について述べた記事を読み、非常に刺激的でした。


1. DRY原則
DRYとはDon'trepeat Yourselfの略で「同じことを繰り返さない」という意味です。

ソフトウェア工学の有名な本「The Pragmatic Programmer」がこの原則を最初に提案しました。その意味は、システムのすべての機能が独自の実装を持つ必要があるということです。つまり、同じ問題が複数回発生した場合は、共通の解決策を抽象化し、同じ機能を繰り返し開発しないようにする必要があります。 この原則は、「1 回限り」原則と呼ばれることもあります。


2. ヤグニ原則
YAGNIとはYou are not going to need itの略で「必要ないよ」という意味です。

これは「エクストリームプログラミング」が提唱する原理で、便利だと思っている機能が実際には使われていないということです。したがって、コア機能を除いて他の機能をデプロイする必要がないため、開発を大幅にスピードアップできます。 その背後にある基本的な考え方は、ソフトウェアをできるだけ速く簡単に実行できるようにすることです (機能する可能性のある最も単純なことを実行します)。

しかし、ここで問題が発生します。よく考えてみると、DRY 原則と YAGNI 原則は完全に互換性がないことがわかります。前者は「抽象化」を追求し、普遍的な解決策を見つける必要がありますが、後者は「迅速さと経済性」を追求します。これは、「必要ない」可能性が高いため、抽象化に焦点を当てないことを意味します。したがって、第三の原則があります。


3. 3 つの原則
3 の法則は「三次元原則」と呼ばれ、ある機能が 3 回目に現れると、その機能は「抽象化」されることを意味します。

これは、特定の関数を初めて使用するときは、特定のソリューションを作成し、2 回目に使用するときは、その関数が 3 回目に表示されるときにのみ、前のコードをコピーすることを意味します。 「抽象化」して一般的な解決策を書き始めます。 これを行う理由はいくつかあります:

• 簡単なトラブル。関数が 1 つまたは 2 つの場所でのみ使用される場合は、「抽象化」に時間を費やす必要はありません。
• パターンを見つけやすい。 「抽象化」には、問題のパターンを見つける必要があります。問題が発生する機会が増えるほど、パターンが見えやすくなり、より正確に「抽象化」できるようになります。たとえば、シーケンスの場合、パターンを決定するには 2 つの要素では不十分です: 1、2、_、_、_、_、; 3 番目の要素が出現すると、パターンがより明確になります: 1、2、4、_、_ 、_。
• 過度の冗長性を防止します。関数に複数の実装が同時に存在すると管理が非常に面倒になり、変更する際には多くの修正が必要になります。実際の作業では、繰り返しの実装は最大 1 回まで許容され、それ以上は許容されません。

要約すると、「3 次元原則」は DRY 原則と YAGNI 原則の間の妥協点であり、コードの冗長性と開発コストの間のバランス ポイントであり、「抽象化」するときに従う価値があります。 。