Design Patterns - Decorator Pattern

Merhaba arkadaşlar,

Sizlerle beraber yaptığımız tasarım desenleri derslerimizin bugünkü konusu en çok bayanların hoşuna gideceğini düşünüyorum :). Bugün dekorasyon tasarım desenini anlatmaya çalışacağız.

Dekorasyon konumuza girmeden önce en son yazdığımız yazının kısa bir özetini geçelim. En son yazımızda singleton tasarım deseninden bahsetmiştik. Singleton tasarım deseni ile şunları yapmayı hedefliyoruz:

• Bir uygulamanın yaşamı boyunca kullandığı bir sınıfın örneğinin tekil olunmasının istenmesi
• İstenilen bu örneğin uygulamanın her noktasından erişiminin sağlanması

Singleton tasarım deseni en basit tasarım deseni olarak gözükmesinin nedeni az kod yazılması ve konunun anlaşılırlığının basit olmasından kaynaklanıyor.

Konumuza gelicek olursak dekorasyon kelimesi dilimize fransızcadan geçmiştir. Fransızca da décoration olarak geçmektedir. Dekor etme, süsleme gibi anlamı vardır.

Yukarıda gösterilen güzel araba konumuza çok güzel örnek olacağını düşünüyorum :).

Bizim yapımız da ise nesneleri süslenmesi ve yeni özelliklerinin eklenmesi gibi düşünebilirsiniz. Yukarıda gösterilen şahin arabamızı da(emin değilim doğan da olabilir :) ) süsleme işlemini yapacağız.

Dekorasyon tasarımımız da 4 adet nesne tipi olacaktır. Bunlar aşağıdaki gibidir:

• Component: Dinamik olarak sorumluluklar ekleyebileceğimiz sınıfa sunulan arayüz veya abstract sınıftır.
• ConcreteComponent: Sorumluluk ekleyeceğimiz asıl nesnemizdir
• Decorator: Dekorasyon işlemlerinden sorumlu, değişik dekorasyon şekillerinin üst sınıfıdır. Değişik dekorasyon şekillerini desteklemek için abstract class veya interface olarak tasarlanır.
• ConcreteDecorator: Dekorasyon işleminin özelliğini barındıran asıl nesnelerdir.

Şimdi konumuzu anlatan uml diagramımıza bir bakalım.

Şimdi ne yaptığımıza bir bakalım. Öncelikle dekorasyonu uygalayacağımız sınıf olan Sahin isimli sınıfımızı görüyorsunuzdur. Sahin nesnemizin özelliklerini dinamik olarak değiştirmek için abstract classtan türettik.

Sahin arabamıza yeni özellikler katacağımız CarDecorator sınıfımızın uml diagramına baktığımızda Car sınıfından türetilmiş ve içinde car sınıfının örneğini barındırdığını görüyoruz. Buradaki amaç modifiye edilmek istenilen aracın dekorasyon sınıfı tarafından sarmalanıp yeni özellikleri de bu sınıftan türeyen dekorasyon sınıflarına bırakılmasıdır.

Biz kapıları geriye doğru açılan bir modifiye olmasını istedik. Bunun için CarDecorator sınıfımızdan SuicideDoorDecorator sınıfını türetti ve yeni özellikler ekledik. Uygulamamızın kodları da aşağıdaki gibi olacaktır.

Uygulamanın Başlangıç Sınıfı

Base Sınıf

Dekorasyonların dinamik olarak uygulanması için türetilen sınıftır.

Sahin arabamız :)

Dekorasyon uygulanacak sınıfımız.

Dekorasyon işlemlerine base olacak sınıfımız.

ve gün sonunda olacak kapı dekorasyon sınıfımız yukarıdaki gibidir.

Kodlara baktığımız zaman, dekorasyon tasarım deseninin amacının nesneye yeni özellikler katmak olduğunu anlayabiliriz.

Bir yazımızın daha sonuna geldik. Bir sonraki yazımız da görüşmek üzere....

Design Patterns - Singleton Pattern

