Search  
Friday, November 24, 2017 ..:: Articole » Design Patterns In Visual FoxPro ::.. Register  Login
 Articole Minimize

Design Patterns In Visual FoxPro

Autor: Grigore Dolghin

E-mail: gdolghin@yahoo.com

Website: www.class-software.ro

 

 

Se traduce prin “Modele de programare” si inseamna exact ceea ce se intelege: solutii pentru problemele des intalnite in cursul dezvoltarii aplicatiilor, intr-un anumit context. O parte suprinzator de mare din aceste modele este intalnita in mod curent in codul pe care il scriem in fiecare zi, desi nu intotdeauna stim ca secventa respectiva este un design pattern; de multe ori design pattern-ul este aplicat de programatori doar datorita simtului si experientei. Cu toate acestea, aplicarea este incompleta sau are diferente fata de definitie. Acest lucru nu este neaparat un lucru rau; singura consecinta negativa posibila este ca intr-un viitor oarecare programatorul ar putea fi nevoit sa revina asupra codului, pentru ca implementarea partiala a unui design pattern ar putea fi insuficienta pe masura ce timpul trece si aplicatia evolueaza.

 

Design Pattern-urile ofera doua mari avantaje: primul este acela ca ele permit oricarui programator sa inteleaga ideea generala a codului specificand doar denumirea pattern-ului. “Aha, deci aici e un Bridge. Ia sa vedem cum e facut.” Programatorul va sti cum functioneaza codul dvs. fara a citi macar un rand de cod. Al doilea mare avantaj este ca ofera consecventa in tratarea problemelor. Ori de cate ori apare aceeasi problema de rezolvat, se va aplica aceeasi metoda. Daca sunteti ca mine, este foarte probabil ca la inceputul unei aplicatii sa rezolvati un anumit tip de problema intr-un fel, iar un an mai tarziu in alt fel. Cunoasterea Design Pattern-urilor va scuteste de munca de “creatie”. Veti aplica metoda perfecta si acum si peste un an; important este doar sa stiti pattern-urile si sa recunoasteti situatiile in care acestea se aplica.

 

Acest articol este primul dintr-o serie mai lunga, in care voi incerca sa descriu Design Pattern-urile si sa scriu secvente de cod care demonstreaza aplicarea fiecarui pattern in Visual FoxPro. Veti intalni cod pe care probabil il scrieti si dumneavoastra in fiecare zi; in cazul acesta va adresez felicitari. Pe de alta parte este posibil sa gasiti solutii la care nu v-ati gandit pana acum; este decizia dvs. daca veti folosi sau nu modelele. Ce va pot asigura, in schimb, este ca aceste modele sunt solutii demonstrate, care si-au dovedit flexibilitatea si stabilitatea in timp, si ca eficatitatea lor este direct proportionala cu marimea aplicatiei pe care o scrieti.

 

Un design pattern are patru elemente de baza:

  • Numele – care descrie sintetic problema rezolvata de pattern si solutia;
  • Problema – o descriere mai larga a problemei si a contextului in care apare ea;
  • Solutia – o descriere a elementelor de proiectare folosite a relatiilor dintre ele;
  • Consecintele si dezavantajele – descrierea dezavantajelor care pot apare prin implementarea pattern-ului respectiv.

 

Design pattern-urile nu sunt implementari concrete sau proiecte particulare; studiul unui design pattern nu este legat de un anumit limbaj de programare; design pattern-ul este pur si simplu o descriere teoretica a unui anumit tip de problema si a solutiei pentru ea, fiind independent de limbajul de programare folosit.

 

In programarea orientata pe obiect (OOP) entitatea de baza este obiectul. Obiectele au doua entitati de baza: date (stocate in proprietatile obiectului), metode (secvente de cod care actioneaza asupra datelor). In plus exista entitatea numita mesaj, care reprezinta transferul de informatie de la un obiect la altul. Aceste mesaje sunt singura metoda prin care un obiect este determinat sa execute o operatie, modificand datele sale. Evenimentele sunt un caz particular al metodelor – ele sunt metode care se excuta fara interventia directa a programatorului (de exemplu, evenimentul .Load()). In Visual FoxPro evenimentele se deosebesc de metode printr-o regula de bun simt: daca trebuie s-o apelez, e metoda; daca nu trebuie, e eveniment.

 

Partea cea mai dificila in dezvoltarea unui sistem OOP este descompunerea sistemului in obiecte. Cunoasterea design pattern-urilor usureaza aceasta sarcina, pentru ca ofera un mod unitar de a privi lucrurile. Mai mult, unele din obiecte sunt mai putin evidente in faza de analiza, iar prin cunoasterea design pattern-urilor veti sti sa identificati si acest tip de situatii.

 

