Malum “jar”, Java’nın arşiv formatıdır. Jar formatında arşiv oluşturmak için gerekli araç “jar” ve diğer Java araçları her JDK kurulumunda vardır ve yerleri de yine malumunuz olduğu üzere JDK’nın bin klasörüdür. Projemize üçüncü el bir bileşen (third party component) eklemek istediğimizde o bileşenin jar dosyalarını classpath’e koymamız yeterlidir. (JDK’le birlikte gelen Java SE’nin bileşenleri de zaten jar dosyası olarak, örneğin rt.jar, makinamıza kopyalanırlar.) Bu en sık yaptığımız işlerdendir. Hatta o kadar ki Java projelerinde kod yazmak değil ama uygun jar sürümlerini bulup bir araya getirmek çoğu zaman daha zor olabilir 🙂

Zaman zaman “jar dosyası nasıl oluşturulur” şeklinde sorularla karşılaşıyorum. Bu yazıda hızlıca hem çalıştırılabilir (executable) hem de çalıştırılabilir olmayan jar arşiv dosyaları nasıl oluşturuluru anlatacağım.

Jar dosyası oluşturmak için gerekli adımları şöyle listeleyebiliriz.

• Masaüstünüzde “Selam” isimli bir klasör açın. Benim makinamda bu “/Users/akin/Desktop/Selam” şekilde bir yola sahip olacaktır.
• Bu klasörde Selam.java and SelamTest.java isimli iki Java kaynak kodu dosyası yaratın. Bu sınıfları buradan alabilirsiniz. Bu iki sınıfın da “org.javaturk.oop.ch01” şeklinde bir pakete sahip olduğuna dikkat edin.
• Bulunduğunuz klasorde “bin” isimli bir başka klasör oluşturun. Derlenmiş class dosyalarımızı buraya koyacağız.
• Sonra bir terminal ya da command line (CMD) açıp Selam klasörüne gidin.
• Sonra bu iki kaynak kodu derlemek için ya şu iki satırı

javac -d ./bin SelamTest.java
javac -classpath ./bin -d ./bin SelamTest.java

ya da bu satırı yazıp çalıştırın:

javac -classpath ./bin -d ./bin *.java

Bu satırlar kaynak kodlarını derleyip, ilgili paket yapısını oluşturacak şekilde class dosyalarını karşı gelen klasörlere yerleştirecektir. Artık Selam’ın altında şöyle bir klasör yapımız var:

bin
|
|__org
    |
    |__javaturk
         |
         |__ oop
              |
              |__ch01
              |
              |__Selam.class
              |__SelamTest.class

• Sonra “/Users/akin/Desktop/Selam” klasöründe aşağıdaki satırı çalıştırın.

jar cvf Selam.jar -C bin/ .

Bu satır “Selam.jar” isminde bir jar dosyası yaratacaktır. Jar dosyasının içeriği ise “bin” dosyasının altındaki klasör ve dosyalardan oluşacaktır.Zaten terminalde “jar” dediğinizde size “c”nin yeni bir jar dosyası yaratmak için, “v”nin jar komutunun çalışması sırasında neler yaptığını çıktı olarak yazması için, f’nin de “Selam.jar” ismin kullanması içın verildiğini anlarsınız. Jar yaratırken en fazla yanlış yapılan nokta, jarın içine girecekleri belirttiğiniz yerdir. Unutmayın “-C”, jar aracından, kendinden sonra gelen “bin/” klasörüne gitmeyi istemektedir. En sondaki “.”yi kesinlikle unutmayın. Eğer o noktanin ilk etapta yanlış yazıldığını düşündüyseniz lütfen bu yazıyı okumayı bırakıp, en temel MS-DOS, Unix ya da Linux kitabı edinip, baştan 20-30 sayfa okuyun. Zira genel olarak “.” bulunduğunuz klasörü, “..” ise bulunduğunuz klasörün ebeveynini gösterir ki bu yazıyı okuyorsanız, bu bilgiyi şu ana kadar öğrenmiş olmanız gerekirdi. Artık elinizdeki Selam.jar dosyasını projelerinizde kullanabilirsiniz. Yapacağınız şey, Selam.jar’i projenizin classpath’ine koymak. Ant ya da Maven gibi yapılar kullanıyorsanız, yapmanız gereken, onların kendi ayarlarını kullanarak Selam.jar’ın olması gereken yere örneğin repositorye gitmesini sağlamaktır. Projenizde kod olarak artık “Selam selam;” gibi bir satır yazdığınızda “import” anahtar kelimesini kullanarak “org.javaturk.oop.ch01.Selam” sınıfı ulaşılır hale gelecektir.

