1. SOLID原則を学んでいます
2. まずはInterfaceから
3. いよいよ依存性反転の原則

SOLID原則を学んでいます

「Software Design (ソフトウェアデザイン) 2023年6月号 [雑誌]」という雑誌に出会ったので、SOLID原則を学習中です。これを機に3流プログラマーに慣れたらいいなぁと。

前回の学習内容はこちら

[getpost id=”1332″ cat_name=”1″ date=”0″]

まずはInterfaceから

PHPにおけるInterface（インターフェース）は、クラスが実装するべきメソッドのシグネチャ（メソッド名、引数、戻り値の型）を定義するための機能です。

Interfaceは抽象的なクラスであり、実際の実装を持ちません。
(じゃあいらんやん…って思っちゃいますよね)

なぜ必要なのかというと、
クラスはInterfaceを実装することで、そのInterfaceで定義されたメソッドを必ず実装しなければならないからです。

例えば、ユーザーにメッセージを送信する場面を考えて下さい。

どの様なメッセンジャーを使うにしても必ず「メッセージを生成する機能」と「メッセージを送信する機能」の2つが必要になるはずです。

ここではメールで送信する場合(メールクラス)とLineで送信する場合(Lineクラス)を想定してみます。

interfaceを以下のように定義することで、実装したクラスはinterfaceの内容を必ず実装しなければいけません。

interface Message {
    public function createMesseage();
    public function sendMessage();
}

上記の様に定義することで、メールクラスとLineクラスは必ず同じメソッドがある事が担保されます。(クラスは同じ振る舞いを持つことが保証されます)

仮にSlackでメッセージを送信したい場合、Slackクラスに同じメソッドを実装するだけで済むため拡張性が高くなりますよね。あら、わかりやすい。笑
(既存のクラス(メールクラス、Lineクラス)に影響なく実装できる)

class Mail implements Message {
    public function createMessage() {
        //処理    
    }

    public function sendMessage() {
        //処理   
    }
}

class Line implements Message {
    public function createMessage() {
        //処理    
    }

    public function sendMessage() {
        //処理   
    }
}

interface Message {
    public function createMessage() {}
    public function sendMessage() {}
}

いよいよ依存性反転の原則

一旦、呼び出し元の観点を持ってみましょう。

interfaceを実装することで、呼び出し元のコードはinterfaceに対して依存し、具体的な実装クラスに対して依存しないためコードの結合が低くなります(疎結合。。。)

先程のコードで考えると呼び出し元はメールクラスを呼び出しているつもりでもinterfaceを経由しているのが実態です。

Interfaceを使用することで、クラス間の依存関係を抽象化し、実装にではなくインターフェースに依存するようにすることができます。

• 呼び出し元の見ているところがinterfaceになる
• interfaceは定義する場所
• interfaceを継承したクラスは必ず同じメソッドある
• 結果、呼び出し元と実装クラスはinterfaceに依存している

これにより、依存性反転原則が達成されます。

ちゃんちゃん。

1. 先輩から雑誌を渡された
2. SOLID原則を簡単に
3. 単一責任の原則

先輩から雑誌を渡された

これから設計に関する知識も増やしていきたいな〜と思っていた矢先、「Software Design (ソフトウェアデザイン) 2023年6月号 [雑誌]」という書籍に出会いました。中々嬉しいタイミングですね！笑

いわゆるクリーンアーキテクチャに関する内容が紹介されている雑誌になります。

今回はシリーズ形式で各記事に分けて書いていこうと思います〜！

SOLID原則を簡単に

1. 単一責任の原則 (Single Responsibility Principle, SRP)
2. オープン/クローズドの原則 (Open/Closed Principle, OCP)
3. リスコフの置換原則 (Liskov Substitution Principle, LSP)
4. インターフェース分離の原則 (Interface Segregation Principle, ISP)
5. 依存性逆転の原則 (Dependency Inversion Principle, DIP)

単一責任の原則

SRP : Single Responsibility Principle

一言で表すとクラスは単一の責務を持つべきということらしいです。

もっと噛み砕くと1つのクラスが1つの目的や責務にのみ集中するべきことを指します.

//良くない設計
<?php
class DB {
	private $host;
	private $dbName;
	private $userName;
	private $password;
	
	public function __construct($name, $email) {
		$this->host = env('host');
		$this->dbName = env('dbName');
		$this->userName = env('userName');
		$this->password = env('password');
		
		try {
			$database_handler = new PDO('mysql:host=' . $this->host . ':3306;dbname=' . $this->dbName . ';charset=utf8mb4', $this->userName, $this->password);
		} 
    	catch (PDOException $e) {   
        	echo $e->getMessage() . "\n";
        	exit;
    	}  
	}
	
	public static function selectUser() {
		$PDO = $db = new self();
		
		//取得処理	
	}
	
	public static function editAdmin() {
		$PDO = $db = new self();
		
		//編集処理	
	}
}
?>

上記のコードではDBクラスを定義しているのですが、ユーザーの取得処理と管理者の編集処理を記述しています。

理想とするクラス設計では、ユーザーのクラス/管理者のクラスという形で分けるべきですよね。↓

DB接続クラス

class DB {
	private $host;
	private $dbName;
	private $userName;
	private $password;
	
	public function __construct($name, $email) {
		$this->host = env('host');
		$this->dbName = env('dbName');
		$this->userName = env('userName');
		$this->password = env('password');
		
		try {
			$database_handler = new PDO('mysql:host=' . $this->host . ':3306;dbname=' . $this->dbName . ';charset=utf8mb4', $this->userName, $this->password);
		} 
    	catch (PDOException $e) {   
        	echo $e->getMessage() . "\n";
        	exit;
    	}  
	}
}

ユーザクラス（管理者も同様に）

class User {
	public static function selectUser() {
		$PDO = $db = new self();
		
		//取得処理	
	}

	//他のユーザーに関する処理を記述していく
}

良くないコード例として出したソースは以前の現場で書いていた手法なんですよね。笑
DBクラスの内容が1000以上になっていたので、拡張性や保守性がかなり良くない事が単一責任の原則を学んで理解できたので良しとしましょう。

ちなみに前の現場で書いていた内容はいつか爆発することは目に見えているのですが、爆破する前に逃げ出すことが出来ました。笑

[getpost id=”1204″ cat_name=”1″ date=”0″]