Merhaba arkadaşlar,

Uzun bir zamanın ardından yeniden sizlerle birlikte yeni bir konu üzerinde konuşacağız. Blog ile aramın soğumasını önlemek için bugün sıcak bir güneş resmi ile başlangıç yapmak istedim(Anlatacağım konu da da güneşi örnek vericem :Pp).

 

Bir şeyler yapıcaz dedik ama aslında yaptığımız başka insanların yapmış olduğu çalışmaları öğrenmek olacak. Nereden bakarsak bakalım çok hoş olmamakla beraber şu an için elin gavurunun bilgisi bizimkinden önde gidiyor. Öyle kibir yapıpta yok ben öğrenmem, yok ben bilmem deyipte saçma sapan kendini beğenmişlik egosuna girmenin alemi yok gardaşım.

 

Biraz daha muhabbet edelim sonra konumuza başlarız inş. (Direk konuya girmek isteyen kırmızı renkli arkadaşlarımı aşağıdan başlamalarını tavsiye ediyorum :Pp Diğer renkler okumaya devam edebilir :))

 

Uzun bir ara oldu dedik. Nedenini kısaca şöyle bahsetmek gerekirse çalıştığım iş yerindeki organizasyonel değişiklikten dolayı başka bir birime geçiş yaptım. İyi mi oldu kötü mü oldu bilmiyorum ama ileriki dönemlerde daha çok yeni şey öğreneceğimi düşünüyorum inş.  "Tebdil-i mekanda ferahlık vardır" diye bir sözümüzü düşündükçe, bu değişiklikte beni motive ediyor.

 

Günümüz de iş yaşamı boyunca ortalam 10 iş değişikliğinin 2 sini farklı kurum birini kurum içi yaparak 3,5 sene içinde 3 değişiklik sayısına ulaştım. Kalan ömrümüz de ne yaparız bilmiyorum ama hakkımız da en hayırlısı olur inş.

 

Velhasıl hayat devam ediyor ve biz bugün kaldığımız yerden devam etmemiz gerekiyor. 

 

Bugünkü konumuz, tasarım desenlerinin en kolayı ama en güzeli (bana göre :P ) olan singleton tasarım desenini incelemeye çalışacağız.

 

Not: Diğer yazılarımızın başında bir önceki yazımızın özetini yazıyorduk. Uzun bir ara olduğu için özet yerine okumanızı tavsiye ediyorum :)

 .

Singleton kelimesi, tek, tekil gibi anlamlara geldiğini düşünüyorum inş. öyledir :) Singleton tasarım deseninin amacı bir uygulamanın ömrü boyunca belirli bir nesneden sadece bir tane olmasını garanti etmek ve buna her yerden erişimi sağlamaktır.

 

Tanımdan anladığınız gibi konu kulağa çok hoş geliyor. Belli bir sınıfımın örneğini uygulama boyunca sadece 1 kere oluşturulmasını sağlamak amacımız.

 

Giriş cümlem de yazdığım gibi benim uygulamam da bunu güneş ile anlatıcam. Bildiğiniz gibi güneş dünyanın hacminden 1,4122×10²⁷ m³  kadar büyük, çekirdek sıcaklığı ~15,7×10⁶ K   olan bir yıldızdır (O nasıl bir sıcaklıktır :| dini konulara girerdim ama konudan sapmayalım :Pp ). Detaylı bilgi için vikipediye bakabilirsiniz. 

 

Güneş samanyolu galaksisindeki herhangi yıldızdan bir tanedir. Güneşin uygulamamız da temsili olarak göstermek istersek heralde iki tane olması mantıklı gelmez (farklı güneşlerden bahsetmiyoruz bizim güneşimizden bahsediyoruz arada bir iki güzel arkadaşım bana göz kırpıyor gibi :)).

 

Biz de uygulamamız da güneşin kullanılmasını singleton tasarım deseni ile anlatmaya çalışacağız.

 

Yukarıda bahsettiğimiz gibi güneş sınıfından bir örneği uygulama boyunca tek olmasını ve her yerden erişimini sağlayacağız.

 

