The Single Responsibility Principle (Tek Bir Sorumluluk İlkesi)

Ana Sayfa Blog The Single Responsibility Principle (Tek Bir Sorumluluk İlkesi)

The Single Responsibility Principle (Tek Bir Sorumluluk İlkesi)

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.

Sinan Eldem

Fullstack Web Developer

Laravel Framework ile PHP ve MySQL üzerine özel ders, danışmanlık ve web programcılığı hizmetleri veriyorum.

Danışmak istedikleriniz ile ilgili benimle irtibat kurabilirsiniz.

Benzer Yazılar

macOS, CentOS ve Ubuntu Üzerinde PostgreSQL Kurulumu ve Türkçe Karakter Hatasının Giderilmesi

Bu makalede macOs, Centos ve Ubuntu üzerine kurulumu, kullanıcı (rol) ve veritabanı oluşturulmasına ilişkin komutları bulacaksınız.

Open–Closed Principle (Açık/Kapalı İlkesi)

Bir uygulamanın ömrü boyunca, sürekli olarak sıfırdan yeni özellikler eklemekten ziyade mevcut kod temeline ekleme yapmak için daha çok zaman harcanır.

Liskov Substitution Principle (Liskov İkame İlkesi)

Bu ilke, bir soyutlamanın herhangi bir implementasyonunu o soyutlamayı kabul eden her yerde kullanabileceğinizi ifade eder ama bunu biraz basitleştirelim.

Yorumlar