Factory Pattern

Factory pattern en yaygın tasarım kalıplarındandır. Yapı itibari ile creational, yani obje yaratma süreçleriyle ilgilenen bir kalıptır. Benzer özellikleri taşıyan, ayrı obje türlerinin yaratılması esnasında, bu farklı objelerin yaratılma sürecinin, tüketici sınıf veya uygulama tarafından bilinmesinin gereksiz olduğu mantığı üzerine kurulu şekilde konumlanır.

Bu kalıbı genel bir tanım ihtiyacı olduğunda ve bu tanımın detaylarının soyutlanması gerektiğinde kullanırız. Son dönemlerde hayatımızda yer edinen, market alışverişlerimizi internet üzerinden yaptığımız uygulamaları düşünün. Bu uygulamalarda eğer teslimatınız büyük bir paketi içeriyorsa kuryeniz bir ticari araç ile teslimat yaparken, daha küçük siparişleri ise motosikletli bir kurye getirmektedir. Ancak tüketici olarak bunu yönetmek durumunda kalmazsınız. Dahası, bunu yönetmek size ekstra bir fayda sağlamayacağı gibi, kullandığınız mobil uygulamanın süreçlerini de anlamsız bir şekilde uzatacaktır. O halde, burada teslimatın hangi yöntemle yapılacağı bilgisiyle ilgilenmeden siparişimizi verebilmeliyiz. Fakat sisteme işlenen siparişin yaratılması esnasında, teslimatın ayrı şekillerde yapılabilmesinin mümkün olması ve bunun da müşteri tecrübesini etkilemeyecek bir yöntemle halledilebilmesi gerekmektedir.

Bu durumu yönetebilmek için factory pattern son derece etkili bir yöntemdir. Yukarıdaki sınıf şemasında az evvel bahsettiğimiz sorunun, factory pattern ile bir çözümünü görmektesiniz. Burada dikkat edilmesi gereken 2 nokta vardır.

  • Teslimat iki ayrı şekilde mümkündür. Bunların kod seviyesinde yönetimini kolaylaştırmak adına gerek Truck gerekse Motocycle sınıflarımız aynı interface üzerinden türetilmiştir.
  • Teslimatın tamamlanması esnasında hangi methodun kullanılacağını MobilApp sınıfı belirlemektedir. Ancak sadece teslimat yöntemi konusundaki isteğini belirtir. Bunu da DeliveryFactory sınıfına iletmektedir. Sonrasında olan biten ile ilgilenmez.

Şimdi de kod üzerinden bu şemanın uygulanmış halini görelim.

public interface Delivery {
	
	void deliver();
	
}
public class Motocycle implements Delivery {

	@Override
	public void deliver() {
		System.out.println("This is a 'Motocycle' Delivery");
	}

}


public class Truck implements Delivery {

	@Override
	public void deliver() {
		System.out.println("This is a 'Truck' Delivery");
	}

}
public class DeliveryFactory {

	public static Delivery getDeliveryVehicle(String deliveryChoice) {
		
		if ("Truck".equals(deliveryChoice)) {
			return new Truck();
		}
		
		return new Motocycle();
	}
}
public class MobilApp {

	private int orderSize;
	
	public void completeOrder() {
		
		Delivery delivery;
		
		if(this.orderSize > 10) {
			delivery = DeliveryFactory.getDeliveryVehicle("Truck");
		} else {
			delivery = DeliveryFactory.getDeliveryVehicle("Motocycle");
		}
		
		delivery.deliver();
	}

	public int getOrderSize() {
		return orderSize;
	}

	public void setOrderSize(int orderSize) {
		this.orderSize = orderSize;
	}
	
}

Şimdi de bu kurguyu test etmek üzere main methodu olan bir sınıf yazalım. MobilApp sınıfına dikkat ederseniz teslimatın hangi yöntemle yapılacağı siparişin boyutuna göre belirlenmiş durumda. Dolayısı ile iki teslimat durumunu da test edecek bir kod yazacağız.

public class Test {

	public static void main(String[] args) {
		
		MobilApp mobilApp = new MobilApp();
		
		//Truck Delivery
		mobilApp.setOrderSize(15);
		mobilApp.completeOrder();
		
		
		//Motocycle Delivery
		mobilApp.setOrderSize(5);
		mobilApp.completeOrder();
		
	}

}
Çıktı:
This is a 'Truck' Delivery
This is a 'Motocycle' Delivery

Factory tasarım kalıbının kullanılmasına dair örneğimizi bitirmiş olduk. Bu kalıp sayesinde mobil uygulama ve teslimat yapan sınıflar arasında doğrudan bir bağlantı kurmamış olduk. Böylece her sınıf kendi sorumluluk alanında kalmış oldu ve uygulama mantığı iç içe girmemiş oldu. Ayrıca DeliveryFactory sayesinde, uygulamamıza yeni teslimat methodları geldiğinde, uygulamaya etki vermeden bu methodları arttırabilir durumda olacağız. Ancak, bu implementasyonların sayısı arttıkça hem factory sınıfımızın kendisini hem de factory sınıfını kullanan aracıları büyütmemiz gerekecektir. Bu da giderek karmaşıklaşan bir silsileye dönüşme riski taşımaktadır.

1 comment on Factory Pattern

Leave a Reply

Your email address will not be published. Required fields are marked *