Peki oluşturduğumuz Selam.jar dosyasını nasıl çalıştırılabilir (executable) yaparız? Bir jar dosyasının çalıştırılabilir olması, içinde main metoda sahip olan sınıfın main metodunun çağrılması demektir. Bunun için Selam.jar oluşturulurken içine, main metoda sahip sınıfı ki bizde SelamTest, gösteren bilgi geçilmelidir. Bu bilgi jar aracına “e” ile geçilebilir. Yani şöyle bir satır gereklidir:

jar cvfe Selam.jar org.javaturk.oop.ch01.SelamTest -C bin/ .
 

Bu durumda oluşan Selam.jar dosyasının içine bakarsanız, META_INF klasörünün altında MANIFEST.MF isimli bir dosya olduğunu ve icinde de şu satırların olduğunu görürsünüz:

Manifest-Version: 1.0
Created-By: 1.8.0 (Oracle Corporation)
Main-Class: org.javaturk.oop.ch01.SelamTest

Artik teminalde

java -jar Selam.jar
 

yazarak “Selam Ali :)” çıktısını görebilirsiniz.

Bu jar dosyasını, classpath’e koyup, diğer projelerde kullanılmasını da sağlayabilirsiniz. Ya da işletim sisteminizde bu dosyaya çift tıklayarak java tarafından çalıştırılmasını sağlayabilirsiniz.

Benzer işler için Eclipse, Netbeans vb.geliştirme ortamlarını kullanabileceğiniz gibi Ant gibi araçları da kullanabilirsiniz.

Ayrıca konu ile ilgili Java Tutorial‘da da güzel ve geniş açıklamalar var.

Bol jar’lı günler dilerim 🙂

Toplam görüntülenme sayısı: 6342

Geliştirdiğimiz Java kodunun nesne-merkezli olmadığının 10 işaretinin neler olduğunu bu yazıda listelemiş ve bu yazıda ve bu yazıda da ilk iki maddeyi ele almıştık. Şimdi de üçüncü maddeyi ele alalım:

Kodunuzda hiç alan nesnesinin olmaması ya da varsa bile yetersiz ve ince olmaları. (No or very thin domain objects in the code.)

Eğer kodunuzda iş alanınızı modelleyen Müşteri, Hesap, Ürün, Poliçe, Kredi, Olay, Belge, Araç, Başvuru Dosyası ve benzeri nesneleriniz yoksa, bir iş modeliniz de yok demektir. Daha doğrusu, gerçekte var olan işinizin nesnelerle ifade edilmiş bir modeli yok demektir. Nesne-merkezli programlamanın en temel üstünlüğü ya da nesnelerin en fazla görünür olduğu yer aslında dilimizde işin nesne modeli (domain model ya da business domain model) olarak da adlandırdığımız, işin kendi kavramlarının ve aralarındaki ilişkilerin nesne merkezli olarak ifade edildiği durumdur. Böyle bir model, en temel iş terimlerini, özelliklerini ve sorumluluklarını ifade ettiği için son derece değerlidir. Bu modelin öncelikle bir sözlük olarak ifade etmek analiz sürecinde olmazsa olmaz çalışmalardandır. Sonrasında bu sözlüğü, use caselerden yola çıkarak, dilden bağımsız olarak UML class diyagramları ve/veya XML scheması olarak ifade etmek, uygulama geliştiren bir kurumun en temel bilgi teknolojisi değerlerinden olacaktır. Böyle bir çalışma ile kurum, teknik dilindeki tüm kavramları, ozellikleri ve davranışları boyutunda yakalamış olacaktır. Hatta eğilim, farklı ülkelerde hatta tüm dünyada, bazı kuruluşlar öncülüğünde, iş kollarının jargonlarının bu şekilde, platform ya da dilden bağımsız olarak yakalanıp ifade edilmesidir. Bunun da amacı, hızlı ve rahat entegrasyondur tabi olarak. Kurum böyle bir çalışmayla böyle bir modele sahip olduğunda, örneğin bu kurumun yazılımları gerek veri tabanında gerek ise uygulama katmanında, her zaman aynı iş terimlerini aynı şekilde ifade edecektir.