Multithread kullanılmayan sistemler için aşağıdaki birinci versiyonu inceleyelim.

Yukarıdaki kod bloğunu incelediğimiz de Sun sınıfının constructor metodunun private olduğunu görürüz. Bunun amacı Sun nesnesinin oluşturulmasını dışarıya açmamaktır. Dışarıya açtığımız da zaten nesneden birden çok üretilmesi anlamına gelir.

 

Private olarak tanımlanmış bir diğer alan da ise uygulama boyunca tekil olacak nesnemizin kendisi tutulur.

 

Sınıftan örnek istenildiğinde (GetSun methodu) _sun alanında tuttuğu değer null ise yeni bir örnek oluşturulak bu alana atanır. Daha önce oluşturulmuş ise alan da tutulan değer geri gönderilir.

 

Multithread uygulamalarımız da if bloğunu aynı anda iki farklı thread geçebileceği için birden çok nesnenin ortada gezmesine olanak sağlamış oluruz. Bu gibi durumlar da aşağıdaki kod bloğunu kullanibiliriz.

 

Yukarıdaki kod bloğumuzun ilkinden farklı olarak göze çarpan özelliği lock deyimi ve double check kontrolüdür. Lock deyimi aynı anda birden çok threadin bir kod bloğuna girmesini engeller. Double check ise şöyle açıklayabiliriz.

• İki thread aynı anda ilk if bloğuna geldi ve ikisi de alanın değeri olmadığı için içeri giriş yaptı (Matrix aklıma geldi birden :)).
• Bunlardan sadece birini lock bloğunun içerisine alındı.
• İkinci if bloğunda _sun alanın değeri olmadığı için birinci öncelikli thread içeri girerek nesneyi oluşturdu. İşini bitirdi gitti.
• İkinci thread lock bloğunun deaktif olmasından faydalanarak kod bloğunun içerisine girerek ikinci if bloğunda karşılaştırma yaptı. artık dolu olan _sun alanının karşılaştırmasında false değeri alarak oluşturulmuş _sun alanını kullanarak yoluna devam etti.

Dilim döndüğünce (yazarken bu deyim çok saçma oluyor) anlatmaya çalıştım. Kısacası bir nesneniz sizin için sanat güneşi ise :)) onun tek olmasını istiyorsanız bu nesnenin tasarımın da singleton tasarım desenini kullanabilirsiniz.

 

Oh sonuna gelebildik. Özlemişiz birşey yazmayı. Ne derece yazdıysak o derece öğrendiğimiz bu çalışmalar kendi içinde basit gözükse de çalışma hayatının olmazsa olmazı "Öğrendiğini uygulamalısın" prensibine çok güzel birer örnek oluyor.

 

Değerli vaktinizi ayırıp okuma zahmetinde bulunan herkese teşekkür ederim. Bir sonraki yazım da görüşmek üzere arkadaşlar...

Design Patterns - Adapter Pattern

Merhaba arkadaşlar,

 

Tasarım desenleri konumuza kaldığımız yerden devam ediyoruz. Bu yazımızda anlatacağımız konumuz adaptör deseni(Adapter Pattern) olarak geçiyor.

Konumuza geçmeden önce bir önceki yazımızı hatırlayalım.

Bir önceki yazımızda Abstract Factory Pattern incelemiştir. Bu desen bize seri nesne üretim yapan fabrikaları üreten üst bir yapıdan bahseder.

 

Konumuza dönersek Adaptör Tasarım ismi insana bir fikir verdiğini düşünüyorum. Adaptörler ne iş yapar diye düşünürsek, sisteme dışarıdan gelen girişleri sistemin anlayacağı şekile dönüştürür. Bu bize ne gibi kolaylık sağlar ? Sisteme girişlerinin standart olması sayesinde adaptörlerin değiştirilebilmesine imkan tanır.

 

Gerçek hayatta buna pek çok örnek var. Bilgisayar şarz cihazları, post cihazları, iett akbil basma cihazı gb.

 

