Gerçek dünyada, bir uygulama geliştirme sürecinde veya sonrasında, sürekli müşterilerimizden yeni istekler ve güncelleme talepleri gelmektedir.
Bu gelecek olan isteklerin sistemimize rahatlıkla entegre olabilmesi veya kolaylıkla genişletilebilmesi için (günümüzde zaman artık çok değerli bir kıstas olduğu için) uygulamamızı gelişime açık, değişime kapalı bir şekilde geliştirmeliyiz. Genelde uygulamalarımız üzerinde değişiklik veya güncellemeler kaçınılmaz bir gerçektir. Her ne kadar ileriye dönük esnek (Extendability) bir tasarım oluşturursak, karşımıza gelecek olan isteklerin sistemimize uygulanabilirliğini, kara kara düşünmeden işleme koyabilmemizi sağlar.
Konunun daha iyi anlaşılabilmesi açısından, en güzel bulduğum ve zamanında benimde anlayabilmem açısından en iyi olan örnek üzerinden gideceğim.
Örneğimizde Rectangle(Dikdörtgen) isminde bir class’ımız mevcut ve bu class’ımız Width ve Height property’lerine sahip. Birde AreaCalculator isminde bir class’ımız ve burada Area isminde bir metot ile Rectangle tipinde bir dizi alarak basit bir şekilde alanlarını hesaplıyoruz.
Evet her şey oldukça güzel görünüyor değil mi? Rectangle’ın alanını hesaplayabiliyoruz. Peki müşterimizden gelen bir istek ile Circle(Daire)’ında alanını hesaplamak istediğini belirtti bize.
Aklımıza gelen ilk şey olarak artık Rectangle tipinde bir dizi yerine object tipinde dizi tanımlayarak bunu da ufak bir if else bloğuna sokarak bir type kontrolü ile halledebiliriz sanırım…
Hemen kodumuzun son haline bir bakalım:
Şuan için yine oldukça güzel duruyor 🙂 Sanırım müşterimizin isteğini yerine getirmiş olduk ve artık Circle’ın da alanını hesaplayabiliyoruz.
Her şey güzel gidiyor derken müşterimizden gelen bir haber ile tekrar bir yeni isteği olduğunu belirtiyor. Bu seferde Triangles (Üçgen) için bir alan hesaplamak istiyor. Elbette bunu hesaplamak çok zor değil fakat yine kodumuzda değişiklikler gerekiyor.
Git gide open-closed’a karşı bir yapı kuruyoruz. Gelişime açık, değişime kapalı olmamız gerekirken sürekli kodumuzu değiştiriyoruz. Bu duruma hemen open-closed prensibine uygun bir yaklaşımla bakarsak AreaCalculator class’ımız değişime kapalı değildir aksine yeni istek için sürekli değiştirmemiz gerekmektedir. Aslında olaya developer olarak bakarsak, kendi kendimize bir ek iş çıkarıyoruz burada 🙂
Evet şimdi open-closed prensibine göre bu class’ımızı gelişime bir açalım ve bize neler katabilecek bir bakalım hemen.
Öncelikle OOP’in güzelliklerinden yararlanarak hemen Shape isminde bir abstract class oluşturarak bu class ile şekli soyutlayıp istediğimiz tipte türetebileceğiz. Her birinin kendi alan hesaplama formülü bulunacak. Bu şekilde bir yaklaşımla metodumuzu gelişime açık, değişime kapalı olarak belirlemiş olduk.
Hemen kodun son haline bakacak olursak:
Artık her ne kadar farklı hesaplama ve şekil isteği gelse de biliyoruz ki bizim için farketmez, kolaylıkla metodumuzu genişletebiliriz.
Bir makalenin daha sonuna geldik, umarım faydalı olabilmişsem ne mutlu bana.
Takipte kalın… 🙂
[…] Open Closed prensibinden sonra vermiş olduğum uzun bir aranın arından sıradaki prensibimiz olan Liskov’un yerine geçme prensibi (Liskov Substitution Principle) ile makalemize devam edelim. […]