İşin nesne modeli kurgulanmadığında uygulamalar, işin nesne modeli ile ilgili en iyi ihtimalle, aynı nesneleri farklı şekilde ifade ederek ilerleyecektir. Bu durumda da örneğin Müşteri nesnesi, her uygulamada farklı yapılarda olacak ve uygulamalar arası bir entegrasyon söz konusu olduğunda ciddi miktarda “dönüştürme” yükü ortaya çıkacaktır. Özellikle başarılı SOA projelerinin önündeki en temel engellerden birisi, iş kavramlarını farklı şekillerde ifade eden veri tabanı ve uygulamaların birbirleriyle konuşabilmeleri için gerekli “dönüştürme” ya da “yeknesaklaştırma” çalışmalarının, özellikle büyük kurumlar için devasa boyutlara ulaşmasıdır.

Bir kurumda üç aşağı – beş yukarı aynı anlama gelen iş kavramlarının farklı uygulmalarda içerik olarak farklı şekillerde ifade edilmesi, yani bir uygulamanın Müşteri ya da Poliçe dediği kavramı, başka bir uygulamanın çok farklı nesnelerle ve yapılarla ifade etmesi, kurumsal mimari (enterprise architecture) açısından sıkıntılı bir durumdur. Ama hiç olmazsa bu organizasyonel bir problemdir. Bu durumun daha kötüsü şu iki halden birisi olur muhtemelen: İlkinde nesne merkezli bir iş modeli vardır ama bu modeldeki nesneler, sadece veri taşıyıp, diğer nesnelerle get/set metotlarıyla haberleşen dolayısıyla bir önceki maddede açıkladığım gibi, yüksek bir içerik bağımlılığına sahip olan nesnelerdir. Bu durumla sıklıkla karşılaşıyorum ve sebep olarak da nesne merkezli bir iş ve ihtiyaç analizi yapılmaması yanında, nesne kavramını yeterince içselleştirememiş, nesne-merkezli programlama konusunda tecrübe sahibi olmayan programcıları gorüyorum. Bu tür programcılar için nesne, yine bu serideki bir önceki yazımda açıkladığım gibi, bir kaç private alanı bir araya getirip, set/get metotlarını hızlıca oluşturmaya, nesne diyen, ama aslında nesne yerine veriyi modelleyen bir anlayışa sahip programcı arkadaşlarımızdır.

Bu türden nesnelere Martin Fowler “anemic domain model” ya da “kansız iş modeli” diyor. Yani bir model var ama model, iş alanındaki verileri temsil ederken malesef o modelin bir parçası olan davranışları, sorumlulukları temsil etmiyor. Yani model nesne ile kurgulanmış ama ifade ettiği şey, veri, davranışlar değil. Halbuki nesneler veri taşıyandan çok bir davranışa ya da sorumluluğa sahip olan elemanlardır. Verinin davranışlarıyla birlikte bir yerde ifade edilmesi, nesnenin ya da daha temelde sarmalama/encapsulation kavramın tanımıdır. Aksi taktirde tam da bir önceki maddede örneğini verdiğim Date nesneleriniz olur ve tarih ile ilgili davranışlar bir ya da daha çok kereler, “copy-paste reuse” tekniğini iyi bilen ya da birbirinden tamamen habersiz, her şeyi sıfırdan kendisi yapmaya çalışan yazılımcılar tarafından çoğaltılır. Bu da karman-çorman olmuş, anlaşılması zor, değişmesi daha zor olan yazılımlar demektir.