Yazılım da örnek verelim. Hazır kütüphaneleri sistem de kullanırken, kütüphanelere bağımlı kalınmaması için araya adaptörler yazılabilir. Bugünkü örneğimiz de buna uygun şekilde yapalım. Loglama işlemi yapan hazır kütüphane ve kendi loglama mekanizmamızı sistemimize dahil etmeye çalışalım.

 

Uml diagramımıza bakalım.

Uygulamamız da 2 adet loglama yapan sınıf vardır. Bunlardan bir tanesi kendi yazdığımız Mylogger  sınıfımız ve diğeri ise Log4Net kütüphanesidir.

Uygulamamızın kodlarına bakacak olursak;

Adaptör Arayüzü

Log4Net Adaptörü

Kendi Log Kaydetme Sınıfımız

 

Loglama işlemini çağıran sınıf

Log4Net konfigürasyonu app.config

Not: Log4Net konfigürasyonu için assembly.cs sınıfına

[assembly: log4net.Config.XmlConfigurator(Watch = true)]
 satırını eklemeniz gerekmektedir. 

 

Yukarıdaki kodu incelersek prgram sınıfı önce kendi loglama mekanizmasını çağırarak loglama işlemini yapıyor. Daha sonra kullanmak istediği log4net loglama mekanizması için adaptörü kullanıyor.

 

Burada kod geliştirmek istesek başka ne yapılabilir diye düşündüğümüz de loglama mekanizmasını bir factory sınıfından alabiliriz. Bu şekilde üretme işlemini de sistemden soyutlamış oluruz.

 

Dikkat ettiyseniz eğer Log4Net'ten sistemimizi hala tam soyutlamadık. Program sınıfında ILog nesnesini static olarak tanımladık. Bu işlemi de fabrika sınıfında bir Dictionary koleksiyonu içinde tutabiliriz. Loglama işlemi için daha önce gelmeyen bir sınıfın ILog nesnesi oluşturulup koleksiyona ekleriz. Daha sonra gelen aynı sınıf loglama işlemleri için tekrar tekrar değişken tanımlamamıza gerek kalmaz.

 

Arkadaşlar yukarıdaki iki genişletme işlemini kendi sisteminizde deneyebilirsiniz. Bu şekilde pratik yapmış olursunuz(Yazılım dünyasında bir kodu anlamak ve unutmamak istiyorsak kesinlikle örneğini yapmalıyız :)).

 

Bir makalemizin daha sonuna geldik. Adaptör nesnesinin temel özelliği nedir diye sorarsak, bir sisteme monte edilecek farklı sistemler için arayüz oluşturmasıdır.

 

Yanlışlarımız varsa her zaman söylediğim gibi düzeltirseniz memnun olurum. Yazdıklarım bilmediklerimin yanında okyanusta damla gibi olduğunu biliyorum.

 

Okuyan gözlerine sağlık. Görüşmek üzere :)

 

Design Patterns - Abstract Factory Pattern

Merhaba Arkadaşlar,

 

Bu yazımızda Tasarım Desenleri serimize "Abstract Factory Pattern", Türkçe'si Soyut Fabrika Tasarımı'nı inceleyeceğiz. 

 

Yeni konumuza geçmeden önce bir önceki konumuzu hatırlayalım (Biz cahil insanlar olarak genelde yazdıklarımızı tekrar okumayız ve yazdığımız bilgileri unutmaya terkederiz).

 

Bir önceki konumuz da fabrika tasarımı incelemiştik. Türleri aynı olan ürünlerin tek bir yerden üretilmesini sağlayan bir çözümdü.

 

Soyut fabrika tasarımını anlamak için fabrika tasarımını iyi anlamamız gerekiyor. Soyut fabrika tasarımı fabrika tasarımında gerçekleşen ürün üretimi yerine ürünün üretildiği fabrikaları üretmeyi sağlar. Ne demek şimdi bu ? (Benim gibi bazı arkadaşlar ilk başta bunun anlamını anlamayabilir. Korkacak birşey yok arkadaşlar :))

 

