Geliştirdiğimiz Java kodunun nesne-merkezli olmadığının 10 işaretinin neler olduğunu bu yazıda listelemiş ve ilk yedi maddeyi daha önce ele almıştık. Şimdi de sekizinci maddeyi inceleyelim:

Demeter prensibini ihlal eden metotlara. (Methods that break the Demeter law.)

Demeter prensibi, bir nesnenin metotlarının, hangi nesnelerin metotlarını çağırabileceğini belirler. Buna göre bir nesnenin metotlarında, kendisi üzerinde metot çağrısı yapabileceği nesneler ancak şunlar olabilir:

• kendisi,
• nesne değişkenleri,
• metoda geçilen parametre nesneler,
• metotta oluşturulan nesneler.

Yani bir nesne ancak arkadaşlarıyla konuşur, yabancılarla konuşmaz.

Bu durumu bir örnekle açıklayalım: 

public class A{
   private B b;
	
   public void f(C c){
      h();                      // 0- Yapılabilir    
      b.g();		    	// 1- Yapılabilir
      c.u();		    	// 2- Yapılabilir
      D d = new D()
      d.v();		    	// 3- Yapılabilir
      E e = c.w();      
      e.z();	  //4- Yapma bunu! E’den iş isteme, C’den,                       //E'den iş istemesini talep et.
   }

   public void h(){
      ...
   }
}

Bir nesnenin metotdunda, o nesnenin diğer metotlarını çağırmak son derece tabidir. “0”de ifade edilen durum budur.

Demeter kuralına göre, bir nesnenin bir metodunda, o nesnenin değişkenlerinden olan nesneler üzerinde metot çağrısı yapabilirsiniz. “1”de ifade edilen durum budur. Bu normaldir çünkü, nesne değişkenleri, nesnenin parçalarıdır, beraber yaşadığı nesnelerdir.

“2”de ifade edilen satırda çağrılan “u()” metodu “f()” metoduna geçilen bir parametre olan “c” nesnesi üzerindeki bir metottur. Bu durum da normaldir çünkü, “c” nesnesi “f()” metoduna zaten işlenmek üzere argüman olarak geçilmektedir.

“3”de ifade edilen satırda çağrılan “v()” metodu da “f” metodunda oluşturulan D tipindeki bir “d” nesnesi üzerindeki bir metottur. Bu durum da normaldir çünkü, “d” nesnesi “f” metodunda zaten ihtiyaç olarak oluşturulmaktadır.

“4”deki durum ise yukarıdaki üç halden farklıdır çünkü bu satırda üzerinde metot çağrısı yapılan “E” tipindeki “e” nesnesi, “A” sınıfının nesnelerinin doğrudan bildiği bir nesne değildir.

Demeter kuralı, bize bir nesnesin sahip olabileceği bağımlılıklarla ilgili bilgi verir, olabildiğince az bağımlılık yaratarak programlama yapmamızı sağlar. Nesne, tabi olarak bildiği nesneler dışında kimseyle konuşmamalıdır, sdece ve sadece yakınında olan nesneleri bilmelidir. Bu yüzden bu prensibe “principle of least information” da denir, yani “en az bilgi prensibi”. Nesneler olabildğince az bilgi bilmelidirler. Nesneler sadece en yakınındaki nesneleri bilmelidirler. Bu durumu şöyle bir örnekle de açıklayabiliriz:

Bir şirkette müdür, müdürün sekreteri ve fotokopici olsun. Müdür bazı belgelerin fotokopisine ihtiyaç duyduğunda yapacağı şey, sekreterinden fotokopiciye gidip o belgelerin fotokopisini çektirmesini istemektir. Bu durumdaki haberleşme şekli makul olandır ve aşağıda gösterilmiştir:

Bir de şu durumu düşünün: Müdür sekreterden bunu istemek yerine, sekretere, “bana fotokopiciyi cağırır mısın” diye istekte bulunsa, müdür aslında konuşmaması gereken bir nesneye ulaşmış olacak ve konuşµa hiyerarşisi bozulacaktır. Bu durumu şöyle resmedebiliriz:

Demeter kuralına uymak, paketler, modüller, bileşenler ve katmanlar arasındaki haberleşmeyi düzenler. Demeter kuralına uymadığımızda bağımlılığı (coupling) yüksek yapılara sebep oluruz. Bu durumda da yazılımlarımızın bakımını yapmak çok zor olur, özellikle değişiklik yapmak çok maliyetli hale gelir.