Suma proprietatilor, metodelor si evenimentelor unui obiect se numeste interfata. A nu se confunda cu notiunea Interfata Utilizator, care se refera strict la partea “vizibila” a unei aplicatii. In acest context, design pattern-urile ne ajuta sa definim interfetele si sa identificam elementele care nu trebuie sa apara in interfata (uneori programatorii au tendinta sa aglomereze inutil interfata obiectelor).

 

In OOP exista doua tipuri diferite de mostenire: mostenire de clasa si mostenire de interfata. O parte din design pattern-uri se bazeaza pe aceasta diferenta. In Visual FoxPro mostenirea de interfata nu este implementata, dar va pot face o descriere sumara a ei, ca sa intelegeti despre ce este vorba:

Cum spuneam mai devreme, interfata este colectia de proprietati, evenimente si metode (PEM) ale unei clase. Daca subclasez (in Visual FoxPro) o clasa oarecare, cand apelez o metoda a subclasei se executa si codul clasei parinte. Aceasta este mostenirea de clasa. Pot sa obtin un echivalent al mostenirii de interfata deschizand fiecare metoda si eveniment si introducand un NODEFAULT ca prima linie de cod, “rupand” mostenirea. Voi obtine o clasa care are toate PEM-urile clasei din care a fost subclasata, dar care nu are nici o legatura cu codul clasei parinte. Clasa subclasata mosteneste doar interfata (colectia de PEM-uri), nu si codul. (In realitate il mosteneste, si din acest motiv ziceam ca mostenirea de interfata nu este suportata in VFP. NoDefault ca prima linie de cod doar emuleaza mostenirea de interfata).

 

Interfata este o notiune extrem de importanta in OOP. Definirea corecta a interfetelor claselor ofera doua avantaje: obiectele client nu sunt nevoite sa stie cu ce tip de obiecte comunica, atat timp cat obiectele expun aceeasi interfata, si obiectele client nu sunt nevoite sa stie care sunt clasele care implementeaza obiectele cu care comunica, ci trebuie doar sa stie interfata definita de acestea.

 

Toate aceste lucruri duc catre o regula OOP, formulata de GoF (Gang of Four – Erich Gamma, Richard Helm, Ralph Johnson si John Vlissides:

 

Programati in termeni de interfete, nu de implementari.

 

Altfel spus: daca scriem cod care instantiaza un obiect dintr-o clasa, si specificam numele clasei in clar, vom lega pentru totdeauna codul pe care il scriem de numele clasei respective. Mai tarziu este posibil ca acest lucru sa ne incurce; daca aplicatia va necesita instantierea altui obiect, va trebui sa scriem cod suplimentar (un DO CASE de cele mai multe ori), care va tot creste pe masura ce complexitatea aplicatiei creste si ea.

 

La o privire mai atenta ne dam seama ca noi de fapt nu avem nevoie de OBIECTUL acela in mod expres, ci avem nevoie de un obiect care implementeaza INTERFATA aceea in mod expres. Daca folosim un design pattern creational (veti vedea mai tarziu ce sunt acestea), putem decupla instantierea obiectului de clasa in care este definit, schimband astfel clasa ori de cate ori avem nevoie. Ce obtinem? Codul scris se va potrivi si la clienti, si la furnizori, de exemplu (pentru ca putem instantia cu acelasi cod si obiectul client si obiectul furnizor, care sunt definite in clase distincte).

 

Design Pattern-urile sunt impartite in trei mari categorii:

  • Creational Patterns (modele creationale)
  • Structural Patterns  (modele structurale)
  • Behavioral Patterns (modele comportamentale)

 

In articolele urmatoare voi descrie design pattern-urile propriuzise, cate un articol pentru fiecare design pattern. Inainte de a termina, le voi enumera, grupandu-le in categoriile lor:

 

  • Modele Creationale
    • Abstract Factory
    • Builder
    • Factory Method
    • Prototype
    • Singleton
  • Modele Structurale
    • Adapter
    • Bridge
    • Composite
    • Decorator
    • Façade
    • Flyweight
    • Proxy
  • Modele Comportamentale
    • Chain Of Responsibility
    • Command
    • Interpreter
    • Mediator
    • Memento
    • Observer
    • State
    • Template Method
    • Visitor

    

 Google Ads Minimize

    

Copyright 2002-2013 Profox   Terms Of Use  Privacy Statement