開発者にとって不可欠なJava設計原則

約9分

プログラミング原則入門

ソフトウェア開発には、アーキテクト、プログラマー、およびソフトウェアを設計する必要のある人にとって指針となる、普遍的な法則と原則があります。このページでは、それらの原則をいくつか紹介しますが、完全ではありません。このページは、Lars Kappert氏によるprogramming-principlesリポジトリのフォークであり、彼が資料収集の大部分を行いました。

KISS

ほとんどのシステムは、複雑にするよりもシンプルに保つ方が最も効果的に機能します。

なぜ

コードが少ないほど、記述時間が短く、バグが少なく、変更が容易になります。
シンプルさは究極の洗練です。
完璧とは、何も付け加えるものがなくなったときではなく、
何も取り除くものがなくなったときに到達するようです。

リソース

YAGNI

YAGNIは、「you aren't gonna need it（必要になることはない）」の略です。必要になるまで実装しないでください。
必要になるまで実装しないでください。

なぜ

明日必要な機能にのみ使用される作業は、現在のイテレーションで完了する必要がある機能からの努力の喪失を意味します。
現在のイテレーションで完了する必要がある機能からの努力の喪失を意味します。
コードの肥大化につながり、ソフトウェアが大きくなり、より複雑になります。

方法

実際に必要なときに常に実装し、必要になることを予測するときは絶対に実装しないでください。
実際に必要なときに常に実装し、必要になることを予測するときは絶対に実装しないでください。

リソース

可能な限り最もシンプルなことを行う

なぜ

実際の課題に対する真の進歩は、問題が本当に何であるかについてのみ取り組む場合に最大化されます。
実際の課題に対する真の進歩は、問題が本当に何であるかについてのみ取り組む場合に最大化されます。

方法

「可能な限り最もシンプルなことは何ですか？」と自問してください。

リソース

可能な限り最もシンプルなことを行う

関心の分離は、コンピュータプログラムを明確なセクションに分離するための設計原則であり、各セクションが個別の関心事に対処するようにします。たとえば、アプリケーションのビジネスロジックが関心事であり、ユーザーインターフェースが別の関心事です。ユーザーインターフェースを変更しても、ビジネスロジックの変更は必要ないはずであり、その逆も同様です。
関心の分離は、コンピュータプログラムを明確なセクションに分離するための設計原則であり、各セクションが個別の関心事に対処するようにします。たとえば、アプリケーションのビジネスロジックが関心事であり、ユーザーインターフェースが別の関心事です。ユーザーインターフェースを変更しても、ビジネスロジックの変更は必要ないはずであり、その逆も同様です。
関心の分離は、コンピュータプログラムを明確なセクションに分離するための設計原則であり、各セクションが個別の関心事に対処するようにします。たとえば、アプリケーションのビジネスロジックが関心事であり、ユーザーインターフェースが別の関心事です。ユーザーインターフェースを変更しても、ビジネスロジックの変更は必要ないはずであり、その逆も同様です。
関心の分離は、コンピュータプログラムを明確なセクションに分離するための設計原則であり、各セクションが個別の関心事に対処するようにします。たとえば、アプリケーションのビジネスロジックが関心事であり、ユーザーインターフェースが別の関心事です。ユーザーインターフェースを変更しても、ビジネスロジックの変更は必要ないはずであり、その逆も同様です。
関心の分離は、コンピュータプログラムを明確なセクションに分離するための設計原則であり、各セクションが個別の関心事に対処するようにします。たとえば、アプリケーションのビジネスロジックが関心事であり、ユーザーインターフェースが別の関心事です。ユーザーインターフェースを変更しても、ビジネスロジックの変更は必要ないはずであり、その逆も同様です。

Edsger W. Dijkstraの引用
(1974):

