Strategy Pattern

Stragegy patern.   ასევე ლიტერატურაში შეიძლება შეგხვდეს მისი სახელწოდეა როგორც  Policy pattern. მისი საშვალებით ალგორითმის ქცევის არჩევა ძალზედ მარტივად ხდება. იმას, თუ რომელი ალგორითმი იქნება გამოყენებული, კლიენტი განსაზღვრავს.

 დამავწყდა მეთქვა, რომ, ეს დიზაინ პატერნი Creational pattern ოჯხს განეკუთნება.

ამ დიზაინ პატერნის სტრუქტურა ასეთია:

როგორც სურათზე ხედავთ, გვაქვს სტრატეგიის ინტერფეისი, რომელთა მრავალი იმპლემენტაცია შეილება გვქონდეს–  მაგალითად გვინდა Payment ის შესრულება. იგი შეიძლება შესრულდეს Visa ელექტრონით, შეიძლება MasterCard -ით.

ალგორითმი უსმენს კლიენტს და იმ იმპლემენტაციას უშვებს რომელიც მოთხოვნას შეესაბამება. მოსმენას და შესაბამის სტრატეგის ალგორითმის გამოძახებას Context  ემსახურება.

დავიწყოთ მაგალითის წერა, და  თან განვმარტოთ. თავდაპირველად, გადახდისთვის გავაკეთოთ enum, რომლებითაც იქნება შესაძლებელი გადახდა.

	/**
	* @author v.koroghlishvili
	* Enum for Payment methods
	*/
	public enum PaymentType {
	VISA_ELECTRON, MASTERCARD
	}

view raw gistfile1.java hosted with ❤ by GitHub

შემდეგ ამ ენამიდან რომელიმეს Context–ს გადავცემთ.  თუ სხვა ჯერზე ფეიმენთის გაკეთება  გადახდის სხვა ტიპით მომინდება, უბრალოდ  კონტექტს ვეტყვი ამ ყოველივეს.

	/**
	*
	* @author v.koroghlishvili
	*
	*/
	public class PaymentContext {
	private PaymentRule paymentRule;
	public PaymentContext(PaymentType setting) {
	this.paymentRule = createRule(setting);
	}
	/**
	* This method chooses payment method,
	* using payment type
	* @param setting
	* @return
	*/
	private PaymentRule createRule(PaymentType setting) {
	switch (setting) {
	case MASTERCARD:
	return new VisaElectronRule();
	case VISA_ELECTRON:
	return new MaserCardRule();
	default:
	return null;
	}
	}
	public void cheeckOut(String number) {
	paymentRule.makePayment(number);
	}
	public PaymentRule getValidationRule() {
	return paymentRule;
	}
	}

view raw gistfile1.java hosted with ❤ by GitHub

PaymentContext, რომელიც განსაზღვრავს რომელი implement გაუშვას. აქ მარტივადაა ყველაფერი, switch ით ვნსაზღვრავ საჭიროს. როდესაც კონტესტის ობიექტს შევქმნი, კონსტრუქტორშივე ვახდენ შესაბამისი მეთოდის მინიჭებას.


PaymentRule ინტეფეისი ,რომლის შვილებიც იქნებიან კონკრეტული იმპლემენტაციები. ჩვენს შემთვევაში ერთი მასტერქარდთან მომუშავე, მეორე ვიზა ელექტრონთან. სწორედ კონტექსტში  PaymentRule  შვილის რომელიმე ობიექტს ვქმნი (switch ებში), და ვანიჭებ paymentRuleს, რომელიც არის PaymentRule   ტიპისა.


ახლა დავწეროთ კონკრეტული სტრატეგიის იმპლემენტაციები.

ეს VisaElectron იმპლემენტაცია.  ეს კი უკვე MasterCard–ის:


საბოლოოდ კი ყველაფერი ძალიან მარტივი გვაქ.