Bir önceki örneğimiz de çikolata yapan fabrikadan bahsetmiştik. İstersek bu örnekten devam edebiliriz ama örnek çeşitliliği adına farklı bir örnek yapmanın daha iyi olacağı kanaatindeyim.

 

2 adet bilgisayar üretme fabrikamız olduğunu düşünelim. Bunların birbirini yiyen iki firma olsun mesela (çok düşünmeye gerek yok:)) Samsung ve Apple(Eşimin telefonu Apple benimki Samsung özgürlüğü tercih ettiğimi düşünüyorum :Pp). 

 

Biz Bir Laptop aldığımız da Laptopun kendisi ve çantası beraber geliyor. Bu fabrikaların amacı benim istediğim model laptop ve çantasını getirmesi. Samsung istiyorsam samsung laptop ve samsung çantam olsun  gb.

 

Bu kadar laf salatalığı yaptıktan sonra bir UML ile ne demek istediğimizi anlatalım.

 

Fabrika Sınıfları
 

Çanta Sınıfları

Laptop Sınıfları

 

Fabrika Kullanma ve Oluşturma Sınıfları

 

Arkadaşlar yukarıdaki uml diagramlarına bakarak şunları çıkartabiliriz.

 

• Bilgisayar ve Çanta üreten fabrikalarımız ve bu fabrikaların üst sınıfı olan bir sınıfımız vardır.
• Bilgisayarlar ILaptop arayüzünü implemente etmek zorundadırlar.
• Çantalar IBag arayüzü implemente etmek zorundadır.
• Kullanmak istediğimiz model bilgisayar için fabrika üreten bir sınıfımız vardır.
   

 

Kodlarımıza bakalım.

 

ILaptop Arayüzü

 

Apple Laptop Sınıfı
 

 

Samsung Laptop Sınıfı

 

IBag Arayüzü



Apple Çanta Sınıfı

Samsung Çanta Sınıfı

 

Fabrikalara Arayüz Sunan Soyut Sınıf

Fabrika Üreten Sınıf

Apple Fabrikası

Samsung Fabrikası

Bilgisar Almak İsteyen Sınıf

 

Arkadaşlar yukarıdaki kodlarımızı adım adım inceleyelim.

 

1. Kullanılmak istenilen Laptop markası dışarıdan alınıyor.
2. Alınan laptop markası fabrikaları üreten sınıfa gönderiliyor(FactoryComputer).
3. FactoryComputer gelen modele göre ilgili fabrikayı oluşturup geri FactoryBase üst sınıfını gönderiyor.
4. Kullanılmak istenilen Laptop ve Bag nesneleri için gönderilen sınıfın CreateBag ve CreateLaptop metodları çağrılıyor.
5. Bu metodlar üst sınıf olan IBag ve ILaptop sınıflarını geriye döndürüyor.
    

Gördüğünüz gibi arkadaşlar fabrika oluşturmak da fabrika kullanmak da gayet basit. Tabiki iyileştirmeler yapılabilir.  Fabrika oluşturma işlemlerini if veya switchlerle kontrol edilmeyebilir. Modellerimiz için oluşturulan laptop ve çantaları biz tek tip yaptık. Bunlar çeşitlendirilebilir.

 

Bir yazının daha sonuna geldik. Bir sonraki yazıda buluşmak üzere :)

Design Patterns - Factory Patterns

Merhaba Arkadaşlar,

 

 

Bu yazımızda Türkçesi Tasarım Desenleri olan Design Patterns serisine giriş yapacağız. Aslında aman aman öyle yeni birşey anlatmayacağız. Daha önceki serimiz olan Design Principles kavramlarının baz alarak sıkça rastlanan sorunlara bulunan çözümleri anlatmaya çalışacağız.

Ama önce en son yazımızda ne yazdığımız ile ilgili bilgi vermek istiyorum. (Lost izleyenler flash backleri severler:))