Gerek eğitimlerde gerek ise danışmanlık verdiğim yerlerde çok sıklıkla karşılaşıyorum bu türden durumlara. Account nesnesi var ama withdraw(), deposit() ya da calculateInterest() gibi metotlar Account nesnesi üzerinde değil. Bu gibi metotlar service ya da controller tipinde nesnelerde birikmiş durumda. Bu durumlarda son derece yetersiz, ince ya da zayıf iş nesneleri olurken, devasa boyutlarda, onlarca metota sahip servis nesnelerimiz oluyor. Daha da kötüsü, bu durumda bu türden iş nesneleri ile servis nesneleri arasında içerik bağımlılığı oluşuyor ki karmaşıklık çok ciddi bir engel haline geliyor. Bir nesneye değişiklik yapmak servis nesneleri ve onlar üzerinden diğer nesnelere kadar değişiklik yapmaya sebep oluyor. (Yeri değil ama bu ayırımı, yani veriyi nesneler üzerinde, davranışı ise servisler üzerinde tutmayı, katmanlı mimarinin gereği olarak uyguladığını söyleyenlere kafalarındaki katmanlı mimari ve nesne kavramını gözden geçirmelerini tavsiye ederim. Bu konuda benim şu ve devamı olan şu yazılarıma bakabilirsiniz.)

/**
 * This class represents a banck account anemically. It carries data but no responsibility regarding that data.
 * @author akin
 *
 */
public class Account {

	private String iban;
	private double balance;

	public Account(String iban, double balance) {
		super();
		this.iban = iban;
		this.balance = balance;
	}

	public String getIban() {
		return iban;
	}

	public void setIban(String iban) {
		this.iban = iban;
	}

	public double getBalance() {
		return balance;
	}

	public void setBalance(double balance) {
		this.balance = balance;
	}

	@Override
	public String toString() {
		return "Account [iban=" + iban + ", balance=" + balance + "]";
	}
}

Yukarıdaki gibi bir kansız nesnemiz olduğunda bakın para çekme işlemini nasıl yapıyoruz:

/**
 * This class implements business logic on Account object.
 * @author akin
 *
 */
public class AccountManager {
...
	public void withdraw(Account account, double amount) throws InsufficentBalanceException{
		
		double balance = account.getBalance();
		if(balance >= amount)
			balance -= amount;
		else
			throw new InsufficientBalanceException(account);
	}
...
}

Yukarıdaki AccountManager nesnesi ile Account arasında sadece bilgi akışı olduğuna ve bu durumun aslında en istenmeyen türden bağımlılık yarattığına dikkatinizi çekmek istiyorum. Biz tasarım sırasında temelde iş nesneleri arasındaki ilişkileri nasıl halledelim diye kafa patlatırken bir de böyle bir ilişki yumağı, sistemi berbat etmektedir.

İkinci durum ise, benim eskiden daha sık karşılaştığım, hiç bir nesne modelinin olmadığı, dolayısıyla sadece Java’daki ilkel tipler ile String tipindeki alanların List ve benzeri torbalarla taşındığı yaklaşımdır.

Bu durumda uygulama, ilgili iş kavramının, çoğunlukla veri tabanındaki anahtar alana karşılık gelen bilgisine sahiptir ve diğer bilgileri, bu anahtar bilgi sayesinde ya veri tabanından sorguluyordur ya da uygulamanın diğer parçalarından alıyordur. Ama nihai olarak alınan ve verilen şey nesne değildir, gerçekte nesne olabilecek bilgilerin bölük börçük ifade edilmesidir. Bu durumda aslında nesnelerde ifade edilmesi gereken nesneler arası ilişkiler (associations) de, genel olarak sadece veri tabanında tablolar arasında ifade edilir. Yani kod, tek başına anlaşılabilir bir yapı olmaktan çıkar.  Dolayısıyla örneğin aşağıdaki gibi metotlar çok sık görülür:

...
public ArrayList getVehicle(int id, String [] properties, boolean b){

   List vehicle = new ArrayLIst();
   vehicle.add(id);
   vehilce.add(properties[0]);
   ...
   return vehicle;
}
...

Bu metodun arayüzü, gerçekte Vehicle nesnesinin parçası olan farklı bilgileri, array vb. bölük börçük bilgiler olarak almakta ve yine bölük börçük pek çok bilgiyi bir ArrayList’e koyup geri döndürmektedir. Dolayısıyla iş alanının nesnelerle modellenmesi söz konusu değildir. Bu kodun bir programcı tarafından, ciddi miktarda bilgi desteği olmadan anlaşılması imkansızdır. Örneğin, “vehicle” ismindeki List’in hangi odasında ne var, bunların özellikleri nelerdir vb. bilgiler muhtemelen başka dokümanlarda tutulmalıdır ki bu kod programcılara anlam ifede etsin.

