MINISTERUL EDUCAŢIEI, CULTURII și CERCETĂRII al REPUBLICII MOLDOVA

UNIVERSITATEA TEHNICĂ a MOLDOVEI

FACULTATEA CALCULATOARE, INFORMATICĂ și MICROELECTRONICĂ
DEPARTAMENTUL INGINERIA SOFTWARE și AUTOMATICĂ

RAPORT la lucrarea de laborator Nr. 6

Disciplina: Tehnici si Mecanisme de Proiectare Software
TEMA: Sablonul de proiectare STRATEGY

Elaborat: st. gr. TI-171 Iepuras Daniel

Verficat: conf. univ. Scrob Sergiu

Chișinău – 2020
Definitie

Defineste o familie de algoritmi, încapsulaza pe fiecare și ii face

interschimbabili. Strategia permite algoritmului să varieze independent de clienții care
îl utilizează.

Structura

Participanti

Strategy
declară o interfață comună tuturor algoritmilor suportați. Context folosește această
interfață pentru a apela algoritmul definit de ConcreteStrategy

ConcreteStrategy  (QuickSort, ShellSort, MergeSort)

implementează algoritmul folosind interfața Strategy

Context   (SortedList)
este configurat cu un obiect ConcreteStrategy, păstrează o referire la un obiect de
strategie, poate defini o interfață care permite Strategiei să acceseze datele sale.

Realizare

Sa presupunem ca o tara vrea sa organizeze doar un campionat doar cu o anumita

categorie. Cream doua clase, una abstracta BelorusiaTournament cu o metoda
startTournament(), a doua clasa Kumite, care descrie doar o categorie a campionatului
creat.

abstract class BelorusiaTournament{

public void startTournament(){
System.out.println("tournament has started");
 }
}

class Kumite extends BelorusiaTournament{

public class Main {

public static void main(String[] args) {
Kumite kumite = new Kumite();
kumite.startTournament();
}

In rezultat nou obtinem “tournament has started”

Din anumite considerente organizatorul campionatului decide sa mai adauge o

categorie in campionat. Pentru aceasta vom trebui sa schimbam programul, iar cea
mai simpla metoda este sa facem metoda startTournament() abstracta si sa o realizam
in clasele categoriilor concrete.

abstract class BelorusTournament{

abstract public void startTournament();
}

class Kumite extends BelorusTournament{

public void startTournament(){
System.out.println("Kumite");
}
}

class Kata extends BelorusTournament{

public void startTournament(){
System.out.println("Kata");
}
}

public class Main{

public static void main(String[] args) {
Kumite kumite = new Kumite();
kumite.startTournament();
}
}

Parca totul lucreaza cum am vrut doar ca apare iarasi problema ca organizatorul mai
doreste o categorie de lupte in campionat. Nu e chiar efficient de schimbat programul
la fiecare dorinta a organizatorului. De accea vom folosi doua principii fundamentale
de proiectare, primul - identificarea aspectelor aplicației care le pot schimba și separa
de cele care rămân mereu constante; al doilea este programarea la nivel de interfețe și
nu la nivelul implementării.
Astfel cream interfata TournamentInterface cu doua clase care o va realiza: una pentru
categoria Kumite, alta pentru Kata.

interface TournamentInterface {
public void startTournament();
}

class Kumite implements TournamentInterface{

@Override
public void startTournament() {
System.out.println("Kumite");
}
}

class Kata implements TournamentInterface{

@Override
public void startTournament() {
System.out.println("Kata");
}
}

Acum trebuie sa schimbam principala clasa BelorusTournament si clasele mostenite.

abstract class BelorusTournament{

TournamentInterface tournamentInterface;

public void performTournament(){

tournamentInterface.startTournament();
}
}

class BelorusKumite extends BelorusTournament{

public BelorusKumite(){
tournamentInterface = new Kumite();
}
}

class BelorusKata extends BelorusTournament{

public BelorusKata(){
tournamentInterface = new Kata();
}
}

Dupa cum putem observa, metoda startTournament() acum nu depinde de nici-o

realizare a clasei categoriei campionatului.
Principala metoda de asemenea se va schimba.
public class Main{
public static void main(String[] args) {
BelorusTournament kumite = new BelorusKumite();
kumite.performTournament();
BelorusTournament kata = new BelorusKata();
kata.performTournament();
}
}

Acum sa ne inchipui ca organizatorul vrea sa adauge pentru categoria Kata de

asemenea si categoria TeamKata. Dupa schimbarile efectuate aceasta nu reprezinta
nimic complicat. Trebuie doar sa adaugam in clasa principala BelorusTournament o
metoda de setare.

abstract class BelorusTournament{

TournamentInterface tournamentInterface;

public void setCategory(TournamentInterface tournamentInterface){

this.tournamentInterface = tournamentInterface;
}

public void performTournament(){

tournamentInterface.startTournament();
}
}

De asemenea schimbam realizarea claselor concrete.

class BelorusKumite extends BelorusTournament{

public BelorusKumite(){
setCategory(new Kumite());
}
}

class BelorusKata extends BelorusTournament{

public BelorusKata(){
setCategory(new Kata());
}
}

Acum putem adauga liber o noua categorie.

public class Main{

public static void main(String[] args) {
BelorusTournament kumite = new BelorusKumite();
kumite.performTournament();
BelorusTournament kata = new BelorusKata();
kata.performTournament();
kata.setCategory(new TeamKata());
kata.performTournament();
}
}
Output
Kumite
Kata
TeamKata

Concluzii

In concluzie pot sa mentionez ca multumita sablonului Strategy aplicatia poate

suporta orice schimbare in alegerea categoriilor unui campionat, astfel, inexactitatea
organizatorului nu devine o problema.