En son yazımızda Dependency Inversion prensibini incelemiştik. Bu prensibte  değişmesi öngörülen alt sınıfların soyutlaştırılmasından bahsettik.

Tasarım Desenleri serimize çoğu üstadın ve arkadaşlarımızın aksine Factory deseni ile başlamak istiyorum(Fabrika diyince insanın içi bir hoş oluyor. Acaba kendimi fabrikatör gibi hissetmemi sağladığından olabilir mi :P ).

Arkadaşlar Fabrika diyince aklımıza ilk gelen şey nedir? Seri üretim yapan, ürettiği şeylerin birbirine benzediği, üretimden sorumlu olduğu bina veya yapılardır.

Bakkala gittiğimiz zaman çikolata almak istediğimizde bize ambalajlı, kapağı olan, cam veya plastik kapta, içi çikolata dolu bir ürün verirler. Ürünün oluşturulması ile ilgili son kullanıcıya iş bırakılmaz.

Yani tekrar bakkala gidelim(Bu sefer başka bakkala gidelim. Ekonomiye can verelim :P) . Çikolota isteyelim. Bize bakkal amca yukarıda yazdığımız ambalaj, kapak, cam, kap, ve çikolotayı verse al kardeşim sen kendin bunu tak, çıkar, koy birşeyler yap sonra yersin. Ne olurdu tepkimiz ?

Factory deseni de işte burada noktaya giriyor. Benim gördüğüm iki noktaya son kullanıcı adına çözüm buluyor.

• Ürünün üretilmesi
• Birden çok aynı tip ürünün tek bir noktadan üretilmesi

Şimdi gelelim örnek yapımıza o kadar çikolatalardan bahsettik fabrikamız da çikolata fabrikası olmasında bir sakınca görmüyorum :)

Uml diagramlarımıza bakarsak pek hayırlı bir kod olmadığı ortada :) Cinsleri aynı nesnelerin bir üst sınıftan türetmemek kod hamallığından başka bir şey değil arkadaşlar.

 

Kodumuza gelirsek,

 

Alpella Sınıfımız:

 



Metro Sınıfımız:

Program Sınıfımız:

 

Arkadaşlar kod resimlerinin bazıları bulanık gibi gözüküyor. Yazının sonunda uygulamanın kodlarını ekleyeceğim.

Konumuza dönersek; Farkettiğiniz gibi çikolataları alma ve oluşturma işlemlerini Program sınıfı yapıyor. Yukarıda yazdığımız senaryo da bakkaldan çikolata parçalarını almak ve birleştirmemiz gibi birşeye tekabul ediyor. Bu hem zahmetli bir iş, hem yapılmaması gereken bir iş.

Yukarıdaki kodda bir prensibi de çiğnedik sizce hangisi ? Farkettiyseniz single responsibility prensibini CreateChocolate metodunda çiğnedik. Method hem çikolata oluşturuyor hemde çikolatalar hakkında bilgiyi ekrana basıyor. Bu iki işlemi ayrı metodlara alma işlemini de yeni kodumuza ekleyelim.

 Şimdi kodumuzu düzenleyelim ve bir fabrika deseni kullanarak bu işlemi gerçekleştirelim.

 

 

 

Yeni uml diagramımız yukarıdaki gibi yaparsak sanırım işleri biraz güzelleştirmiş oluruz. Program sınıfı çikolata üretmek için artık uğraşmayacak. ChocolateFactory sınıfından hangi tipten ne kadar istiyor ise o kadar alacak.
 
 

 

Yukarıdaki kod Program sınıfı tarafından ChocolateFactory sınıfından çikolata isteme işlemlerini içeriyor.

Çikolata Fabrikası bu isteği aşağıdaki gibi karşılıyor ve cevap veriyor.

Factory metodu bu şekilde arkadaşlar. Tabi bu kod hala prensiplerimizden bazılarına uymuyor. Open Closed Prensibi burada bizim çakılmamıza neden olur. Sisteme her yeni çikolata eklediğimizde ChocolateFactory sınıfımızı da güncellememiz gerekecek. OCP prensibini uygulamak adına burada reflection yöntemiyle sınıfları ayağa kaldırma işlemi yapılabilir.

 

