Skip to content

Interface Segregation Principle (Arayüz Ayrımı Prensibi)

4. Interface Segregation Principle

  • ISP, basit bir ifadeyle, bir sınıfın gereksiz yöntemlerle uğraşmak yerine yalnızca gerçekten ihtiyaç duyduğu yöntemleri bilmesi gerektiğini öne sürer.

  • Bu prensibi sade bir dil ile açıklamak için "Arayüzleri(Interface) küçük ve odaklı tutun" şeklinde düşünün.

  • Çok çeşitli yöntemler sağlayan büyük bir arabirime sahip olmak yerine, belirli ihtiyaçları karşılayan daha küçük arabirimlere sahip olmak daha iyidir.

  • İstemciler(Clients) yalnızca gereksinimleriyle ilgili arabirimlere bağlı olabileceğinden, bu, kodunuzdaki modülerliği ve esnekliği destekler.

  • Gerçek dünyadan bir Ödeme sistemi örneğini ele alalım. process_payment, refund_payment ve get_payment_status gibi fonksiyonlar sağlayan PaymentProcessor adlı bir interface olduğunu varsayalım. Ancak, sistemin farklı bölümlerinin farklı ihtiyaçları vardır. Örneğin, müşteriye yönelik bir modül, gelen ödemeleri işlemek için yalnızca process_payment yöntemine ihtiyaç duyarken, bir yönetici modülü, geri ödemeleri işlemek ve ödemelerin durumunu kontrol etmek için refund_payment ve get_payment_status fonksiyonlarına ihtiyaç duyabilir.

  • ISP'ye bağlı kalmak için arayüzü(interface) her bir modülün ihtiyaçlarına özel daha küçük arayüzlere ayırırız. Örneğin, müşteriler için yalnızca process_payment yöntemiyle bir PaymentProcessor arabirimi ve refund_payment ve get_payment_status yöntemleriyle yöneticiler için ayrı bir RefundProcessor arabirimi oluşturabiliriz. Her modül daha sonra gereksinimlerine uyan arabirime bağlı olabilir.

4.1 ISP ihlal

class PaymentProcessor:
    def process_payment(self, amount):
        # ...

    def refund_payment(self, transaction_id):
        # ...

    def get_payment_status(self, transaction_id):
        # ...
Yukarıdaki örnekte, tüm metodlar tek bir arayüzün(interface) parçasıdır. Bir modülün yalnızca ödemeleri işlemesi gerekiyorsa, refund_payment veya get_payment_status yöntemlerini kullanmasa bile içe aktarması ve tüm PaymentProcessor sınıfına bağlı olması gerekir. Bu, ISP'yi ihlal eder çünkü istemciler ihtiyaç duymadıkları yöntemlere bağımlı olmaya zorlanırlar.

4.2. ISP uygulama

class PaymentProcessor:
    def process_payment(self, amount):
        # Code to process the payment


class RefundProcessor:
    def refund_payment(self, transaction_id):
        # Code to refund the payment

    def get_payment_status(self, transaction_id):
        # Code to get the payment status
Bu örnekte arayüzü iki ayrı sınıfa ayırdık: PaymentProcessor ve RefundProcessor. İstemci modülleri artık ihtiyaç duydukları belirli arayüze bağlı olabilir. Örneğin, müşteri modülü PaymentProcessor sınıfını içe aktarabilir ve kullanabilirken yönetici modülü, RefundProcessor sınıfını içe aktarabilir ve kullanabilir. İstemciler yalnızca ihtiyaç duydukları yöntemlere bağlı olduğundan, bu ISP'ye bağlıdır.