Design Patterns: Strategy

 

მეგობრებო, განვაგრძობ პროგრამირების სფეროში არსებული თემების მიმოხილვას. ამ კონკრეტულ პოსტში მიმოვიხილავ Behavioral Design Pattern [ქცევითი დიზაინის ნიმუშები] - ის ერთ-ერთ კონკრეტულ ელემენტს, რომელსაც Strategy  [სტრატეგია] ეწოდება. სტრატეგია გვაძლევს საშუალებას დიდი ალგორითმი/ლოგიკა დავყოთ პატარ-პატარა ალგორითმების ოჯახად და runtime-ის დროს გამოვიყენოთ ოჯახის კონკრეტული წევრი, რომელიც გვჭირდება და არ მოვარგოთ ერთი უზარმაზარი ლოგიკა ყველაფერს. მოდით განვიხილოთ ეს ყველაფერი კონკრეტულ მაგალითზე. დავუშვათ გვაქვს ევროკავშირის ქვეყნებში ფულის გადარიცხვის სისტემა  და ბიზნესისგან შემოვიდა Task [დავალება] რომ მომხმარებელს გამოვუთვალოთ და დავუბეჭდოთ თუ რა იქნება გადარიცხვის საკომისიო, ანუ გადასარიცხი თანხის გარდა კიდევ დამატებით რა ღირებულების გადახდა მოუწევს. ვიცით გადასარიცხი თანხა, ქვეყანა, ბანკი და ანგარიშის ნომერი საიდანაც ვრიცხავთ და ასევე ქვეყანა, ბანკი და ანგარიშის ნომერი სადაც ამ თანხას ვრიცხავთ. 

    

როგორც კოდის ფრაგმენტიდან ჩანს, ვქმნით MoneyTransfer კლასის ობიექტს. ამ კლასს აქვს ალგორითმი CalculateTransferFee() რომელიც ითვლის საკომისიოს და შემდგომ შედეგს ვბეჭდავთ კონსოლში:  

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

მოდით ჩავიხედოთ კლასის ამ მეთოდში და გავარკვიოთ თუ როგორ არის კოდი ორგანიზებული.

 საკომისიო ითვლება ქვეყნებისა და ბანკების მიხედვით. როგორც კოდიდან ჩანს, ჩვენი სისტემისთვის ამ მომენტში შესაძლებელია მხოლოდ იტალიისა და საფრანგეთის ბანკებში გადარიცხვა, მაგრამ ბიზნესის ცვალებასთან ერთად იზრდება მოთხოვნებიც. ადვილად შესაძლებელია რომ დაემატოს, მაგალითად  ესპანეთი, გერმანია, ბელგია და ა.შ. ეს ყოველივე გამოიწვევს ჩვენი ალგორითმის გაზრდას, რის შედეგადაც, სისტემის runtime-ის დროს თუ მჭირდება მხოლოდ ბელგიაში გადარიცხვა, მომიწევს იმ მეთოდის გამოძახება, რომელშიც აღწერილია ევროკავშირის ყველა ქვეყნის ლოგიკა სადაც სისტემას გადარიცხვა შეუძლია. Strategy პატერნს შეუძლია ეს პრობლემა თავისებურად გადაგვიჭრას: შევქმნათ ITransferStrategy ინტერფეისი, რომელშიც განვსაზღვრავთ CalculateTransferFee კონტრაქტს:

ინტერფეისის შექმნის შემდეგ საჭიროა საკომისიოს გამოთვლის სხვადასხვა იმპლემენტაციები, რადგან გვაქვს სხვადასხვა ქვეყნები. ამისათვის ვიქცებით შემდეგნაირად:  ვქმნით კლასებს და ამ კლასებში ვაიმპლემენტირებთ ჯერ ITrasferStrategy ინტერფეისს  და შემდგომ ინტერფეისში კონტრაქტით აღწერილ მეთოდს.

როგორც ხედავთ შევქმენით ორი კლასი : ItalyTransferStrategy და FranceTransferStrategy რომლებიც ცალ-ცალკე აიმპლემენტირებენ საკომისიოს გადარიცხვის ლოგიკებს. ისღა დაგვრჩენია MoneyTransfer კლასში არსებული ლოგიკა გავამარტივოთ.

შედეგი სახეზეა. ობიექტი, რომელიც ITransferStrategy ინტერფეის აიმპლემენტირებს დავამატეთ როგორც კლასის property : _transferStrategy. MoneyTransfer-ის ობიექტის შექმნის დროს ის შეიძლება იყოს ItalyTransferStrategy ან FranceTransferStrategy. CalculateTransferFee() მეთოდს უწევს მხოლოდ  ინტერფეისში კონტრაქტით აღწერილი  მეთოდის გამოძახება, რომელსაც  გადასცემს საკუთარ თავს. კოდის ორგანიზება საკმაოდ გაუმჯობესდა და CalculateTransferFee მეთოდი განიტვირთა. ეხლა შევხედოთ თუ როგორ ვიყენებთ Main მეთოდში ამ ყოველივეს. 

 

Main-ში უკვე runtime-ის დროს ვარკვევთ რომელი ქვეყანა აირჩია გადასარიცხად, შესაბამისად moneTransfery ობიექტს ვანიჭებთ კონკრეტულ სტრატეგიას property-ს სახით, რათა გამოთვალოს გადარიცხვის საკომისიო. ამით Strategy დიზაინის ნიმუშმა შეასრულა მასზე დაკისრებული ვალდებულება და CalculateFee-ს დიდი ალგორითმი დაყო პატარა ნაწილებად და თუ რომელი ნაწილია საჭირო, მაგას runtime-ის დროს სისტემა თვითონ საზღვრავს.