Her uygulama bir iş için yapılır ve ister çok teknik olsun ister olmasın ister çok karmaşık olsun isterse de sadece bir kaç süreç ve kural içerecek kadar basit olsun muhakkak bir iş süreci ve mantığı barındırır. Dolayısıyla bu süreçler ve ilgili mantığın, nesneler ve aralarındaki ilişkilerle ifade edilmesi gereklidir. Aksi taktirde hangi dili kullandığınızın ya da kaç katmanlı yapı kurguladığınızın çok fazla önemi olmayacaktır. Çok sıklıkla EJB, Spring, JSF gibi teknolojileri kullanacak öngörüde bulunan yazılımcıların bu konularda çuvalladığını görüyorum. Aslolan iş süreçlerinizi doğru düzgün ve değişıme el verecek şekilde modelleyip kodlamak. Teknoloji, hangi frameworku ya da hangi dili kullandığınız ancak bu sorunu çözdükten sonra problem olarak ele alınmalıdır.

Bol ve eğlenceli nesneli projeler diliyorum…

Toplam görüntülenme sayısı: 1558

Geliştirdiğimiz Java kodunun nesne-merkezli olmadığının 10 işaretinin neler olduğunu bu yazıda listelemiş ve bu yazıda da ilk madde olarak sınıflardaki aşırı statik metot kullanımını ele almıştık. Şimdi de ikinci maddeyi ele alalım:

Yüksek içerik bağımlılığı (high content coupling).

Malum bağımlılık (coupling), bir yazılım elemanının, diğer elemanlar hakkındaki bilgisinin derecesidir. Arzu edilen, mümkün olan en az derece bağımlılığa sahip yapılar kurgulamaktır. İster framework kurgulayın, isterse basit bir iş yapan metot kurgulayın, hem karmaşıklığı yönetmek hem de daha rahat değişebilen yapılar elde edebilmek için daima bağımlılığı az yazılım elemanları ile yazılım geliştirtirin.

Yazılım mühendisliği ya da “iyi kod nasıl yazılır” cinsinden kitaplar bağımlılık konusunu etraflıca ele alırlar ve farklı bağımlılık şekillerini incelerler. Örneğin wikipedia buna güzel bir görsel ile yer ayırmıştır. Bu anlamda içerik bağımlılığı, en kötü bağımlılıktır. Çünkü bir yazılım elemanı, bir başka yazılım elemanının iç yapısına bağımlıdır. Sınıf seviyesinde ele alındığında içerik bağımlılığı, bir sınıfın, bir başka sınıfın iç yapısına bağımlı olması demektir. (Bundan sonra bağlamımız sınıf/arayüz gibi tip seviyesi olacaktır.) Bu durumda bir sınıfı anlamak için bağımlı olduğu sınıf(lar)ı anlamak gereklidir. Benzer şekilde böyle bir sınıfı değiştirmek için bağımlı olduğu sınıf(lar)ı da değiştirmek gerekebilecektir. Bunlar ise karmaşıklığı arttıran ve değişimi zorlaştıran dolayısıyla da maliyeti arttıran, istenilmeyen durumlardır. Bu yüzden bu tür bağımlılığa “pathological coupling” yani “hastalıklı bağımlılık” da denir. 

Yüksek bağımlılık ve düşük bağımlılık.

Bağımlılığı sıfır olan bir sınıftan bahsedemeyiz. Sadece bir sınıfımız varsa, evet bağımlılığı sıfırdır. Yani no coupling! Birbirine bağımlılığı olmayan, bölük pörçük oluşturulmuş sınıflar da bir sistem oluşturmayacağından, bir sistemin sınıfları kendi aralarında bir şekilde bir bağımlılığa sahip olmak zorundadırlar. Bu noktada bağımlılığın keyfiyeti önemlidir. İçerik bağımlılığı, bir sınıf, bir başka sınıfın iç yapılarına ulaşmasıdır dedik. Yani bir sınıfın üye değişkenleri (sınıf ve nesne değişkenleri) dışarıdan erişilebiliyorsa, içerik bağımlılığı oluşur. Bu anlamda bir başka sınıfın üye değişkenlerine erişmek ya da onları değiştirmek, içerik bağımlılığıdır. Bir sınıfın üye değişkenleri dış erişime karşı korunmuyorsa, diğer sınıflar sıklıkla bu değişkenlere ulaşıyorlar demektir. Bu durumda o sınıf hizmet yerine veri sağlıyor demektir. Yani diğer sınıflar, söz konusu sınıf üzerinde metot çağrısı yapmak yerine veri alış verişi yapıyorlar demektir. Örneğin aşağıdaki Date sınıfı bu türden bir sınıftır:

