SOLID原則について
SOLID原則とは
- SRP(単一責任の原則)
- OCP(オープン・クローズドの原則)
- LSP(リスコフの置換原則)
- ISP(インターフェース分離の原則)
- DIP(依存関係逆転の原則)
の頭文字を取ったものである。
なぜSOLID原則？
SOLIDを適用する理由として、
- 変更に強くなる
- 理解しやすくなる
- 多くのソフトウェアシステムで利用できること
が挙げられます。
以下から、各原則の説明、コードについて触れていきます。
SOLIDの各原則について
SRP(単一責任の原則)
###説明
1つのモジュールやクラス、関数などを変更する際に、理由が複数あってはいけないという原則
理由としては以下のような事象が起きることを防ぐため
- 複数の人が一つのソースファイルを変更した際に、マージやコンフリクトが発生
- 変更した内容が予期しないところに影響を受ける
コード
悪い例
一つのインタフェースで従業員の管理、従業員のデータの保存と複数の責務を負っている。
type EmployeeWorkManage interface {
calculatePay()
reportHours()
saveEmployee()
}
####改善後
従業員の管理、従業員のデータの保存のインターフェースを分けて作成して、責務をそれぞれ1つになるようにする。
type EmployeeWorkManage interface {
calculatePay()
reportHours()
}
type EmployeeDataManage interface {
saveEmployee()
}
OCP(オープン・クローズドの原則)
###説明
ソフトウェアの拡張に対して開いていて、修正に対して閉じてなければならないという原則
そうすることで変更の影響を受けずにシステムを拡張できる。
コード
Animalというインターフェイスを作成して、それに依存した形で、Dog型やCat型のメソッドを作成することによって、mainの処理ではDog型やCat型を気にせずに、barkメソッドを実行できる。
また新しくBirdを作りたい場合でも、Animalのインターフェースに依存した作りにすることによって追加だけで済む。
package main
import(
"fmt"
)
type Animal interface {
bark()
eat()
}
type Dog struct {}
type Cat struct {}
func (d Dog) bark(){
fmt.Println("ワンワン")
}
func (d Dog) eat(){
fmt.Println("バクバク")
}
func (c Cat) bark(){
fmt.Println("にゃー")
}
func (c Cat) eat(){
fmt.Println("ムシャムシャ")
}
func main(){
dog := Dog{}
cat := Cat{}
animals := []Animal{dog, cat}
for _, animal := range animals {
animal.bark()
}
}
LSP(リスコフの置換原則)
###説明
S型のオブジェクト :o1
T型のオブジェクト: o2
がある時に、Tを使って定義されたプログラムPに対して、o2の代わりに、o1を使ってもPの振る舞いが変わらない場合、SはTの派生型であるという原則
コード
Goには継承がないため、リスコフの置換原則に違反することがなく意識されない（？）
ISP(インターフェース分離の原則)
###説明
不要なインターフェースに依存することを強制してはいけないという原則
関連のあるインターフェースだけをグループ化、利用しないメソッドの依存を失くす。
コード
悪い例
以下のようなAnimalInterfaceから人間型を作ろうとすると、使用しないflyメソッドまで記述をしないといけなくなる。
type AnimalInterface interface {
fly()
run()
swim()
}
####改善後
鳥だったらBirdInterface、人間だったらHumanInterfaceとインターフェースを分けるようにする。
そうすることによって不要なメソッドを記述せずに済む。
type BirdInterface interface {
fly()
}
type HumanInterface interface {
run()
swim()
}
type Bird struct {}
type Human struct{}
func (b Bird) fly(){
fmt.Println("飛びます！！")
}
func (h Human) run(){
fmt.Println("走るぞ〜")
}
func (h Human) swim(){
fmt.Println("泳ぎます〜")
}
func main(){
bird := Bird{}
human := Human{}
bird.fly()
human.run()
}
DIP(依存関係逆転の原則)
###説明
頻繁に変更されている具象モジュール（関数の実装が書かれているモジュール）に依存してはいけない原則
変更しやすい具象への依存を避け、安定した抽象インターフェースに依存する。
Abstract Factoryパターンを利用して、抽象インターフェイスを参照するようにする。
コード
Abstract Factoryに依存することによって、依存先が図のようなイメージになり、DBかテキストどちらかを気にせずに、ユーザのデータを取得できるようになる。
package main
import(
"fmt"
)
type User struct {
id int
name string
}
type AbstractFactory interface {
getData() User
}
type DbManage struct {}
func (db DbManage) getData() User {
return User{1, "DB TARO"}
}
type TextManage struct {}
func (text TextManage) getData() User {
return User{2, "TEXT JIRO"}
}
func getUserData(manageType string) User {
var manageFactry AbstractFactory
switch manageType {
case "DB":
manageFactry = DbManage{}
return manageFactry.getData()
case "TEXT":
manageFactry = TextManage{}
return manageFactry.getData()
default:
return User{3, "名無し"}
}
}
func main(){
user := getUserData("DB")
fmt.Println(user.id, user.name)
}
参考
https://labs.septeni.co.jp/entry/2017/02/21/164127
https://maroyaka.hateblo.jp/entry/2017/05/22/165355
https://qiita.com/shunp/items/646c86bb3cc149f7cff9
https://golangvedu.wordpress.com/2017/01/31/golang-design-pattern-abstract-factory-and-factory-method/
最後に
なんとなくですが、SOLID原則について分かったような気がします。
質問やご指摘がございましたら、コメントに書いていただけると幸いです。