observer pattern

• özellikle otomasyon alanında uygulanması çok basit ve kullanışlı bir design pattern. örneğimizi şu şekilde kuralım. bir cihazımız olsun. biz bu cihazın bir durumunu gözlüyor olalım. örneğin bir benzin deposunun su ile dolması. ayrıca bu deponun dolması ile ilgilenen birden fazla izleyicimiz olsun. örneğin benzin pompası, benzin göstergesi, yol bilgisayarı gibi.
  
  biz bütün bu istemcileri observer isimli bir absolute class'tan türetirsek, ve bu absolut class'ın pure virtual bir wakemeup() metodu olsa ne güzel olur değil mi..
  
  üstüne, benzin deposu class'ımızın bir vektörü olsa ve bu vektör observer tipinden elemanlar tutsa.. ve istenen durum gerçekleştiğinde, yani depo dolduğunda bu vektörü bir döngüde dolaşıverip wakemeup metodlarını çağırsa.. hoş olmaz mı?
  
  böylece yeni bir istemci eklediğinizde, ne benzin deposunun, ne de diğer istemcilerin haberi bile olmadan tık diye o vektöre ekleyiverseniz..
  
  dikkatli arkadaşlarım benzin deposunu su ile doldurduğumuzu farketmişlerdir.
  
  yıllar sonra: daha dikkatli arkadaşlarım ise "absolut class" değil "abstract class" olması gerektiğini de farkettiler.
• javada hazır bulunan observer arayüzünü implement ederek kolayca uygulayacağınız tasarım deseni. observable tarafının arayüz yerine soyut sınıf olmasından dolayı başka bir sınıftan hali hazırda türemekte olan bir nesne observable ı extend edemez.
• class diagramı linkteki gibi olan tasarım örüntüsü: http://www.codeproject.com/…ngpatterns/observer.gif
  
  bir örnek verecek olursak, haber ajanslarını takip eden basın organları bu örüntü ile gerçekleştirilebilir. basın organları: concreteobserver, haber ajansı ise concrete subject olarak, linkte verdiğim diagramda yerlerini alır. diğer abstract sınıf ve interface in adı tercihe göre aynen kalabilir. haber ajansları bir haber geldiği zaman izleyen tüm sınıflara "değiştim" iletisi göndermek üzere "notify" yordamını çalıştırır. notify yordamı ile observer interface'i içerisinde yer alan ve izleyen sınıflarda her biri farklı şekillerde kodlanmış olan update yordamı çalıştırılır. izleyen sınıfların her biri izlenenin hangi özelliği ile ilgileniyorsa o özelliğini yordam içerisinde işler.
  
  bu örüntünün dezavantajlarından biri, izleyen sınıflara izlenen nesne kendisini gönderir ve izleyen sınıflar izlenen sınıfın attributelarını diledikleri gibi değiştirebilirler.(yapmasana şunu kardeşim, eline koluna hakim ol) bu ise izleyen sınıfın klonunu gönderme yolu ile çözülebilir.
• model view controller ya da mvc adıyla bildiğimiz yapı da observer patternının bir uyarlamasıdır
• design patterns in abap objects adlı kitapta sap abap uygulaması öğrenilebilecek pattern.
  
  özetle; bu pattern twitter gibi düşünülebilir. merkezi sınıf, önemli şeyler oldukça olup biteni tweet'miş gibi yayınlar, takip edenler de bu yayınları dinleyerek kendilerini ilgilendiren bir şey varsa harekete geçer.
• herkesin degisik orneklerle aciklamaya calistigi guzide tasarim kalibina tukureyim...
  
  nereden geldik bu noktaya ben de bilemiyorum.
• ismi dikizci ya da gözlemci olarak dilimize çevrilebilecek olan bir tasarım kalıbı )design pattern). publisher-subscriber olarak da anılır ve genel olarak event mekanizmalarının alt yapısında kullanılır. son zamanlarda gelişmekte olan reaktif programlamanın da temelindeki yapıdır.
• a ve b nesnesi olsun.
  1.a nesnesi kendi içerisinde durumunu zamanla değiştirir olsun. örneğin, kullanıcı girişi durumu giriş yaptı, çıkış yaptı, giriş yapılıyor gibi çeşitli durumları içersin ve bu durumlar kullanıcı giriş yaptığında, kullanıcı giriş yaptı veya benzeri şekilde değiştirilebilir olsun.
  
  2.b nesnesi ise belir bazı nedenlerden ötürü, a nesnesinin mevcut durum değişikliklerinden haberdal olması gereken bir nesne olsun. örneğin, anasayfa nesnemiz olsun ve kullanıcı giriş yaptıysa kullanıcıya göstericekleri içerikler kullanıcıların görmesi gereken içerikler iken, çıkış yaptığında ise bir hata sayfası gösterilmesini sağlaması gereksin.
  
  doğal olarak b nesnesi gösterilecek her içerik, her yeni sayfa içeriği her yorum butonuna tıklanma, her option butonuna tıklanma ve benzeri gibi durumlar, aksiyonlar için a nesnesine ihtiyaç duyucak ve her seferinde ona istek atmak zorunda olucak.
  
  hatta bu durum periodic bir şekilde bile gerçekleşmek zorunda olabilir(örneğin her 1 saniyede bir kullanıcı giriş yapılı mı isteği atıyor olmak zorunda olabiliriz.)
  
  bu tahmin edilebileceği gibi sorunlu bir yapı, çünkü hep kontrol isteği atıyoruz ve durmaksızın bir koşul sorgusu yapıyoruz.
  
  observer pattern mantığı da özetle tam burda devreye giriyor, yukarıda ki senaryoda ki gibi durmaksızın kontrol etmek için a nesnesine istek atmak yerine,
  
  a nesnesi sadece state'i değiştiğinde, gerekli nesnelere bunu bildiriyor. yani a nesnesi observable, ve b nesnesi subscriber ise, a nesnesi sadece state'i değiştiğinde b nesnesine ben değiştim diyor ve artık her seferinde b ile a nesnesi arasında iletişim kurulmasına, kontrol sırasında oluşucak zaman farklılıkları sebebiyle problem yaşanması gibi durumları ortadan kaldırmış oluyoruz.
  
  youtube mantıgından düşünürseniz, 1 hesabın 10 bin takipçisi var diyelim, günde 10 defa takipçiler, yeni video geldi mi diye kontrol etmek için, a hesabına istek atsa, 1 gün içerisinde 100.000 istek atılmış olucak.
  
  ama bunun yerine observer pattern ile, a hesabı video yüklediğinde 10.000 takipçiye bu bildirim iletildiğinde, sadece 10.000 işlem ile 90.000 işlemlik gereksiz işten kurtulunmuş olunucak.
  
  özetle nesneler arasında one to many ilişkisi olduğunda, one'ı diğer nesnelerin dinlemesi ve o güncellendiğinde güncellenmeleri gerektiği yapılarda, observable - observer ilişkisi kurmamızı sağlayan tasarım kalıbıdır.
  
  (bkz: behavioral design patterns)
  
  son olarak şu linkte o kadar güzel anlatılmış ki; link, mutlaka izleyin.