public class Date {
	
	private int day;
	private String month;
	private int year;

	public Date(int day, String month, int year) {
		this.day = day;
		this.month = month;
		this.year = year;
	}

	public int getDay() {
		return day;
	}

	public void setDay(int day) {
		this.day = day;
	}

	public String getMonth() {
		return month;
	}

	public void setMonth(String month) {
		this.month = month;
	}

	public int getYear() {
		return year;
	}

	public void setYear(int year) {
		this.year = year;
	}

	public String toString() {
		return "Date: " + day + " - " + month + " - " + year;
	}
}

Pek çok programcı, Date sınıfının nesne-merkezli olduğunu iddia edecektir. Çünkü sarmalama (encapsualtion) kurallarına uyulmuş, yani alanlar private yapılmış ve doğrudan erişim engellenmiştir. Aslında yukarıdaki sınıf, tarih ile ilgili sadece veri taşımakta bundan dolayı da diğer sınıflarla arasında oluşacak olan bağımlılığin seviyesi içerik olarak kalacaktır. Yani Date sınıfı hizmet değil, veri sağlayacaktır. Bundan dolayı örneğin bir Date nesnesine sahip olup da ertesi günü elde etmek isteyen bir başka nesne, ya da Date nesnesini farklı formatlarda basmak isteyen bir diğer nesne, Date nesnesinden get metotlarıyla bilgi alacak ve bu fonksiyonlari kendileri yerine getireceklerdir. Yani örneğin “ertesi gün” hizmeti Client1 nesnesi tarafından şöyle geliştirilmiş olabilir:

/**
 * Client1 is the class that calculates next day of a given Date.
 * 
 * @author akin
 * 
 */
public class Client1 {

	public Date getNextDay(Date date) {

		int day = date.getDay();
		String month = date.getMonth();
		int year = date.getYear();

		// First check wrong days and months
		if (day > 31) {
			System.out.println("Wrong date entered: " + date);
			System.exit(1);
		}

		if (year < 0) {
			System.out.println("Wrong date entered: " + date);
			System.exit(1);
		}

		if (!isMonthCorrect(month)) {
			System.out.println("Wrong date entered: " + date);
			System.exit(1);
		}

		// February is a special case so handle it separately
		if (month.equalsIgnoreCase("February") || month.equalsIgnoreCase("Subat")) {
			if (day == 28) {
				boolean isLeapYear = isLeapYear(year);
				if (isLeapYear)
					day = 29;
				else {
					day = 1;
					month = "March";
				}
			} else if (day == 29) {
				boolean isLeapYear = isLeapYear(year);
				if (isLeapYear) {
					day = 1;
					month = "March";
				} else {
					System.out.println("Wrong date entered: " + date);
					System.exit(1);
				}
			} else if (day == 30 || day == 31) {
				System.out.println("Wrong date entered: " + date);
				System.exit(1);
			} else {
				day++;
			}
			date.setDay(day);
			date.setMonth(month);

			return date;
		}

		// For other months
		if (day < 30)
			day++;
		else {
			if (day == 30) {
				day = 1;
				if (month.equalsIgnoreCase("April") || month.equalsIgnoreCase("Nisan"))
					month = "May";
				else if (month.equalsIgnoreCase("June") || month.equalsIgnoreCase("Haziran"))
					month = "July";
				else if (month.equalsIgnoreCase("September") || month.equalsIgnoreCase("Eylul"))
					month = "October";
				else if (month.equalsIgnoreCase("November") || month.equalsIgnoreCase("Kasim"))
					month = "December";

			} else if (day == 31) {
				day = 1;
				if (month.equalsIgnoreCase("January") || month.equalsIgnoreCase("Ocak"))
					month = "February";
				else if (month.equalsIgnoreCase("March") || month.equalsIgnoreCase("Mart"))
					month = "April";
				else if (month.equalsIgnoreCase("May") || month.equalsIgnoreCase("Mayis"))
					month = "June";
				else if (month.equalsIgnoreCase("July") || month.equalsIgnoreCase("Temmuz"))
					month = "August";
				else if (month.equalsIgnoreCase("August") || month.equalsIgnoreCase("Agustos"))
					month = "September";
				else if (month.equalsIgnoreCase("October") || month.equalsIgnoreCase("Ekim"))
					month = "November";
				else if (month.equalsIgnoreCase("December") || month.equalsIgnoreCase("Aralik")) {
					month = "January";
					year++;
				}
			}
		}

		date.setDay(day);
		date.setMonth(month);
		date.setYear(year);

		return date;
	}