PMD‘nin Coupling ölçütünün ölçümlerinden birisi de LawOfDemeter’dir ve burada bahsettigimiz prensibe uymayan erişimleri raporlar.

Kodda bu kuralı ihlal eden en temel kalıp, zincirleme erişimdir. Yani

...
Object o = a.getB().getC().getD().calculate();
...

şeklindeki kullanımlar aslında birbirlerinden hiç haberdar olmayan a nesnesi ve D‘nin nesnesini birbirine bağımlı kılar. Bir başka deyişle a nesnesi, hiç gerekmediği halde D‘nin nesnesini bilir, onun API’sinden haberdar olur, dondürdüğü değeri alır.

Bu tür zincirleme erişimlerin makul olabileceği yerleri düşündüğümüzde ilk akla gelen web katmanındaki view yapılarıdır. Örneğin, Java’nin web bileşenlerinden JSF kullandığınızda, view sayfalarında, arkadaki managed beanlere ulaşırken bu şekilde zincirleme özellik ulaşımı yaparsınız. Pek çok Java EE yapısı da açıkçası bu şekilde zincirleme erişimle çalışır. Fakat iş mantığı içınde ya da örneğin katmanlar arasında bu şekilde kısa yollar kurmak son derece sıkıntılıdır.

Demeter kuralı önemlidir, uyarak kod yazmak kodumuzu çok daha kaliteli kılacaktır.

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

Geliştirdiğimiz Java kodunun nesne-merkezli olmadığının 10 işaretinin neler olduğunu bu yazıda listelemiş ve ilk altı maddeyi daha önce ele almıştık. Şimdi de yedinci maddeyi inceleyelim:

Karmaşık metotlar. (Complex methods.)

Aslında bu madde ile bir önceki madde (Çok sayıda metoda sahip olan sınıflar.) yapı olarak benzer özelliklere sahipler. Bu iki madde, nesne-merkezli yazılımlar için yazılım kalitesinin en temel ölçütlerindendir. Bir sınıfın sahip olduğu metot sayısı ile metotların karmaşıklık düzeyi, nesne-merkezli kod parçasının kalitesini hızlı bir şekilde ortaya koyar.

Bir sınıftaki metotların karmaşıklık düzeyini belirleyen temelde 3 etmen vardır: Metodun satır sayısı, metoda geçilen parametre sayısı ve metodun içinde verilen kararların sayısı.

Metotların uzunluğu, en basit karmaşıklık ölçütü olarak görülebilir. Ne kadar kısa metot, o kadar kaliteli kod. Ya da tersinden bakarsak ne kadar uzun metot, o kadar karmaşık kod. Uzun metot, çok iş demektir. Muhtemelen de farklı metotlarda yapılabilecek pek çok işi bir arada yapmak demektir. Halbuki her metot sadece ve sadece bir iş yapmalıdır.

“Clean Code” adlı kitabında R. Martin, sınıflar içın söylediği iki cümleyi metotlar için de tekrarlıyor:

“The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that.”

Yani

“Fonksiyonların ilk kuralı, onların küçük olması gerektiğidir. Fonksiyonların ikinci kuralı ise onların bundan da küçük olması gerektiğidir.”

Metotlar, iş gören yapılardır. Metotların gördüğü işler farklı seviyelerde olabilir. Bazen metotlar bir süreci başlatırlar, bazen başlatılan sürecin içindeki adımlardan birini yerine getirirler, bazen de o bir adımın içinde çok basit bir şey yaparlar.  Nesne oluşturmak ya da bir süreci yönetmek ya da ya da vergiyi hesaplamak gibi çok basit bir iş yapmak şeklinde vb. Her halukarda bir metotta tek bir iş yapılmalı. Örneğin aşağıdaki metodlarla bu durumlu açıklayalım:

public void login(String tckn, String password) throws NoSuchCustomerException, CustomerAlreadyLoggedException, WrongCustomerCredentialsException, MaxNumberOfFailedLoggingAttemptExceededException, CustomerLockedException;