これは、私が「関心の分離」と呼ぶことがあるものであり、完全には不可能であったとしても、効果的な思考の整理のために利用できる唯一の技術です。これが、私が「ある側面に注意を向ける」という意味であり、他の側面を無視することを意味するのではなく、この観点から見て、他は無関係であるという事実を正当化するだけです。
これは、私が「関心の分離」と呼ぶことがあるものであり、完全には不可能であったとしても、効果的な思考の整理のために利用できる唯一の技術です。これが、私が「ある側面に注意を向ける」という意味であり、他の側面を無視することを意味するのではなく、この観点から見て、他は無関係であるという事実を正当化するだけです。
これは、私が「関心の分離」と呼ぶことがあるものであり、完全には不可能であったとしても、効果的な思考の整理のために利用できる唯一の技術です。これが、私が「ある側面に注意を向ける」という意味であり、他の側面を無視することを意味するのではなく、この観点から見て、他は無関係であるという事実を正当化するだけです。
これは、私が「関心の分離」と呼ぶことがあるものであり、完全には不可能であったとしても、効果的な思考の整理のために利用できる唯一の技術です。これが、私が「ある側面に注意を向ける」という意味であり、他の側面を無視することを意味するのではなく、この観点から見て、他は無関係であるという事実を正当化するだけです。
これは、私が「関心の分離」と呼ぶことがあるものであり、完全には不可能であったとしても、効果的な思考の整理のために利用できる唯一の技術です。これが、私が「ある側面に注意を向ける」という意味であり、他の側面を無視することを意味するのではなく、この観点から見て、他は無関係であるという事実を正当化するだけです。
これは、私が「関心の分離」と呼ぶことがあるものであり、完全には不可能であったとしても、効果的な思考の整理のために利用できる唯一の技術です。これが、私が「ある側面に注意を向ける」という意味であり、他の側面を無視することを意味するのではなく、この観点から見て、他は無関係であるという事実を正当化するだけです。

なぜ

ソフトウェアアプリケーションの開発と保守を簡素化します。
関心が十分に分離されている場合、個々のセクションは再利用できるだけでなく、独立して開発および更新できます。
関心が十分に分離されている場合、個々のセクションは再利用できるだけでなく、独立して開発および更新できます。

方法

プログラムの機能を、重複をできるだけ少なくした個別のモジュールに分割します。
プログラムの機能を、重複をできるだけ少なくした個別のモジュールに分割します。

リソース

関心の分離

DRYに保つ

すべての知識は、システム内で単一の、明確で、信頼できる表現を持つ必要があります。
すべての知識は、システム内で単一の、明確で、信頼できる表現を持つ必要があります。

プログラム内の重要な機能はすべて、ソースコードの1か所でのみ実装する必要があります。
プログラム内の重要な機能はすべて、ソースコードの1か所でのみ実装する必要があります。類似の機能が別々のコードによって実行される場合、可変部分を抽象化することで、それらを1つに結合することが一般的に有益です。
プログラム内の重要な機能はすべて、ソースコードの1か所でのみ実装する必要があります。類似の機能が別々のコードによって実行される場合、可変部分を抽象化することで、それらを1つに結合することが一般的に有益です。
プログラム内の重要な機能はすべて、ソースコードの1か所でのみ実装する必要があります。類似の機能が別々のコードによって実行される場合、可変部分を抽象化することで、それらを1つに結合することが一般的に有益です。

なぜ

重複（不注意による重複または意図的な重複）は、メンテナンスの悪夢、不十分な要因、および論理的な矛盾につながる可能性があります。
重複（不注意による重複または意図的な重複）は、メンテナンスの悪夢、不十分な要因、および論理的な矛盾につながる可能性があります。
システムの単一要素を変更しても、論理的に無関係な他の要素を変更する必要はありません。
システムの単一要素を変更しても、論理的に無関係な他の要素を変更する必要はありません。
さらに、論理的に関連する要素はすべて、予測可能かつ均一に変更されるため、同期が維持されます。
さらに、論理的に関連する要素はすべて、予測可能かつ均一に変更されるため、同期が維持されます。

方法

ビジネスルール、長い式、ifステートメント、数式、メタデータなどを1か所のみに配置します。
ビジネスルール、長い式、ifステートメント、数式、メタデータなどを1か所のみに配置します。
システムで使用されるすべての知識の単一の、決定的なソースを特定し、そのソースを使用して、その知識の該当するインスタンス（コード、ドキュメント、テストなど）を生成します。
システムで使用されるすべての知識の単一の、決定的なソースを特定し、そのソースを使用して、その知識の該当するインスタンス（コード、ドキュメント、テストなど）を生成します。
システムで使用されるすべての知識の単一の、決定的なソースを特定し、そのソースを使用して、その知識の該当するインスタンス（コード、ドキュメント、テストなど）を生成します。
適用する
3の法則.