Umarım size bir fabrikatör olmanın ne kadar kolay olduğunu anlatabilmişimdir :). Eğer benim fabrikamda eksik veya yanlış gördüğünüz bir nokta var ise beni bilgilendirmeniz dolayı memnuniyet duyarım .Her  ne kadar parmaklarımız yazmak için caba gösterse de cahil insanlar olarak illaki bir noktaları kaçırmış olabiliriz.

 

Arkadaşlar uygulamanın kodlarını buradan indirebilirsiniz.

 

Bir sonraki yazıda görüşmek üzere. İyi çalışmalar...

 

 

 

Design Prenciples - Dependency Inversion

Merhaba arkadaşlar,

Nesne yönelik programlama adı altında tasarım prensiblerimizi anlatmaya devam ediyoruz. En son anlattığımız konu Interface Segregation prensibiydi.

Her zamanki gibi en son yazdığımız makalemizi hatırlamak adına ne olduğu hakkında kısa bilgi verelim. Interface Segregation prensibi, interfaceleri doğru şekilde tanımlamayı ve implemente edilmesini önerir.

Bu yazımızda anlatacağımız konumuz ise Dependency Inversion prensibidir. Konuya girmeden önce gerçek hayattan birkaç bilgi vermek istiyorum.

Plug and Play denen bir kavram vardır. Bir nesneye başka bir nesnelerin takılıp çalıştırılabilmesi ve iş yaptırılması. Örneklersek eskiden kalma teyplerde kaset takmak, arabanın lastiğini değiştirmek, laptopun bataryasını değiştirmek.

Bunlar olmasaydı ne olurdu diye düşünelim. Bir teyp sadece 1 kaset çalıştıracak, arabanın lastiği değişilemeyecek, laptop bataryalar sökülemeyecek. E peki o zaman ben neden bunları alayım diye içinizden geçiriyorsunuzdur? İşte bu arkadaşlar bu yazımızın konusu :)

Üst sınıflarmız ile alt sınıflarımızı nasıl bağlamalıyız. Nesne yönelimli programlama gelmeden yukarıdaki örneklere insanlar çözüm bulmuş.

Nesne yönelimli programlama buna alt sınıfları soyutlaştırma işlemini yaparak çözüm bulmuş. Hemen uml diagramlarımızla konuyu anlatalım.

Yukarı uml diagramlarında görüldüğü üzere üst sınıf olan Laptop sınıfı alt sınıf olarak Anakart ve Batarya sınıflarına göbekten bağlıdır. Batarya sınıfında yapacağınız değişiklikler Laptop sınıfını direk etkileyebilir. Yukarıdaki diagramları yorumlamaya devam edersek bugün kullandığınız A markalı Anakart yerine B markalı Anakart koymak istediğiniz de Laptopunuzu değiştirmeniz gerekir.

Bu noktada Anakart ve Batarya sınıflarını soyutlaştırırsak laptopumuzun özelliklerini değiştirmemiz  daha kolay olacaktır. Çözüm olarak aşağıdaki uml diagram şeklimiz olabilir mi?

Laptop üst sınıfım artık hangi anakartı veya bataryayı kullandığı o kadar önemli değil çünkü IAnakart ve IBatarya arayüzlerimi uyguladıktan sonra her türlü anakart ve batarya laptopa takılabilir.

Velhasıl arkadaşlar nesne yönelimli programlama bize işlemleri kolaylaştırmak adına imkanlar sunuyor. Bu yazımızla beraber en temel 5 prensibi incelemiş olduk.

Yazdığımız uygulamanın nesne yönelimli bir kod olup olmadığına karar vermek istiyorsanız şu sorulara kendinize sormalısınız.

1- Yazdığınız kod nesne yönelimli ise
2- Tekrar kullanılabilir ise
3- Az bir çaba ile değiştirilebiliyorsa
4- Var olan kodu değiştirmeden genişletilebiliyor ise

