開発原則とは？

オブジェクト指向における原則を示すものであり、主義や格言の頭字語を取った呼び名である。
ソフトウェア開発において、これから紹介する原則を守ることでコードの品質、可読性、拡張性が向上し、プロジェクトの長期的な成功へと導くことができるようになる。

原則について

・Single Responsibility Principle (単一責任原則)
クラスやモジュールは単一の責任を持つべきである。

動作を分離することで変更時の影響範囲が限定されるため、バグが発生した際に他の無関係な場所への影響を最小限に抑えることができるようになる。

・Open-Closed Principle (開放/閉鎖原則)
クラスの拡張(新規機能の追加)には開放されていて、変更には閉じられているべきである。

クラスやモジュールが、既存のコードを変更することなく、新しい機能を追加できるように設計すべきだという考え方。
既存のクラスが使用されている箇所でのバグを防ぐことができるようになる。

・Liskov Substitution Principle (リスコフの置換原則)
親クラスのインスタンスは子クラスで置き換え可能であるべきである。

子クラスは親クラスと同じ、あるいは同様の結果を提供できるようにすることで、一貫性を保つことをことができる。

・Interface Segregation Principle (インターフェース分離の原則)
クライアントが必要なメソッドのみを実行するべきである。

クラスが必要なもののみを実行するように不要なメソッドを削除、もしくは移動することで予期しないバグを避けることができるようになる。

・Dependency Inversion Principle (依存性逆転の原則)
上位クラスは、下位クラスに依存してはならない。
詳細は抽象化に依存するべきである。

クラスは動作を実行するために使用するツールと融合すべきではなく、ツールがクラスに接続できるようにするインターフェイスと融合すべきである。
上位レベルのクラスが下位レベルのクラスに依存するのを減らすことができるようになる。

Keep It Simple, Stupid
コードはできるだけシンプルにすべきである。

複雑すぎるコードはバグを引き起こしやすく、保守が困難になる。
プログラミングをする際に、「動作させるために、もっともシンプルなものは何か」と常に問いかけることが必要である。

You Aren't Gonna Need It
いま必要なコードのみ追加するべきである。

あらかじめ備えてコードを盛り込むことは、余計な複雑性を盛り込んでしまい邪魔になる可能性がある。
汎用性よりも単純性を求め、「今」必要なものだけを実装する。

Don't Repeat Yourself
同じコードは避けるべきである。

同じコードが複数あることで、量が多くなり、修正にかかる時間やコードの理解にも時間を要するようになる。
処理のまとまりには関数化するなどを行い意義していくことが重要である。