hkucuk

SOLID - Interface Segregation Principle

25 Mayıs 2022 • ☕️ 5 dk okuma • 🏷 bilgisayar, yazılım

Yazar tarafından şu dillere çevrildi: English


“Interface Segregation Principle” (ISG) veya “Ara Yüz Ayrımı Prensibi”, yazılım tasarımında kullanılan bir prensiptir. Bu prensibe göre, bir arayüzün mümkün olduğunca özelleştirilmiş olması gerektiği ve arayüzlerin sadece kullanılan özelliklerini içermesi gerektiği söylenir. ISG, kullanılmayan veya gereksiz özelliklerin bulunmadığı, yalnızca ihtiyaç duyulan özelliklerin bulunduğu arayüzler oluşturarak yazılımın esnekliğini arttırmayı amaçlar.

Bu prensip, yazılım tasarımındaki bağımlılıkları azaltmak için kullanılır. Bir arayüzde çok fazla özellik varsa, bu özelliklerin kullanılmadığı yerlerde bile gereksiz kod karmaşıklığı oluşturabilir. Bunun yanı sıra, bu özelliklerin biri değiştiğinde, bu değişiklik arayüzü kullanan tüm sınıfları etkileyebilir. ISG, bu sorunları önlemek için her arayüzün mümkün olduğunca özelleştirilmiş olması ve yalnızca ihtiyaç duyulan özellikleri içermesi gerektiğini söyler.

Bu prensibin avantajları arasında yazılımın daha esnek, bakımının daha kolay ve değişikliklerin daha az maliyetli olması sayılabilir. Ayrıca yazılımın daha anlaşılır ve daha az karmaşık hale gelmesi de mümkündür.

ISG, özellikle büyük yazılım projelerinde kullanışlıdır. Bu projelerde, farklı geliştiriciler farklı modülleri yazabilirler. Bu modüller, birbirleriyle iletişim kurmak için arayüzleri kullanırlar. ISG, arayüzlerin küçük, özelleştirilmiş ve bağımsız olmasını sağlayarak, bu modüllerin birbirinden bağımsız olarak geliştirilmesine olanak tanır.

Sonuç olarak, ISG, yazılım tasarımında kullanılan önemli bir prensiptir. Bu prensip, yazılımın esnekliğini arttırır, bakımını kolaylaştırır ve değişikliklerin maliyetini azaltır. Ayrıca, büyük yazılım projelerinde farklı geliştiricilerin birbirinden bağımsız olarak çalışmasını kolaylaştırır.

PHP’de, Interface Segregation prensibini uygulamak için aşağıdaki gibi bir örnek verilebilir:

interface PaymentInterface {
    public function processPayment();
    public function refundPayment();
    public function holdPayment();
}

class CreditCardPayment implements PaymentInterface {
    public function processPayment() {
        // Kredi kartı ödeme işlemi gerçekleştirme kodu
    }
    public function refundPayment() {
        // Kredi kartı geri ödeme işlemi gerçekleştirme kodu
    }
    public function holdPayment() {
        // Kredi kartı ödeme tutma işlemi gerçekleştirme kodu
    }
}

class PaypalPayment implements PaymentInterface {
    public function processPayment() {
        // PayPal ödeme işlemi gerçekleştirme kodu
    }
    public function refundPayment() {
        // PayPal geri ödeme işlemi gerçekleştirme kodu
    }
    public function holdPayment() {
        // PayPal ödeme tutma işlemi gerçekleştirme kodu
    }
}

Yukarıdaki kod örneğinde, PaymentInterface adlı bir arayüz tanımlanmıştır ve bu arabirim “processPayment”, “refundPayment” ve “holdPayment” adlı üç method içerir. CreditCardPayment ve PaypalPayment adlı sınıflar, PaymentInterface arabirimini uygulayarak bu yöntemleri kullanabilir.

Bu şekilde, PaymentInterface sadece ihtiyacımız olan üç methodu içerir ve bu methodlar yalnızca bu arayüzü kullanan sınıflar tarafından kullanılır. Bu, arayüzün gereksiz yöntemler içermediği anlamına gelir ve bu da arabirimlerin özelleştirilmiş ve ihtiyaç duyulan yöntemleri içerecek şekilde tasarlanmasına olanak tanır.

Aşağıdaki PHP kodu ise Interface Segregation prensibini ihlal eden bir sınıf örneğidir.

interface PaymentInterface {
    public function processPayment();
    public function refundPayment();
    public function holdPayment();
    public function verifyPayment();
    public function processRefund();
    public function notifyUser();
}

class CreditCardPayment implements PaymentInterface {
    public function processPayment() {
        // Kredi kartı ödeme işlemi gerçekleştirme kodu
    }
    public function refundPayment() {
        // Kredi kartı geri ödeme işlemi gerçekleştirme kodu
    }
    public function holdPayment() {
        // Kredi kartı ödeme tutma işlemi gerçekleştirme kodu
    }
    public function verifyPayment() {
        // Ödeme doğrulama kodu
    }
    public function processRefund() {
        // Geri ödeme işlemi gerçekleştirme kodu
    }
    public function notifyUser() {
        // Kullanıcıya bildirim gönderme kodu
    }
}