login() metodunun, örneğin bir web uygulamasında web katmanından çağrılan CustomerService isimli bir servis nesnesi metodu olduğunu düşünelim. Belli ki bu metot, kullanıcı bilgileriyle, o kullanıcıyı uygulamaya kabul eden sürecin başladığı yerdir. Ve bu metotdun fırlattığı sıra dışı durumlara bakınca, bu metotta öyle bir müşteri olup olmadığına karar verilmesinden, müşterinin sistemle kilitli durumda olduğunun anlaşılmasına kadar pek çok iş yapılıyor.

	@Override
	public void login(String tckn, String password) throws NoSuchCustomerException, CustomerLockedException,
			CustomerAlreadyLoggedException, WrongCustomerCredentialsException,
			MaxNumberOfFailedLoggingAttemptExceededException {
		Customer customer = customerDao.retrieveCustomer(tckn);

		// If passwords match, customer hasn't already been locked nor logged in
		// Customer loggs in and it is now currentCustomer
		if (customer.getPassword().equals(password) & !customer.isLocked() & !customer.isLoggedIn()) {
			// customer.logsin is a property in atm.properties. If it is "yes"
			// database is updated when
			// a customer logs in. Updated part in db is CUSTOMERS.LOGGEDIN
			customer.setLoggedIn(true);
			if (customerDao.updateCustomer(customer))
			currentCustomer = customer;
			loginAttemptCount = 0;
		} else if (customer.isLoggedIn()) {
			throw new CustomerAlreadyLoggedException("Customer is already logged in. Please first log out.");
		} else if (customer.isLocked()) {
			throw new CustomerLockedException("Customer is locked. Please consult your admin.");
		} else if (!customer.getPassword().equals(password)) {
			loginAttemptCount++;
			if (loginAttemptCount == Integer.parseInt(ATMProperties.getProperty("customer.maxFailedLoginAttempt"))) {
				customer.setLocked(true);
				customerDao.updateCustomer(customer);
				throw new MaxNumberOfFailedLoggingAttemptExceededException("Max number of login attempt reached: "
						+ loginAttemptCount);
			}
			throw new WrongCustomerCredentialsException("TCKN/password is wrong.");
		}
	}

Bu şekilde, bir süreci başlatan metotlara ihtiyaç pek tabi ki vardır ama bu durum devasa metotlar yazmamızı gerektirmez. Çok açık ki bu metot çok iş yapıyor. Önce “customerDao” üzerinden Customer nesnesini getiriyor. Daha sonra nesnenin üzerindeki bilgilere bakarak o nesnenin temsil ettiği müşterinin sisteme girip giremeyeceğine karar veriyor. Bunun için de hem password kontrolü yapıyor ve yanlış password girildiğinde kilitlenme sayısına gelip gelmediğini anlıyor, hem de müşterinin zaten sistemde olup olmadığını ve daha önceden kilitlenip kilitlenmediğini kontrol ediyor. Bu metot belki şu şekilde daha sağlıklı yazılabilirdi:

	public void login(String tckn, String password) throws NoSuchCustomerException, CustomerLockedException,
			CustomerAlreadyLoggedException, WrongCustomerCredentialsException,
			MaxNumberOfFailedLoggingAttemptExceededException {
		Customer customer = customerDao.retrieveCustomer(tckn);
		loginCustomer(customer, password);
	}

Yukarıdaki login metodunun ilk haliyle sonraki, iyileştirilmiş halini kiyasladığımızda, ikinci halin çok daha kısa ve anlaşılır olduğunu, çünkü sadece tek bir iş yaptığını görebiliriz. login() metodu, login için gerekli sürecin adımlarını sırayla çağırarak, müşterinin sisteme dahil olmasını sağlamakta, varsa oluşan sıra dışı durumları bir üst ortama aktarmaktadır. Orijinal halinde bu metotta olan adımlar ise farklı beş metoda dağılmıştır:

	private void checkIfCustomerAlreadyLoggedIn(Customer customer) throws CustomerAlreadyLoggedException {
		if (customer.isLoggedIn()) {
			throw new CustomerAlreadyLoggedException("Customer is already logged in. Please first log out.");
		}
	}

	private void checkIfCustomerLocked(Customer customer) throws CustomerLockedException {
		if (customer.isLocked()) {
			throw new CustomerLockedException("Customer is locked. Please consult your admin.");
		}
	}

	private void checkCustomerPassword(Customer customer, String password) throws CustomerLockedException,
			MaxNumberOfFailedLoggingAttemptExceededException, WrongCustomerCredentialsException {
		if (!customer.getPassword().equals(password)) {
			loginAttemptCount++;
			checkLoginAttempCount(customer);
			throw new WrongCustomerCredentialsException("Wrong password!");
		}
	}
	
	private void checkLoginAttempCount(Customer customer) throws MaxNumberOfFailedLoggingAttemptExceededException{
		if (loginAttemptCount == Integer.parseInt(ATMProperties.getProperty("customer.maxFailedLoginAttempt"))) {
			lockCustomer(customer);
		}
	}
	
	private void lockCustomer(Customer customer) throws MaxNumberOfFailedLoggingAttemptExceededException{
		customer.setLocked(true);
		throw new MaxNumberOfFailedLoggingAttemptExceededException("Max number of login attempt reached: "
				+ loginAttemptCount);
	}