リソース

保守担当者のためのコーディング

なぜ

メンテナンスは、あらゆるプロジェクトで最もコストのかかる段階です。

方法

保守担当者になる。
あなたのコードを保守する人が、あなたがどこに住んでいるかを知っている暴力的なサイコパスであるかのように常にコーディングしてください。
あなたのコードを保守する人が、あなたがどこに住んでいるかを知っている暴力的なサイコパスであるかのように常にコーディングしてください。
数段階後輩の誰かがコードを拾った場合、それを読み、そこから学ぶことを喜んでくれるように、常にコードを作成し、コメントを付けてください。
数段階後輩の誰かがコードを拾った場合、それを読み、そこから学ぶことを喜んでくれるように、常にコードを作成し、コメントを付けてください。
考えさせないで.
使用する
最小驚嘆の原則.

リソース

早期最適化の回避

Donald Knuthの引用

プログラマーは、プログラムの重要でない部分の速度について考えたり、心配したりするのに膨大な時間を費やしており、これらの効率化の試みは、デバッグとメンテナンスを考慮すると、実際には大きな悪影響を及ぼします。小さな効率化については忘れるべきです。たとえば、時間の約97％の場合、早期最適化はすべての悪の根源です。しかし、重要な3％の機会を逃すべきではありません。
プログラマーは、プログラムの重要でない部分の速度について考えたり、心配したりするのに膨大な時間を費やしており、これらの効率化の試みは、デバッグとメンテナンスを考慮すると、実際には大きな悪影響を及ぼします。小さな効率化については忘れるべきです。たとえば、時間の約97％の場合、早期最適化はすべての悪の根源です。しかし、重要な3％の機会を逃すべきではありません。
プログラマーは、プログラムの重要でない部分の速度について考えたり、心配したりするのに膨大な時間を費やしており、これらの効率化の試みは、デバッグとメンテナンスを考慮すると、実際には大きな悪影響を及ぼします。小さな効率化については忘れるべきです。たとえば、時間の約97％の場合、早期最適化はすべての悪の根源です。しかし、重要な3％の機会を逃すべきではありません。
プログラマーは、プログラムの重要でない部分の速度について考えたり、心配したりするのに膨大な時間を費やしており、これらの効率化の試みは、デバッグとメンテナンスを考慮すると、実際には大きな悪影響を及ぼします。小さな効率化については忘れるべきです。たとえば、時間の約97％の場合、早期最適化はすべての悪の根源です。しかし、重要な3％の機会を逃すべきではありません。
プログラマーは、プログラムの重要でない部分の速度について考えたり、心配したりするのに膨大な時間を費やしており、これらの効率化の試みは、デバッグとメンテナンスを考慮すると、実際には大きな悪影響を及ぼします。小さな効率化については忘れるべきです。たとえば、時間の約97％の場合、早期最適化はすべての悪の根源です。しかし、重要な3％の機会を逃すべきではありません。
プログラマーは、プログラムの重要でない部分の速度について考えたり、心配したりするのに膨大な時間を費やしており、これらの効率化の試みは、デバッグとメンテナンスを考慮すると、実際には大きな悪影響を及ぼします。小さな効率化については忘れるべきです。たとえば、時間の約97％の場合、早期最適化はすべての悪の根源です。しかし、重要な3％の機会を逃すべきではありません。

もちろん、「早期」とは何かを理解することは重要です。

なぜ

ボトルネックがどこにあるかは事前に不明です。
最適化後、読みやすく、保守しにくくなる可能性があります。

方法

動作させる、正しくする、高速化する
必要になるまで最適化しないでください。また、プロファイリングでボトルネックが発見された後にのみ最適化してください。
必要になるまで最適化しないでください。また、プロファイリングでボトルネックが発見された後にのみ最適化してください。

リソース

結合の最小化

