Sınıf düzeyinde OCP uygulanması

Selam sana ey yazılım dostu!

Bir önceki OCP (Open-Closed Principle – Açık–Kapalı Prensibi) yazımda, söz konusu prensibi bir metoda uygulamıştım. Bu yazımda ise aynı prensibi, sınıf düzeyinde uygulayacağım.

Şimdi efendim, önce senaryomuzu oluşturalım. Projenizde bir ürün modeli ve bu modelden türeyen nesneleri barındıran bir koleksiyonunuz var. Dilerseniz önce bu modeli oluşturalım sonra senaryomuza devam edelim.

Şimdi bu ürün modelinden türeyen nesneleri barındıran bir koleksiyonda, belli kriterlere uygun aramalar yapmak istiyorsunuz. Haliyle SRP standartlarına göre, bu işi yapmak üzere bir sınıf oluşturdunuz. İlk olarak, müşteriniz bu ürünler üzerinde renk kriterine göre bir arama yapacağını belirtti. Siz de doğal olarak sınıfınızı bu talep üzerine inşa ettiniz.

Sorun yok gibi duruyor değil mi? Peki. Müşteriniz sizden bir görüşme daha talep etti ve şöyle dedi: “Yahu biz düşündük taşındık ve ürün boyutuna göre de arama yapmamız gerektiğine karar verdik”. Siz de “tamam canım. Alt tarafı bir metot daha ekleyeceğiz” şeklinde yanıt verdiniz. Öyleyse yeni sınıfınız şöyle oldu:

Tam “hah. Şimdi oldu” derken müşterinizden şöyle bir e-posta aldınız: “Pşşt, yazılımcı hem boyut hem de renge göre arama yapabileceğimizi de unutma ha!”. Bu üslup sebebiyle önce biraz dişinizi sıktınız ve hoop bir metot daha eklediniz sınıfınıza:

Sanırım bir sorun olduğunu şimdi sezebiliyorsunuzdur. Bu analiz sorunlu müşteri (hayali müşterime kızdım resmen) size ne zaman yeni bir kriter bildirse UrunArama sınıfınıza yeni bir metot eklemek zorunda kalacaksınız. Oysa ne diyordu OCP? “Bir yazılımın tüm varlıkları (sınıf, modül, fonksiyon) gelişime AÇIK kod değişimine ise KAPALI olmak zorundadır.” Burada UrunArama sınıfı bu prensibe hiç ama hiç uymuyor!

Peki, ne yapacağız?

Ürün arama işlemini birden fazla kriterle yapmamız gerekiyorsa; tüm bu kriterleri abstract bir sınıftan türetebiliriz demek ki. Böylece, polymorphism’in güzelliklerinden faydalanarak geliştirilebilir ama değiştirilemez bir UrunArama sınıfı yapabiliriz. İşte o abstract sınıf geliyor:

Her kritere göre ürün arama yapabileceğimiz için “UrunAra” isminde ortak bir metodumuz olacak. Fakat arama işlemi, bu sınıftan türeyen sınıfların sorumluluğunda olmalı. O nedenle protected Acces Modifier’ına sahip abstract bir ara() metodumuz daha var.

Madem bu sınıfı hazırladık o halde, kriterlerimizi de oluşturmaya başlayalım artık. İlk olarak renge göre filtrelemeden sorumlu sınıfımızı yazalım.

Gördüğünüz gibi, RengeGoreArama sınıfından nesne üretirken, geliştiriciyi bir renk değeri bildirmeye zorluyorum (constructor). Ardından bu değeri kullanarak arama işlemini gerçekleştiriyorum.

Aynı şekilde, Boyuta göre ve hem Boyuta hem de Renk’e göre filtreleme yapabilecek sınıflarımı da oluşturabilirim artık.

Efendim gördüğünüz gibi, müşterinin ihtiyaç duyduğu her filtreleme işlemi için yeni bir sınıf oluşturarak projemi genişletilebilir bir hale getirdim (OPEN). Peki, bunu niçin yapmıştık? UrunArama sınıfının kodunu bir daha değiştirmeye ihtiyaç duymamak için (CLOSED). Öyleyse sınıfa son şeklini verelim.

İşte bu! UrunArama sınıfına “başka bir metot eklemenize gerek kalmadan” müşterinizin tüm kriterlerine uygun arama yapabileceksiniz artık! Hadi bu sınıfı kullanalım şimdi.

İşte sevgili dostlarım, nesne yönelimli tasarımın prensiplerinden Open-Closed prensibi ile ilgili bir örneğimizi de tamamlamış bulunuyoruz. Bir sonraki yazımızda görüşmek dileğiyle…

Hoşça kalın.