güzel bir nesne yönelimli kod yazmışsınız demektir. Eğer bu sorulardan birine cevap veremiyorsanız. Kodunuzu tekrar gözden geçirmenizi tavsiye ederim.

Bir sonraki yazıda buluşmak üzere arkadaşlar :)

Design Prenciples - Interface Segregation

Merhaba arkadaşlar,

 

Tasarım prensipleri anlatımlarımıza kaldığımız yerden devam ediyoruz. En son Liskov Substitution prensibini incelemiştik. LSP prensibini kısaca hatırlamak istersek;

"Alt sınıflardan oluşturulan nesneler üst sınıfların nesneleriyle yer değiştirdiklerinde aynı davranışı göstermek zorundadır" açıklaması yeterli olacağını düşünüyorum.

 

Bugünkü anlatacağımız konu Interface segregation prensibi. Interface segregation prensibinin savunduğu tez şudur arkadaşlar: Interfaceleri sınıflara implemente ederken doğru şekilde implemente edin. Interface üzerinde tanımlanan şartlar, implemente edilen sınıfta kullanılmıyorsa burada bir yanlış var demektir.

 

Ne demek istedik ? Sistemimizde bir interface yazıp bütün şartları bunun içine koyup istenilen sınıflara implemente etmek ilerisi için büyük bir tehlike oluşturur. Sınıflar kullanmadığı her metodlara not implemented exception koymak zorunda kalıcak. Zaten bunun bir adım sonrası OCP ye ters düşen kod yazmaya yöneltecek.

 

UML şemamız ile konuyu anlatmaya çalışalım.

 

 

 

 

IArac interfacemiz olsun. IArac interfacemiz taksi,tir,kamyon gb. nesnelere nasıl davranacağını söyleyecek metodlara sahiptir. Calistir,DorseCikar,DorseTak,Durdur,FarAc,FarKapa,SileceklerCalistir gb. burada farkettiğiniz bir nokta olmalı. Bütün araçlar çalışır,durur,far açılır, far kapanır ama dorsesi olmayan araçlar dorse takamaz ve çıkaramaz. Yukarıdaki uml diagramında görüldüğü gibi taksi nesnesi bu metodlara notimplementedexception fırlatmak zorundadır.

 

Interface segregation kavramı da burada noktaya giriyor. Eğer interfaceniz uygulanan sınıflar tarafından desteklenmiyorsa interfaceinizi bölün.

 

 

 

 

Yukarıdaki uml diagramında IArac arayüzündeki(interface) DorseCikar ve DorseTak metodları IDorseliArac arayüzüne verdik. IDorseliArac arayüzü IArac arayüzünden türettik. Tır ve Kamyon nesnelerine IArac arayüzü yerine IDorseliArac arayüzü implemente ettik.

 

Bu şekilde sınıflar kendilerine dikte edilen metodların hepsini kullanabilir duruma getirdik.

 

Biraz dikkat edersek, şu ana kadar incelediğimiz prensiplerin temelinde şu yatıyor. Sınıflarınız sade olsun, birden çok iş yapmasın, türetme işlemlerini doğru şekilde yapın, interface tanımlamalarını doğru şekilde yapın zaten uygulamanız kendi içinde tutarlı davranacaktır.

 

Hollandalı efsane futbolculardan Johan Cruyff'ın güzel bir sözü vardır futbol ile ilgili:

Futbol basit bir oyundur. Zor olan ise basit oynamaktır.

 

Yazılım dünyasındaki pekçok yazılımı da ben buna benzetiyorum. Kod yazmak basit bir eylemdir. Zor olan basiti yapabilmektir. Kod yazarken kullandığımız programlama dilinin özelliklerini bilip, onun prensiplerine, özelliklerine, davranışlarına hareket ettiğimiz zaman genelde uygulamalarımız doğru çalışır. Eğerki bu konulara hakim değilsek işte o zaman ortaya çıkan uygulamanın intikamı acı olur.

 

Bir sonraki yazımızda görüşmek üzere arkadaşlar :)