モジュール/コンポーネント間の結合は、それらの相互依存性の程度です。結合が低いほど優れています。つまり、結合とは、コードユニット「A」への未知の変更後、コードユニット「B」が「壊れる」可能性のことです。
モジュール/コンポーネント間の結合は、それらの相互依存性の程度です。結合が低いほど優れています。つまり、結合とは、コードユニット「A」への未知の変更後、コードユニット「B」が「壊れる」可能性のことです。
モジュール/コンポーネント間の結合は、それらの相互依存性の程度です。結合が低いほど優れています。つまり、結合とは、コードユニット「A」への未知の変更後、コードユニット「B」が「壊れる」可能性のことです。

なぜ

1つのモジュールを変更すると、通常、他のモジュールに連鎖的な変更が生じます。
1つのモジュールを変更すると、通常、他のモジュールに連鎖的な変更が生じます。
モジュールの組み立てには、モジュール間の依存性の増加により、より多くの労力や時間が必要になる場合があります。
モジュールの組み立てには、モジュール間の依存性の増加により、より多くの労力や時間が必要になる場合があります。
依存モジュールを含める必要があるため、特定のモジュールは再利用やテストが困難になる場合があります。
依存モジュールを含める必要があるため、特定のモジュールは再利用やテストが困難になる場合があります。
開発者は、何が影響を受けるかわからないため、コードを変更することを恐れている場合があります。
開発者は、何が影響を受けるかわからないため、コードを変更することを恐れている場合があります。

方法

必要な関係の複雑さを排除、最小化、削減します。
実装の詳細を隠すことで、結合が削減されます。
デメテルの法則を適用します。

リソース

デメテルの法則

見知らぬ人と話さないでください。

なぜ

通常、結合が強化されます
実装の詳細を過度に明らかにする可能性があります

方法

オブジェクトのメソッドは、次のメソッドのみを呼び出すことができます

オブジェクト自体。
メソッドの引数。
メソッド内で作成されたオブジェクト。
オブジェクトの直接的なプロパティ/フィールド。

リソース

継承よりもコンポジション

なぜ

クラス間の結合が少なくなります。
継承を使用すると、サブクラスは簡単に仮定し、LSPを破ります。

方法

継承するタイミングを決定するためにLSP（置換可能性）をテストします。
「has a」（または「uses a」）関係がある場合はコンポジションし、「is a」の場合は継承します。
「has a」（または「uses a」）関係がある場合はコンポジションし、「is a」の場合は継承します。

リソース

継承よりもコンポジションを優先

直交性

直交性の基本的な考え方は、概念的に関連性のないものはシステム内で関連性を持つべきではないということです。
直交性の基本的な考え方は、概念的に関連性のないものはシステム内で関連性を持つべきではないということです。

出典：直交する

これはシンプルさと関連付けられています。設計が直交するほど、例外は少なくなります。これにより、プログラミング言語でのプログラムの学習、読み取り、書き込みが容易になります。直交機能の意味はコンテキストに依存しません。主要なパラメーターは対称性と一貫性です。
これはシンプルさと関連付けられています。設計が直交するほど、例外は少なくなります。これにより、プログラミング言語でのプログラムの学習、読み取り、書き込みが容易になります。直交機能の意味はコンテキストに依存しません。主要なパラメーターは対称性と一貫性です。
これはシンプルさと関連付けられています。設計が直交するほど、例外は少なくなります。これにより、プログラミング言語でのプログラムの学習、読み取り、書き込みが容易になります。直交機能の意味はコンテキストに依存しません。主要なパラメーターは対称性と一貫性です。
これはシンプルさと関連付けられています。設計が直交するほど、例外は少なくなります。これにより、プログラミング言語でのプログラムの学習、読み取り、書き込みが容易になります。直交機能の意味はコンテキストに依存しません。主要なパラメーターは対称性と一貫性です。

出典
直交性

ロバスト性原則

行うことは控えめに、他の人から受け入れることは寛大に