	private boolean isLeapYear(int year) {
		boolean isLeapYear = false;

		// divisible by 4
		isLeapYear = (year % 4 == 0);

		// divisible by 4 and not 100
		isLeapYear = isLeapYear && (year % 100 != 0);

		// divisible by 4 and not 100 unless divisible by 400
		isLeapYear = isLeapYear || (year % 400 == 0);

		return isLeapYear;
	}

	private boolean isMonthCorrect(String month) {
		boolean isCorrectMonth = false;
		if (month.equalsIgnoreCase("January") || month.equalsIgnoreCase("February") || month.equalsIgnoreCase("March")
				|| month.equalsIgnoreCase("April") || month.equalsIgnoreCase("May") || month.equalsIgnoreCase("June")
				|| month.equalsIgnoreCase("July") || month.equalsIgnoreCase("August")
				|| month.equalsIgnoreCase("September") || month.equalsIgnoreCase("October")
				|| month.equalsIgnoreCase("November") || month.equalsIgnoreCase("December") ||
				month.equalsIgnoreCase("Ocak") || month.equalsIgnoreCase("Subat") || month.equalsIgnoreCase("Mart")
				|| month.equalsIgnoreCase("Nisan") || month.equalsIgnoreCase("Mayis")
				|| month.equalsIgnoreCase("Haziran") || month.equalsIgnoreCase("Temmuz")
				|| month.equalsIgnoreCase("Agustos") || month.equalsIgnoreCase("Eylul")
				|| month.equalsIgnoreCase("Ekim") || month.equalsIgnoreCase("Kasim")
				|| month.equalsIgnoreCase("Aralik"))
			isCorrectMonth = true;

		return isCorrectMonth;
	}
}

Verilen bir Date nesnesini farklı formatlarda basan Client2 sınıfına bir bakalım:

/**
 * Client2 is the class that prints a given Date in different formats.
 * 
 * @author akin
 * 
 */
public class Client2 {

	public void printDate1(Date date) {
		int day = date.getDay();
		String month = date.getMonth();
		int year = date.getYear();
		System.out.println("Date (dd-mm-yyyy): " + day + " - " + month + " - " + year);
	}

	public void printDate2(Date date) {
		int day = date.getDay();
		String month = date.getMonth();
		int year = date.getYear();
		System.out.println("Date (mm-dd-yyyy): " + month + " - " + day + " - " + year);
	}

	public void printDate3(Date date) {
		int day = date.getDay();
		String month = date.getMonth();
		int year = date.getYear();
		System.out.println("Date (dd/mm/yyyy): " + day + " / " + month + " / " + year);
	}
	
	public void printDate4(Date date) {
		int day = date.getDay();
		String month = date.getMonth();
		int year = date.getYear();
		System.out.println("Date (mm/dd/yyyy): " + month + " / " + day + " / " + year);
	}

}

