Kurumsal Java Yazılımı
|
|
|
Facade (Cephe) Tasarım Şablonu Posted: 07 Oct 2009 06:42 AM PDT Profesyonel yazılım sistemleri birçok komponentin birleşiminden oluşur. Yazılım esnasında bir çok ekip birbirinden bağımsız, sistemin bütününü oluşturan değişik komponentler üzerinde çalışırlar. Bir komponent, belirli bir işlevi yerine getirmek için hazırlanmış bir ya da birden fazla Java sınıfından oluşmaktadır.
Bir komponentin sunmuş olduğu hizmetten yararlanabilmek için, komponentin dış dünya için tanımlamış olduğu giriş/çıkış noktaları (input/output interface) kullanılır. Komponent sadece bu giriş/çıkış noktaları üzerinden dış dünya ile iletişim kurar ve iç dünyasını tamamen gizler. Bu komunikasyon noktaları genelde Facade tasarım şablonu kullanılarak programlanır. Uml diagramında görüldüğü gibi Komponent1 isminde bir sistem komponenti, dış dünya ile komunikasyonu KomponentFacade interface sınıfı üzerinden sağlıyor. Kullanıcı sınıfın (client) tanıması gereken sınıflar FacadeFactory ve KomponentFacade sınıflarıdır. FacadeFactory ile, kullanıcı sınıfın kullanabileceği şekilde bir KomponentFacade nesnesi oluşturulur. Komponentin sunduğu hizmetlere, KomponentFacade interface sınıfında tanımlanmış metodlar aracılığıyla ulaşılır. Komponenti kullanmak için tanımlanan giriş noktası KomponentFacade.doSomething() metodudur. Bu yazıyı PDF olarak edinebilirsiniz. Note: There is a file embedded within this post, please visit this post to download the file.Konuyla İlgili Kitaplar |
| You are subscribed to email updates from Kurumsal Java Yazılımı
To stop receiving these emails, you may unsubscribe now. |
Email delivery powered by Google |
| Google Inc., 20 West Kinzie, Chicago IL USA 60610 | |
|
Posted: 08 Oct 2009 02:26 AM PDT Oluşturulmaları zaman alıcı ve sistem kaynaklarını zorlayan nesnelere vekalet eden nesnelere proxy nesneleri adı verilir. Bu nesneler vekil oldukları nesnelerin tüm metodlarına sahiptirler ve kullanıcı sınıf ile vekil olunan nesne arasında aracılık yaparlar. Vekil olan nesne, kullanıcı sınıfa, vekil olunan nesne gibi davranır ve kullanıcı sınıftan gelen tüm istekleri vekil olunan nesneye iletir. Böyle bir yapının kullanılmasının sebebi, gerek olmadığı sürece vekil olunan nesnenin oluşturulmasını engellemektir ya da vekil olunan nesneyi gizlemektir. Böylece vekil olunan nesneye dışardan erişimlerde kontrol altına alınmış olur. Yazılan programın yapısına göre, değişik tipte proxy nesneler kullanılabilir. Bunlar virtual (sanal), remote (uzak bir nesne) ve dynamic (dinamik nesne) proxy nesneler olabilir. Değişik proxy tiplerini yakından inceliyelim. |
|
KurumsalJava.com Otuzbininci İndirime (Download) Koşuyor Posted: 07 Oct 2009 07:54 AM PDT Hizmet vermeye başladığı günden beri yazılım sektöründe Java teknolojileri ile çalışanların yoğun ilgisini çeken KurumsalJava.com’un bünyesinde barındırdığı ve KurumsalJava.com yazarları tarafından kaleme alınan makalelerin indirilme (download) adedi 30.000 e yaklaştı. Otuza yakın makale tasarım şablonları, extreme programming, yazılım mimarisi, performans, yazılım testleri, open source, ve mimari başlıkları altında okuyuculara sunulmaktadır. KurumsalJava.com sunduğu yüzlerce sayfalık Java kaynak makaleler ile Türkiye’nin öncü Java eğitim ve tecrübe paylaşım platformu haline gelmiştir. PDF formatında olan makalelere Makaleler bölümünden ulaşabilirsiniz. |
|
Chain of Responsibility Tasarım Şablonu Posted: 09 Oct 2009 04:01 AM PDT Chain of responsibility sorumluluk zinciri anlamına gelmektedir. Sisteme gönderilen bir istediğin (komut) hangi nesne tarafından cevaplanması gerektiğini bilmediğimiz durumlarda ya da isteği yapan nesne ve servis sağlayan nesne arasında sıkı bir bağ oluşmasını engellememiz gerektiğinde Chain of Responsibility tasarım şablonu kullanılır. Bu tasarım şablonunda servis sağlayan ilgili tüm nesneler bir kolye üzerindeki boncuklar gibi birbirleriyle ilişkili hale getirilir. Bir nesne zincirdeki kendinden sonraki nesneyi tanır ve isteği kendi cevaplayamadığı durumda, kendinden sonraki nesneye iletir. Bu işlem, zincirde bulunan doğru servis saglayıcı nesneyi bulana kadar devam eder. Bu tasarım şablonu için ilginç bir örnek kullanmak istiyorum. İçine para atarak, kahve aldığımız bir kahve otomatı düşünelim. Bir kahvenin bedeli 1 TL olabilir. Kahveyi alabilmek için 1 TL değerindeki metal parayı otomata atmamız gerekiyor. |
|
Front Controller Tasarım Şablonu Posted: 09 Oct 2009 03:44 AM PDT Web aplikasyonlarında Front Controller tasarım şablonu ile sisteme yöneltilen tüm istekler (request) merkezi bir yerde toplanarak işlem görürler. Front Controller ile, yönlendirme ve işlem yapma fonksiyonlarının birden fazla view (bir JSP sayfası olabilir) elementine dağıtılması önlenmiş olur.Tüm view elementleri yönlendirme ve işlem yapma fonksiyonlarını ortak kullanırlar. Böylece Front Controller tasarım şablonunun kullanıldığı bir proje bakımı ve geliştirilmesi daha kolay bir hale gelir. Ayrıca Front Controller ile gösterim ve navigasyon fonksiyonları birbirinden ayrıldığı için, gösterim katmanını etkilemeden navigasyon idaresi değiştirilebilir yada tamamen yenilenebilir. |
|
Flyweight (Sinek Siklet) Tasarım Şablonu Posted: 09 Oct 2009 02:37 AM PDT Java dilinde yazılan programlar içinde sınıflar ve bu sınıflardan oluşturulan nesneler kullanır. Bazen aynı sınıftan yüzlerce, belki binlerce nesne oluşturup, kullanıyor olabiliriz. Bu gibi durumlarda çok nesne oluşturulduğu için sistem performansı kötüye gidebilir. Flyweight tasarım şablonu kullanılarak, kullanılan nesne adedini aşağıya çekebiliriz.
Bu satırlar oluşurken, büyük bir ihtimalle kullandığım editör flyweight tasarım şablonunu kullanıyor olabilir. Yazdığım her cümle kelimelerden, her kelime birden fazla harften oluşmaktadır. Kullandığım editörün Java dilinde yazıldığını ve her harf için bir nesne kullandığını farzedersek, bir satırlık doküman için 80 ila 100 arası harf nesnesi oluşturması gerekir. 100 satırlık bir doküman için bu 10.000 civarı harf nesnesinin oluşturulması anlamına gelir. |
| You are subscribed to email updates from Kurumsal Java Yazılımı
|
| To stop receiving these emails, you may unsubscribe now. |
| Email delivery powered by Google |
|
Single Responsibility Principle (SRP) – Tek Sorumluk Prensibi Posted: 14 Oct 2009 05:48 AM PDT Resim 1 deki gibi bir sınıfa daha önce bir yerlerde rastlamışsınızdır. Bu sınıf kendisini bilgibankasına ekleme, silme, müşteriye email gönderme, login yapma (shop sistemi olabilir) ve sipariş oluşturma işlemlerini yapabilmektedir.
Büyük bir ihtimalle bu sınıfı programlayan programcı kendisi ile gurur duyuyor olmalıdır. Aslında böyle bir sınıfın ve programcının küçümsenecek hiçbir tarafı yok. Bu sınıf büyük emek harcanarak oluşturulmuş olabilir, çünkü ihtiva ettiği metotlar basit değildir. Lakin bu sınıf saatli bir bombadır, çünkü içinde bulunduğu ortamdaki her değişiklik, sınıfın yapısal değişikliğe uğramasına sebep olabilir. Bunun yanı sıra Customer sınıfında implemente edilen kod tekrar kullanılmak istendiğinde, Customer sınıfının bağımlı olduğu sınıf ve API’lerin bu sınıfla beraber kullanılma zorunluluğu vardır, yani Customer sınıfı gittiği yere beraberinde kullandığı diğer sınıflar ve API’leri götürür. Bu kodun tekrar kullanımını sağlamak için istenmeyen bir durumdur. Customer sınıfını test edilebilir ve bakımı kolay bir hale getirmek için, sahip olduğu sorumlulukların başka sınıflara yüklenmesi gerekmektedir. Bunun bir örneğini resim 2 de görmekteyiz.
Resim 2 de yer alan Customer sınıfı sahip olduğu sorumlulukların başka sınıflara yüklenmesiyle hafiflemiş ve değişikliklere karşı daha dayanıklı bir hale gelmiştir. Bunun yanı sıra bu sınıfın test edilebilirliği yükselmiştir. Bu ve diğer sınıfların değişmek için artık sadece bir sebebi vardır. Bunun sebebi sadece bir sorumluluk sahibi olmalarında yatmaktadır. Bir sınıfın sorumluluğunu sadece bir sebepten dolayı değişebilir olması olarak tanımlayabiliriz. Eğer bir sınıfın değişikliğe uğraması için birden fazla sebep varsa, bu sınıf birden fazla sorumluluk taşıyor demektir. Bu durumda sınıfta sadece bir sorumluluk kalacak şekilde, sorumlukların diğer sınıflarla paylaşılması yoluna gidilmelidir. |