Yukarıdaki beş metodun her birisinin sadece ve sadece bir iş yaptığına dikkat edin.

Bence idealde metotlarımız bu kadar kısa, üçer-beşer satırdan ibaret olmalı. Eskiden fonksiyonların bir ekrandan daha uzun olmaması gerektiği söylenirdi. Benim 15’lik makinamda, Eclipse’de 11 puntoluk Consolas ile tam 80 satır, aşağıya doğru kaydırmaya gerek kalmadan tek bir ekranda görünüyor. 80 satır bir metot için çok!

R. Martin Clean Code’da, bir metodun olabildiğince 20 satırı geçmemesi gerektiğini söyler. “Refactoring in Large Software Projects” isimli kitapda da  M. Lippert ve S. Roock, mimari kötü kokulardan bahsederken bir metodun ortalama olarak 30 satırı geçmemesi gerektiğinden bahseder.

Sınıfların karmaşıklık ölçütlerinden bahsederken metot sayısını ele almış ve karşı örnekleri de göstererek, bu durumun problemlerinden bahsetmiştik. Benzer durum metotların karmaşıklığını satır sayısıyla ölçerken de geçerli. Bu konuda Steven C. MacConnell’in Code Complete kitabındaki tartışmaya bakablirsiniz.

Bir metodun aldığı argüman sayısı da o metodun karmaşıklığı hakkında bize bilgi verir. İdealde bir metoda geçilen parametre sayısının sıfır olmasını bekleriz. Bu durumda o metodu kodlamak, anlamak, test etmek vs. çok daha kolay olur. Kendisine hiç parametre geçilmediği halde içinde tonla iş yapan metot yazmak elbette mümkündür ama sonuçta satır sayısı gibi bu ölçüt de mutlak olmayıp, bize kötü kokular veren cinstendir. Gerçekte bir motodun aldığı argüman sayısı, o metodun API tasarım kalitesini belirler. Parametre sayısı constructor ve factory metotlarıyla façade rolü olan sınıfların metotlarında artabilir ama bir sistemdeki metotlara geçilen parametrelerin ortalama sayısının olabildiğince 1 civarında olması tercih edilir. PMD Code Size ölçütünün ölçümlerinden biri olan ExcessiveParameterList’de uyarı seviyesini 10 olarak belirlemiştir. Yani 10’dan fazla parametre alan metotların gözden geçirilmesini tavsiye etmektedir.

Bir diğer metot karmaşıklığı ölçütü de “Cyclomatic Complexity” denen ve 1976 yılında MacCabe tarafında geliştirilmiş olan ölçüttür. Dilimize karar karmaşıklığı olarak da çevrilebilecek bu ölçüt, bir metotta alınan kararların sayısı üzerine bina edilmiştir. Dolayısıyla bir metotaki if-else, switch-case, while, for gibi karar mekanizmaları ne kadar az kullanılırsa o kadar sağlıklı metotlara sahip oluruz. PMD Code Size ölçütünün ölçümlerinden biri olan CyclomaticComplexity’de uyarı seviyesini 10 olarak belirlemiştir. Yani 10’dan fazla karar mekanizmasına sahip olan metotların gözden geçirilmesini tavsiye etmektedir. Bu konuyu ileride daha geniş ele almak üzere burada bırakalım.

Metotlar, kodumuzun ana yapılarındandır. Bu yüzden metotların basitliği ve anlaşırlığı, sistemimizin basitliği ve anlaşırlığını belirler. Unutmayalım, “küçük güzeldir” (small is beautiful).

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