分離してテストおよび理解できる小さな断片でコードを構成する必要があります。
関数、メソッド、クラスのいずれであっても、それぞれの小さなピースは 1 つのことを適切に行う必要があります。
これらの小さな部分からより大きな機能を構成できるようにする必要があります。これにより、各構成が内部でどれほど複雑であっても、その機能の抽象化のレベルでは単純なままになります。
言い換えれば、高レベルであっても、複雑な内部構造を単純な外部構造で説明できるはずです。
これは、Andrew Koenig が「抽象化は選択的無知である」と言ったときの意味です。何かが内部でどのように機能するかについての知識を意図的にあきらめることによって、それがどのように機能するかではなく、それが何をするかを考えることができます。
簡単な例を挙げましょう。ハイエンドでは、「このクラスは、あるデータ構造で最小の int を見つける」と言うかもしれません。それは、それがどのように行うかではなく、何をするかを教えてくれます。この高レベルの抽象化では、私たちが気にかけているのはそれだけです。
私たちは何かをするものを持っています、そしてそれはモジュラーです、それを同じことをする他のものに置き換えることができます。それはパブリックインターフェースを持っています。
下位レベルでは、これがどのように機能するかは、内部的にはヒープまたは優先キューなどである可能性があります。
そして、それらは、ツリー、自己均衡ツリー、または (次善の) リンクされたリストの観点から実装される場合があります。リンクされたリストは次善の実装になりますが、それが同じことをしている限り、私たちは本当にカフェではありません。同じインターフェースで。
そして、それらはツリー トラバーサルの観点から実装されます (事前注文: 常に左、親、右の順序で進みます)。そして、それらはノード上の単純な操作の観点から実装されています。
重要な部分は次のとおりです。アプリの残りの部分は、そのモジュールの内部や副作用に依存していないため、貧弱な実装をより良い実装に交換しても、他のコードは変更されず、全体的に速度が向上します。
各層は、そのすぐ上の層とすぐ下の層とのみ通信するため、各層を置き換えることができます。視覚的には、ベン図の重なりではなく、円の中に円の中に円のように見えます。
直感に頼る必要がある場合は、コードに副作用があるか、他のモジュールへの過度に広範なインターフェイスがあるか、インターフェイスではなく、自己完結型で構築されたコードではないことを示唆しています。 、交差しない、モジュール、オーバーラップと交差、脆弱なコードがあります。理解できるほど単純な断片に分解していないこと。
（くそ、遅い。この説明をもっとうまく分解できたのではないかと心配している.これを編集するために戻ってくるだろう.）