Kurumsal Java Yazılımı
Kurumsal Java Yazılımı
Kurumsal Java Yazılımı
|
|
- YAGNI
- KISS
- DRY
- UML’i Sevmeyenler İçin
- Interface Segregation Principle (ISP) – Arayüz Ayırma Prensibi
- Test Güdümlü Yazılımın Tasarım Üzerindeki Etkileri
- Builder Tasarım Şablonu
|
Posted: 17 Nov 2009 06:15 AM PST YAGNI = You Ain´t Gonna Need It = İhtiyacın Olmayan Birşeyi Oluşturma! Extreme Programming prensiplerinden birisi olan YAGNI, JUnit test karşılığı olmayan ve ihtiyaç duyulmayan program kodunun programcılar tarafından oluşturulmamaları gerektiğini ifade eder. Test güdümlü çalışıldığı taktirde YAGNI prensibi uygulanmış olur. Testlerin olmadığı yerde YAGNI vardır
|
|
Posted: 17 Nov 2009 05:58 AM PST KISS = Keep It Simple, Stupid (KISS) = Mümkün Olan En Basit Çözümü Seç! KISS prensibine göre bir programcı, mevcut bir sorunu çözerken mümkün olan en basit çözümü seçmelidir. En basit çözüm genelde en optimal çözümdür. Genelde programcılar bir sorunun en basit çözümünü basit ve yetersiz gördüklerinden daha komplike çözümler üretirler, ama bilmezler ki KISS prensibine bu sekilde ters düşmüş olurlar
|
|
Posted: 17 Nov 2009 05:20 AM PST DRY = Don’t Repeat Yourself = Kendini Tekrarlama! DRY prensibine göre programcının kodlama esnasında kod tekrarlarından (code duplication) sakınması gerekmektedir. Kodun kendini tekrarlaması (örneğin copy-paste metodu kullanılarak) yazılım sisteminin genelde bakımını ve geliştirilmesini zorlaştırır. Bunun önüne geçmek için azimle DRY prensibinin uygulanması gerekmektedir.
|
|
Posted: 17 Nov 2009 01:43 AM PST Herhangi bir araç kullanmadan UML sequence diagramı çizmek istiyorsanız, Websequencediagrams.com sitesini bir deneyin
|
|
Interface Segregation Principle (ISP) – Arayüz Ayırma Prensibi Posted: 17 Nov 2009 01:08 AM PST Birbiriyle ilişkili olmayan birçok metodu ihtiva eden büyük bir interface sınıf yerine, birbiriyle ilişkili (cohesive) metotların yer aldığı birden fazla interface sınıfı daha makbuldür.
 Resim 1 de yer alan Connector interface sınıfı bünyesinde JMS (Java Message Service) için gerekli iki metot bulunmaktadır: commit ve rollback. Bu metodlarin RMIConnector implementasyonunda implemente edilmeleri anlamsız olur. Büyük bir ihtimalle RMIConnector sınıfında bu metotların implementasyonu kod 1 de yer aldığı şekilde olacaktır.
