Bu makalede SOLID prensiplerinin ilk maddesinden söz edeceğiz. "Neydi bu prensipler?" diye mi sordunuz, buyurun, özet makaleyi inceleyin.
Tek Bir Sorumluluk İlkesi bir sınıfın bir ve yalnız bir değiştirme sebebi olmasını belirtir. Diğer bir deyişle, bir sınıfın kapsam ve sorumluluğu dar odaklı olmalıdır. Sınıf sorumlulukları söz konusu olduğunda, cehalet mutluluktur. Bir sınıf kendi işini yapmalıdır ve bağımlılıklarından birine yapılan değişikliklerden etkilenmemelidir.
Aşağıdaki sınıfı ele alalım:
class OrderProcessor {
public function __construct(BillerInterface $biller)
{
$this->biller = $biller;
}
public function process(Order $order)
{
$recent = $this->getRecentOrderCount($order);
if ($recent > 0)
{
throw new Exception('Duplicate order likely.');
}
$this->biller->bill($order->account->id, $order->amount);
DB::table('orders')->insert([
'account' => $order->account->id,
'amount' => $order->amount;
'created_at' => Carbon::now();
]);
}
protected function getRecentOrderCount(Order $order)
{
$timestamp = Carbon::now()->subMinutes(5);
return DB::table('orders')
->where('account', $order->account->id)
->where('created_at', '>=', $timestamps)
->count();
}
}
Yukarıdaki sınıfın sorumlulukları nedir? Açıkçası, adı onun sipariş işlemeden sorumlu olduğunu ima ediyor. Fakat, getRecentOrderCount metoduna dayalı olarak, onun ikilenmiş siparişleri tespit etmek için ilgili hesabın veritabanındaki sipariş geçmişini incelemekten de sorumlu olduğunu görebiliyoruz. Bu ekstra validation sorumluluğu, veri depomuzu değiştirdiğimiz takdirde, ayrıca sipariş validation kurallarımızı değiştirdiğimiz zaman sipariş işleyici sınıfı da değiştirmemiz gerekmesi demektir.
Bu sorumluluğu OrderRepository gibi başka bir sınıfa çıkartmalıyız:
class OrderRepository {
public function getRecentOrderCount(Account $account)
{
$timestamp = Carbon::now()->subMinutes(5);
return DB::table('orders')
->where('account', $account->id)
->where('created_at', '>=', $timestamp)
->count();
}
public function logOrder(Order $order)
{
DB::table('orders')->insert([
'account' => $order->account->id,
'amount' => $order->amount;
'created_at' => Carbon::now();
]);
}
}
Daha sonra, onu OrderProcessor içine enjekte ederek, OrderProcessor'ı bir hesabın sipariş geçmişini yeniden araştırma sorumluluğundan kurtarabiliriz:
class OrderProcessor {
public function __construct(BillerInterface $biller,
OrderRepository $orders)
{
$this->biller = $biller;
$this->orders = $orders;
}
public function process(Order $order)
{
$recent = $this->orders->getRecentOrderCount($order->account);
if ($recent > 0)
{
throw new Exception('Duplicate order likely.');
}
$this->biller->bill($order->account->id, $order->amount);
$this->orders->logOrder($order);
}
}
Şimdi sipariş verisi toplama sorumluluklarımızı soyutlamış olduk ve sipariş elde etme ve günlüğe yazma metodu değiştiği zaman artık OrderProcessor'ı değiştirmek zorunda olmayacağız. Sınıf sorumluluklarımız daha odaklı ve dardır, bu daha temiz, daha anlamlı bir kod ve daha sürdürülebilir bir uygulama sağlar.
Tek Bir Sorumluluk ilkesinin sadece daha az kod yazmakla ilgili olmadığını, dar bir sorumluluğu ve birleştirici bir metodlar kümesi olan, böylece bir sınıftaki tüm metodların sınıfın genel sorumluluğu ile uyumlu olduğundan emin olunacak sınıflar yazılmasıyla ilgili olduğunu aklınızda tutun. İyi tanımlanmış sorumlulukları olan küçük, temiz sınıflardan oluşan bir kitaplık inşa edilmesinden sonra, kodumuz daha ayrışık, test edilmesi kolay ve dostça değiştirilebilir olacaktır.