Eğer Client1 ve Client2 gibi bir sınıf bir hizmeti yerine getirmek, bir şeye karar vermek vb. için bir başka sınıfın iç yapılarına ulaşıyor ya da ondan veri alıyorsa, bu sınıfların aralarındaki bağımlılık yüksektir. Bu durumda Client1 ve Client2 sınıflarını anlamak içın Date sınıfını anlamaya, Date sınıfını değiştirdiğinizde de muhtemelen bu iki sınıfı değiştirmeye ihtiyacınız olacak demektir. Bu şekilde bağımlılığı yüksek olan sınıfların birliktelikleri de (cohesion) düşüktür ya da bir başka deyişle, Date sınıfı tarih kavramının hepsini halletmek yerine sadece bir kısmını halletmekte, bundan dolayı da diğer kısımları farklı yerlerde halledilmektedir. Yani tarih ile ilgili veri ve hizmet bir yerde toplanmayıp, pek çok yere dağılmıştır. Bir de birbirinden habersiz programcıların, bu türden Date üzerine hizmet veren metotları farklı yerlerde farklı şekillerde yazdıklarını düşünün. İşte, iyi programcılarla iyi bir yazılım geliştirilmemesinin en temel sebebi budur. İyi futbolculardan iyi bir takım olmamasına karşın, vasat ama iyi organize olmuş oyunculardan oluşmuş takımın daha iyi performans göstermesi gibidir bu durum. İlki program yazan programcılardır, ikincisi ise yazılım geliştiren bir takımdır. Yukarıdaki Date sınıfının içerik bağımlılığından kurtarmanın yolu, bu sınıfın veri taşıyıp dağıtmasının önüne geçmektir. Date ya da bir sınıf veri taşımak için kurgulanmamalıdır, hizmet vermek için kurgulanmalıdır. Yani, Client1 ve Client2‘deki servisler aslında Date sınıfında olmalıdır. Diğer sınıflar da Date‘den veri yerine hizmet almalıdırlar. Böyle bir yapıdaki Date sınıfının arayüzü pekala şöyle bir DateI arayüzü ile temsil edilebilir:

/**
 * DateI represents date related services to be implemented in subclasses. 
 * @author akin
 *
 */
public interface DateI {

	public abstract String toString();

	public abstract String print();

	public abstract String printShort();

	public abstract String printLong();

	public abstract String print(Locale locale);

	public abstract DateI getNextDay();

	public abstract String getWeekDay();

	public abstract String print(Locale locale, DateFormat format);

}

Bağımlılığı sadece arayüz seviyesinde tuttuğumuzda, en sağlıklı bağımlılığa ulaşmış oluruz. Eğer Date sınıfı, DateI arayüzünü implement ederse ya da yerine getirirse, üzerinde sadece hizmet veren metotlar olacak ve veri taşımak yerine hizmet verecektir. DateI‘nin metotlarından bazılarının String döndürdüğüne dikkat edin. Buradaki String taşınan veriden ziyade, hizmet sonucu üretilen nesneyi temsil etmektedir ve kaçılmazdır. Bu anlamda sınıflar arasında gidip gelen veriyi ne kadar az tutarsanız, içerik bağımlılığınız o derece az oalcak ve sisteminizi hem anlamak hem de değiştirmek yani bakımını yapmak o kadar kolay olacaktır. Bu yüzden DateI arayüzünde get/set metotlarının olmadığına dikkat edin. “Getter ve setter metotları şeytandır” diyen Allen Holub‘ı da burada anmakta fayda vardır.

Bu durum GoF tarafından “program to an interface, not an implementation”  yani “arayüze programlama yapın, gerçekleştirmeye değil” şeklinde ifade edilmiştir. Dolayısıyla açık/kapalı prensibi (open/closed principle) olarak bildiğimiz, “genişlemeye açık, değişikliğe kapalı” (open for extension, closed for modification) şeklindeki kurala da uyarsak, DateI‘nin sunduğu arayüz hiç bir zaman değişmeyecek demektir. Bu durumda Date sınıfını kullanan yani odnan hizmet olan hiç bir sınıfın, Date‘deki bir değişiklikten dolayı değişmesi gerekmeyecektir.

Bu yüzden, üç-beş private alanı bir araya getirip, sağ tıkla set/get metotlarını üreterek yapılan şey programlama olabilir ama nesne-merkezli programlama değildir. Bu şekilde program yazılabilir ama o program hiç bir zaman software/yazılım seviyesine çıkmayacaktır.

Amacımız, az bağımlılıklı ve yüksek birliktelikli ya da odaklı (lowly-coupled, highly-cohesive) yazılımlar geliştirmektir. Hemen her türlü yazılım kalitesi temelde bu iki kavram üzerine bina edilir. Bunları göz önüne almadan hangi dili ya da hangi frameworkü kullandığınızın hiç bir önemi yoktur. Ama ben bu türden kodlara o kadar çok ve sık rastlıyorum ki.

Bağımlılığı az, birlikteliği yüksek insan ve programcı olmak ümidiyle…

Toplam görüntülenme sayısı: 1665