メモ Good Code, Bad Code

null の安全性とオプションの型について詳しく知りたい場合は、付録 B にさらに多くの情報が含まれています

null 安全に関して、付録を割いて説明、null安全をデフォルトで使用することを推奨している、共感できる

2.2.1抽象化の層とコード品質の柱

• 読みやすさ
• モジュール性
• 再利用性
• テスト容易性

私たちが書くコードは、他のコードが利用できるミニAPIを公開していると考えると、役に立つことが多い

大事

コード品質の柱を満たす例

インターフェースを介して実装を行う場合のクラスが一つしか無くてもメリットはある

わかりみがあるな...

1. このレイヤーを使用するエンジニアがどの機能を使用すべきか、または使用すべきでないかについて混乱することがありません。もしエンジニアがTextSummarizerImplクラスに新しいパブリック関数を追加しても、TextSummarizerインターフェースにしか依存しないので、これより上のレイヤーのコードには公開されない。

2. 最初にコードを書いたときは、2つ目の実装は必要ないと確信していたかもしれないが、1、2ヶ月後にこの仮定が間違いであることが判明するかもしれない。もしかしたら、いくつかの段落を省略するだけでテキストを要約するのはあまり効果的ではないことに気づき、まったく別の方法でテキストを要約する別のアルゴリズムを実験することにするかもしれない。

3. 例えば、実装クラスが特に複雑な処理をしていたり、ネットワークI/Oに依存している場合、テスト時にモックや偽の実装で代用したくなることがあります。使用するプログラミング言語によっては、これを実現するためにインターフェースを定義する必要があるかもしれません。

4. 同じクラスで2つのサブ問題を解決できる 
1つのクラスで2つ以上の異なる抽象化レイヤーの実装を提供できることがあります。この例として、LinkedList の実装クラスがList とQueueインターフェース の両方を実装する場合があります。これは、あるシナリオでキューとして使用することができ、そのシナリオのコードではリストとしても使用できることを意味します。これは、コードの汎用性を大幅に向上させることができます。

4.2.2 Fail loudly

If code fails fast and fails loudly, then there is a good chance that a bug will be discovered during development or during testing (before the code is even released).

なるべく早く失敗する、かつ、気づきやすいエラーにする

4.2.4 Don’t hide errors

エラーは隠さない、だめ、絶対

5.2.3 Comments can be great for explaining why code exists

コードが自己説明するのが苦手なのは、なぜそのようなことが行われるのかという点です。
あるコードが存在する理由や、そのコードが何をするのかという理由は、
そのコードを見る他のエンジニアが必ずしも知らないような文脈や知識と結びついていることがあります。
このようなコンテキストが、コードを理解したり、安全な方法でコードを変更したりするために重要である場合、コメントは非常に便利です。
あるコードが存在する理由を説明するためにコメントするのが良い例として、次のようなものがあります。

• 製品またはビジネスの決定
• 奇妙で明白でないバグの修正
• 依存関係の直感に反するクセを処理する

6.5.2 Solution: Make critical inputs required

パラメータは、その関数にとって重要なものであり、そのパラメータがなければその関数が行うことができないものです。このようなパラメータがある場合は、必須パラメータにして、その値が利用できない場合は関数を呼び出すことができないようにしたほうが安全な場合があります。

デメテルの法則

デメテラの法則（LoDと略されることもある）とは、あるオブジェクトが他のオブジェクトの内容や構造について仮定することをできるだけ少なくすべきであるというソフトウェア工学の原則である。特に、この原則は、あるオブジェクトがすぐに関連する他のオブジェクトとだけ相互作用すべきであることを提唱しています。