package shop;
public class RMIConnector implements Connector
{
public void commit()
{
throw new RuntimeException("not implemented");
}
public void rollback()
{
throw new RuntimeException("not implemented");
}
}
Kod 1 de yer alan yapı LSP ile uyumlu değildir. Connector sınıfını kullananlar RuntimeException oluşabileceğini göz önünde bulundurmak zorunda bırakılmaktadırlar. ISP uygulandığı taktirde resim 1 de yer alan Connector interface sınıfını yok ederek, yerine sorumluluk alanları belli iki yeni interface sınıf oluşturabiliriz. Resim 2 de bu çözüm yer almaktadır.  Programcı olarak bir interface sınıfa birden fazla sorumluluk yüklememek için, interface sınıfın sistemdeki görevini iyi anlamamız gerekmektedir. Bu sadece bir sorumluluk alanı olan bir interface sınıf oluşturmamızı kolaylaştıracaktır. Bu yazıyı PDF dosyası olarak aşağıdaki linkten edinebilirsiniz.
|
|
Test Güdümlü Yazılımın Tasarım Üzerindeki Etkileri Posted: 17 Nov 2009 12:37 AM PST Yazılımcı olarak çalıştığım projelerde geleneksel ve çevik yazılım süreçleri hakkında tecrübe edinme firsatı buldum. En son kitabım bir çevik süreç olan Extreme Programming hakkındadır. Edindiğim tecrübeler doğrultusunda çevik süreçlerin, klasik yazılım süreçlerine nazaran bakımı ve geliştirilmesi daha kolay yazılım sistemlerinin oluşturulmasında daha avantajlı olduğunu söyleyebilirim.
Bu yazımda sizelere test güdümlü yazılım sürecinin, yazılım tasarımı üzerindeki etkilerini bir örnek üzerinde aktarmak istiyorum. TDD ile birlikte oluşan tasarım, kendiliğinden oluşan birşey değildir. Testler şekil aldıkça, oluşturmak istediğimiz tasarımın modeli de gözümüzde canlanmaya başlar. Oluşturduğumuz testler, programın gelecekteki kullanıcılarını (client) simule ettiği için, programın nasıl kullanılacağını testler bünyesinde gözlemlemek kolaylaşmaktadır. Bu süreç, sınıfların ve metotların kullanıcı gözüyle (client) tasarlanmasını sağlar. Bu sayede basit ve kullanışlı API (Application Programming Interface)’ler oluşur. Test güdümlü yazılım tasarımı devamlı zorlar ve yetersiz kaldığı yerlerde refactoring yöntemleriyle yenilenmesini sağlar. Bu süreç sayesinde kendisini devamlı yenileyen ve yeni gereksinimlere cevap veren bir tasarım oluşur. Bu yazıyı PDF olarak edinebilirsiniz. Note: There is a file embedded within this post, please visit this post to download the file.
|
|
Posted: 17 Nov 2009 12:31 AM PST Daha önceki bölümlerde Abstract Factory tasarım şablonu ile değişik nesne ailelerinden nasıl nesneler üretildiğini incelemiştik. Builder tasarım şablonu da Abstract Factory tasarım şablonunda oldugu gibi istenilen bir tipte nesne oluşturmak için kullanılır. İki tasarım şablonu arasındaki fark, Builder tasarım şablonunun kompleks yapıdaki bir nesneyi değişik parçaları bir araya getirerek oluşturmasında yatmaktadır. Birden fazla adım içeren nesne üretim sürecinde, değişik parçalar birleştirilir ve istenilen tipte nesne oluşturulur.
Diğer bölümlerde olduğu gibi bir örnek üzerinde bu tasarım şablonunu yakından inceliyelim.  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 | |
Kurumsal Java Yazılımı
|
Apache ile Tomcat Arasında Reverse Proxy Oluşturma Posted: 22 Nov 2009 05:13 AM PST JugTR.org projesi Tomcat içinde deploy edilen bir Java 6 web aplikasyonu (Servlet 2.5 spec). Bu aplikasyona http://www.jugtr.org adresi üzerinden ulaşabilmek için Tomcat’in 80 numaralı port üzerinde çalışması gerekmektedir. Kullandığım server üzerinde 80 numaralı portta Apache çalışmakta. Bu durumda Tomcat’i 80 numaralı port üzerinde çalıştırmam mümkün değil. 80 haricinde herhangi bir port seçerek, JugTR.org aplikasyonunu deploy edebilirim, örneğin port 8181. Bu durumda aplikasyonun erişim adresi http://www.jugtr.org:8181 olacaktır.
Apache ile Tomcat arasında Reverse Proxy oluşturarak JugTR.org aplikasyonuna 80 numaralı port üzerinden ulaşabiliriz. Reverse Proxy kullanıldığında http://www.jugtr.org adresine gelen kullanıcı istekleri Apache tarafından http://127.0.0.1:8181 adresine yönlendirilir ve bu şekilde 8181 portu üzerinde faaliyet gösteren Tomcat’e 80 numaralı port üzerinden erişim sağlanmış olur. Apache, kullanıcı ile Tomcat içinde deploy edilmiş ve 8181 numaralı portta çalışan JugTR.org aplikasyonu arasında aracılık etmiş olur. Apache ile Tomcat arasında Reverse Proxy oluşturmak için öncelikle mod_proxy modülünü Apache httpd.conf dosyasina eklememiz gerekiyor. Ben Apache 2 versiyonunu kullanıyorum. Aşağıda httpd.conf dosyasında yer alması gereken konfigürasyon bulunmakta.
LoadModule proxy_module modules/mod_proxy.so [Proxy *] Order deny,allow Allow from all [/Proxy] NameVirtualHost 192.168.1.76 [VirtualHost 192.168.1.76] ServerName www.jugtr.org ServerAlias www.jugtr.org jugtr.org ServerAdmin in...@jugtr.org DocumentRoot /database/usr/local/apache/htdocs/ ProxyPass / http://127.0.0.1:1224/ [Location /] ProxyPassReverse / [/Location] [/VirtualHost] Yukarda görüldügü gibi VirtualHost direktifini kullanarak, jugtr.org icin yeni bir virtual domain oluşturuyorum. Bu sayede aynı Apache kurulumu üzerinde birden fazla domain ismini kullanmam mümkün. VirtualHost direktifini yakından incelediğimizde ProxyPass direktifi ile http://www.jugtr.org/ adresine gelen tüm kullanıcı isteklerinin (request) http://127.0.0.1:8181 adresine yönlendirildiğini görmekteyiz. ProxyPass direktifini kullanarak Apache ve Tomcat arasında Reverse Proxy oluşturmus oluyoruz. Tomcat kullanıcı isteklerine konfigüre edildigi IP ve port adresi ile cevap verir. Yukardaki örnekte kullanıcı http://127.0.0.1:8181 adresine yönlendirilecektir. Bu durumda Apache ile Tomcat arasındaki proxy çalışmamaktadır. Tomcat’in gönderdigi cevapların reverse proxy adresinde olmasını sağlamak için Tomcat’in server.xml konfigürasyon dosyası üzerinde değişiklik yapmamız gerekmektedir. Yapılması gereken değişiklik Connector elementi bünyesindedir. Connector port="1224" maxThreads="150" minSpareThreads="25" maxSpareThreads="75" enableLookups="false" redirectPort="8443" debug="0" acceptCount="100" connectionTimeout="20000" disableUploadTimeout="true" URIEncoding="UTF-8" proxyName="www.jugtr.org" proxyPort="80" Connector elementinde kullandığımız proxyName ve proxyPort atributlarıyla Tomcat’in gönderdiği cevapların http://www.jugtr.org şeklinde olmasını sagladık.
EOF ( End Of Fun )
Özcan Acar
|
|
Posted: 21 Nov 2009 05:25 AM PST Geçen hafta Belçika’da düzenlenen Devoxx konferansına katıldım. Java ile ilgilenenlerin mutlaka katılması gereken bir konferans. Bir hafta boyunca değişik konularda, konularında uzman şahısların sunum yaptıkları bu konferansta James Gosling, Robert C. Martin, Chris Richardson, Scott Ambler gibi ustaları dinleme ve onlarla sohbet etme fırsatı bulabiliyorsunuz.
Aşağıda yer alan fotografları Devoxx’da çektim.
Resim 1 de Agile Mythbuster konulu sunumu yapan Scott Ambler yer almakta. Çevik süreçlerde oluşan bazı efsaneleri tematize eden bu sunumda Scott Ambler bazı efsanelerin nasıl oluştuğunu ve nasıl çürütüldüğünü istatistikler üzerinde dinleyicilere aktardı. En çok hoşuma giden efsane ise, çevik süreçlerde sertifikasyonun çok önemli olduğu idi. Scott Ambler’e göre 3 sene doktora yapmış bir şahıs ile 2 günlük bir seminer ardından sertifika almış bir şahısı aynı kefeye koymak çok mantık dışı
Resim 4 de Architecting Robust Applications for Amazon EC2 konulu sunumu yapan Chris Richardson yer almakta. Chris Richardson POJO in Action konulu kitabın yazarı. Bu kitap yazılımcı kariyerimde beni en çok etkileyen kitaplardan birisidir. Chris Richardson ustayı Devoxx da dinleme firsatı bulmak benim için büyük bir şerefdi.
Resim 5 de Java’nın babası James Gosling ve ben yer alıyorum.
Resim 6 Resim 6 da programcılar için hazırlanan anketlerden birisi yer almakta. Resim 6 da yer alan ankette, programcılara kullandıkları yapılandırma (build tool) aracı sorulmuş. Çoğunluğu maven ve ant yapılandırma aracı oluşturmakta. Benim son zamanlardaki favorim maven. Resim 7 Resim 7 de değişik ülkelerde faaliyet gösteren JUG (Java User Group) liderlerinin katıldığı toplantıdan bir resim yer almakta. Bu toplantıda JUG liderleri Java hakkındaki sorularını Java’nın babası James Gosling’e yönelttiler. Bu toplantıda bir çok JUG lideri ile tanışma firsatı buldum. Türkiye’de de bir JUG kurmanın zamanı geldi. Kısa bir zaman sonra JugTR.org adresinde Türkiye’nin ilk resmi JUG’u faaliyete geçecek. Bu konudakı çalışmalarım devam etmekte.
|