Yukarıdaki örnekte, PaymentInterface adlı bir arayüz tanımlanmıştır ve bu arayüz “processPayment”, “refundPayment”, “holdPayment”, “verifyPayment”, “processRefund” ve “notifyUser” adlı altı method içerir.

Ancak CreditCardPayment sınıfı yalnızca “processPayment”, “refundPayment” ve “holdPayment” yöntemlerini kullanırken, PaymentInterface arabirimi de diğer üç yöntemi içermektedir. Bu arayüzün gereksiz yöntemler içerdiği anlamına gelir ve bu gereksiz kod karmaşasına neden olabilir ve gelecekteki değişiklikler için kod değişikliğinin daha zor olmasına neden olabilir.

GoLang dilinde, Interface Segregation prensibini uygulamak için aşağıdaki gibi bir örnek verilebilir:

package main

import "fmt"

type Payment interface {
    processPayment()
    refundPayment()
    holdPayment()
}

type CreditCardPayment struct{}

func (cc *CreditCardPayment) processPayment() {
    fmt.Println("Kredi kartı ödeme işlemi gerçekleştirme kodu")
}

func (cc *CreditCardPayment) refundPayment() {
    fmt.Println("Kredi kartı geri ödeme işlemi gerçekleştirme kodu")
}

func (cc *CreditCardPayment) holdPayment() {
    fmt.Println("Kredi kartı ödeme tutma işlemi gerçekleştirme kodu")
}

type PaypalPayment struct{}

func (pp *PaypalPayment) processPayment() {
    fmt.Println("PayPal ödeme işlemi gerçekleştirme kodu")
}

func (pp *PaypalPayment) refundPayment() {
    fmt.Println("PayPal geri ödeme işlemi gerçekleştirme kodu")
}

func (pp *PaypalPayment) holdPayment() {
    fmt.Println("PayPal ödeme tutma işlemi gerçekleştirme kodu")
}

Yukarıdaki örnekte Payment adlı bir arayüz tanımlanmıştır ve bu arayüz “processPayment”, “refundPayment” ve “holdPayment” adlı üç yöntem içermektedir. CreditCardPayment ve PaypalPayment adlı sınıflar, Payment arayüzünü uygulayarak bu yöntemleri kullanabilir.

Bu şekilde Payment arabirimi yalnızca ihtiyacımız olan üç yöntemi içerir ve bu yöntemler yalnızca bu arabirimi kullanan sınıflar tarafından kullanılır. Bu, arayüzün gereksiz yöntemler içermediği anlamına gelir ve bu da arabirimlerin özelleştirilmiş ve ihtiyaç duyulan yöntemleri içerecek şekilde tasarlanmasına olanak tanır.

PHP örneğine benzer şekilde, aşağıdaki GoLang kodu da Interface Segregation prensibini ihlal eden bir örnektir.

package main

import "fmt"

type Payment interface {
    processPayment()
    refundPayment()
    holdPayment()
    verifyPayment()
    processRefund()
    notifyUser()
}

type CreditCardPayment struct{}

func (cc *CreditCardPayment) processPayment() {
    fmt.Println("Kredi kartı ödeme işlemi gerçekleştirme kodu")
}

func (cc *CreditCardPayment) refundPayment() {
    fmt.Println("Kredi kartı geri ödeme işlemi gerçekleştirme kodu")
}

func (cc *CreditCardPayment) holdPayment() {
    fmt.Println("Kredi kartı ödeme tutma işlemi gerçekleştirme kodu")
}

func (cc *CreditCardPayment) verifyPayment() {
    fmt.Println("Ödeme doğrulama kodu")
}

func (cc *CreditCardPayment) processRefund() {
    fmt.Println("Geri ödeme işlemi gerçekleştirme kodu")
}

func (cc *CreditCardPayment) notifyUser() {
    fmt.Println("Kullanıcıya bildirim gönderme kodu")
}

Yukarıdaki örnekte Payment adlı bir arayz tanımlanmıştır ve bu arayüz “processPayment”, “refundPayment”, “holdPayment”, “verifyPayment”, “processRefund” ve “notifyUser” adlı altı methodları içermektedir.

Ancak,CreditCardPayment sınıfı yalnızca “processPayment”, “refundPayment” ve “holdPayment” yöntemlerini kullanırken, Payment arabirimi de diğer üç yöntemi içermektedir. Bu, arayüzün gereksiz yöntemler içerdiği anlamına gelir ve bu, gereksiz kod karmaşasına neden olabilir ve gelecekteki değişiklikler için kod değişikliğinin daha zor olmasına neden olabilir.

Kaynaklar