連携するサービスは、相互のインターフェースに依存します。多くの場合、インターフェースは進化する必要があり、相手側で指定されていないデータを受信することになります。単純な実装では、受信したデータが仕様に厳密に従っていない場合、連携を拒否します。より高度な実装では、認識しないデータを無視して、引き続き機能します。
連携するサービスは、相互のインターフェースに依存します。多くの場合、インターフェースは進化する必要があり、相手側で指定されていないデータを受信することになります。単純な実装では、受信したデータが仕様に厳密に従っていない場合、連携を拒否します。より高度な実装では、認識しないデータを無視して、引き続き機能します。
連携するサービスは、相互のインターフェースに依存します。多くの場合、インターフェースは進化する必要があり、相手側で指定されていないデータを受信することになります。単純な実装では、受信したデータが仕様に厳密に従っていない場合、連携を拒否します。より高度な実装では、認識しないデータを無視して、引き続き機能します。
連携するサービスは、相互のインターフェースに依存します。多くの場合、インターフェースは進化する必要があり、相手側で指定されていないデータを受信することになります。単純な実装では、受信したデータが仕様に厳密に従っていない場合、連携を拒否します。より高度な実装では、認識しないデータを無視して、引き続き機能します。
サービスを進化させるには、プロバイダーが新しい要求をサポートするために変更を加えることができるようにする必要があります。その際に、既存のクライアントへの破損を最小限に抑える必要があります。

なぜ

サービスを進化させるには、プロバイダーが新しい要求をサポートするために変更を加えることができるようにする必要があります。その際に、既存のクライアントへの破損を最小限に抑える必要があります。
サービスを進化させるには、プロバイダーが新しい要求をサポートするために変更を加えることができるようにする必要があります。その際に、既存のクライアントへの破損を最小限に抑える必要があります。
サービスを進化させるには、プロバイダーが新しい要求をサポートするために変更を加えることができるようにする必要があります。その際に、既存のクライアントへの破損を最小限に抑える必要があります。

方法

コマンドやデータを他のマシン（または同じマシンの他のプログラム）に送信するコードは、仕様に完全に準拠する必要がありますが、入力を受け取るコードは、意味が明確である限り、準拠しない入力を受け入れる必要があります。
コマンドやデータを他のマシン（または同じマシンの他のプログラム）に送信するコードは、仕様に完全に準拠する必要がありますが、入力を受け取るコードは、意味が明確である限り、準拠しない入力を受け入れる必要があります。
コマンドやデータを他のマシン（または同じマシンの他のプログラム）に送信するコードは、仕様に完全に準拠する必要がありますが、入力を受け取るコードは、意味が明確である限り、準拠しない入力を受け入れる必要があります。
コマンドやデータを他のマシン（または同じマシンの他のプログラム）に送信するコードは、仕様に完全に準拠する必要がありますが、入力を受け取るコードは、意味が明確である限り、準拠しない入力を受け入れる必要があります。

リソース

制御の反転

制御の反転は、「ハリウッドの原則」とも呼ばれ、「こちらから電話はしない、
向こうから電話してくる」というものです。これは、コンピュータプログラムの
カスタムで書かれた部分が、汎用的なフレームワークから制御の流れを受け取る
設計原則です。制御の反転は、再利用可能なコードと問題固有のコードが、
アプリケーション内で連携して動作するにもかかわらず、互いに独立して
開発されるという強い意味合いを持ちます。

なぜ

制御の反転は、プログラムのモジュール性を高め、拡張可能にするために使用されます。
タスクの実行を実装から分離するため。
モジュールを、設計されたタスクに集中させるため。
モジュールが、他のシステムがどのように動作するかについての前提をなくし、
代わりに契約に依存するようにするため。
モジュールを置き換える際の副作用を防ぐため。
ファクトリーパターンを使用する

方法

サービスロケーターパターンを使用する
依存性注入を使用する
コンテキスト化されたルックアップを使用する
テンプレートメソッドパターンを使用する
ストラテジーパターンを使用する
Wikipediaの制御の反転

リソース

凝集度の最大化

形成する度合いであり、凝集度が高いほど優れています。
モジュールを理解するのが難しくなる。

なぜ

ドメイン内の論理的な変更が複数のモジュールに影響を与え、あるモジュールでの
変更が関連するモジュールでの変更を必要とするため、システムの保守が
難しくなる。
ほとんどのアプリケーションはモジュールによって提供されるランダムな操作のセットを
必要としないため、モジュールの再利用が難しくなる。
単一の責任を共有する関連機能をグループ化します（例：クラス内）。

方法