Programarea orientată pe obiecte Curs 1
Organizare (1) Curs Alexandru IOVANOVICI E-mail:  [email_address] Tel: 0746-173820 www.bjt.ro/~alex/poo Laborator la fel ;...
Eu si cursul ...
Organizare (2) Evaluare <ul><li>la sfarsitul fiecarui laborator;
la sfarsitul cursului (lucrare scrisa)
pe activitate/ parcurs </li></ul>Notele vor fi folosite ca si note pe parcurs la informatica la clasele din care faceti pa...
Portia de Dilbert
Bibliografie <ul><li>I. Jurca: “ Programarea orientată pe obiecte. Limbajul Java ”,   Ed. de Vest, 2005
K. Arnold, J. Gosling, D. Holmes:    “ The Java Programming Language ”, 4th edition,   Addison Wesley, 2005
C. Marinescu, P. Mihancea: <cartea_de_lab>
Diverse altele, recomandate pe parcurs;
Google -;) </li></ul>
Multumiri <ul>Aceasta prezentare (si cele ce vor urma) are la baza cartea  Ioan Jurca – Programarea Orientata pe Obiecte  ...
Roadmap (1) <ul><li>Introducere
Clase şi obiecte
Moştenire şi polimorfism
Interfeţe
Clase şi interfeţe încuibate
Excepţii şi aserţiuni
Pachete
Operaţii de intrare/ieşire
Colecţii
Programare concurentă în Java
Interfeţe grafice (GUI) </li></ul>
Roadmap (2) <ul><li>Modelare şi programare
Paradigme de programare
Caracteristicile orientării pe obiecte
Elemente ale UML
Ciclul de viaţă al software-ului
Maşini virtuale, cod virtual
Limbaje orientate pe obiecte </li></ul>
Obiective <ul><li>Introduerea conceptului de Programare Orientata pe Obiecte;
Prezentarea modului in care aceasta tehnica poate fi folosita pentru dezvoltarea de programe  bune ; </li></ul>GOOD
De ce ? Probleme: <ul><li>Costurile de dezvoltare  software cresc, iar pretul hardware-ului scade;
Upcoming SlideShare
Loading in...5
×

Curs1-POO-Loga

1,837

Published on

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,837
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "Curs1-POO-Loga"

  1. 1. Programarea orientată pe obiecte Curs 1
  2. 2. Organizare (1) Curs Alexandru IOVANOVICI E-mail: [email_address] Tel: 0746-173820 www.bjt.ro/~alex/poo Laborator la fel ;-) Atentie ! Odata la doua sapt. se face curs şi in cealalta saptamana se face laborator (cate 2 ore)
  3. 3. Eu si cursul ...
  4. 4. Organizare (2) Evaluare <ul><li>la sfarsitul fiecarui laborator;
  5. 5. la sfarsitul cursului (lucrare scrisa)
  6. 6. pe activitate/ parcurs </li></ul>Notele vor fi folosite ca si note pe parcurs la informatica la clasele din care faceti parte (veti avea doua note in plus)
  7. 7. Portia de Dilbert
  8. 8. Bibliografie <ul><li>I. Jurca: “ Programarea orientată pe obiecte. Limbajul Java ”, Ed. de Vest, 2005
  9. 9. K. Arnold, J. Gosling, D. Holmes: “ The Java Programming Language ”, 4th edition, Addison Wesley, 2005
  10. 10. C. Marinescu, P. Mihancea: <cartea_de_lab>
  11. 11. Diverse altele, recomandate pe parcurs;
  12. 12. Google -;) </li></ul>
  13. 13. Multumiri <ul>Aceasta prezentare (si cele ce vor urma) are la baza cartea Ioan Jurca – Programarea Orientata pe Obiecte cat si diferite materiale “culese” din Internet. Peste tot unde am folosit diferite surse am incercat sa mentionez autorii acestora. Eventualele scapari sunt mea culpa . </ul>
  14. 14. Roadmap (1) <ul><li>Introducere
  15. 15. Clase şi obiecte
  16. 16. Moştenire şi polimorfism
  17. 17. Interfeţe
  18. 18. Clase şi interfeţe încuibate
  19. 19. Excepţii şi aserţiuni
  20. 20. Pachete
  21. 21. Operaţii de intrare/ieşire
  22. 22. Colecţii
  23. 23. Programare concurentă în Java
  24. 24. Interfeţe grafice (GUI) </li></ul>
  25. 25. Roadmap (2) <ul><li>Modelare şi programare
  26. 26. Paradigme de programare
  27. 27. Caracteristicile orientării pe obiecte
  28. 28. Elemente ale UML
  29. 29. Ciclul de viaţă al software-ului
  30. 30. Maşini virtuale, cod virtual
  31. 31. Limbaje orientate pe obiecte </li></ul>
  32. 32. Obiective <ul><li>Introduerea conceptului de Programare Orientata pe Obiecte;
  33. 33. Prezentarea modului in care aceasta tehnica poate fi folosita pentru dezvoltarea de programe bune ; </li></ul>GOOD
  34. 34. De ce ? Probleme: <ul><li>Costurile de dezvoltare software cresc, iar pretul hardware-ului scade;
  35. 35. Timpii de dezvoltare ai software-ului cresc, la fel si timpii de intretinere;
  36. 36. Erorile / defectele de software devin tot mai dese pe cand cele de hardware sunt aproape inexistente;
  37. 37. Tot mai multe proiecte esueaza din epuizarea fondurilor; </li></ul>Financial Times (27/08/2002, p. 12) The National Institute of Standards and Technologies recently reported that software bugs cost American companies approximately $60 billion in 2001 , while Bill Gutterman at CMU's Sustainable Computing Consortium pegs the real costs closer to three or four times that [...]
  38. 38. Si totusi … de ce ? Asteptari: <ul><li>Reducerea eforturilor, complexitatii si costurilor de dezvoltare pentru sistemele software;
  39. 39. Reducerea timpului de “adaptare” a sistemelor existente => flexibilitate , reutilizabilitate ;
  40. 40. Cresterea fiabilitatii sistemului; </li></ul>
  41. 41. Filosofie … Ce este programarea ??? <ul><li>Ca si orice limbaj uman, un limbaj de programare asigura o modalitate de a exprima concepte ;
  42. 42. Dezvoltarea programelor implica crearea de modele ale situatiilor din lumea reala si scrierea programelor pe baza acelor modele;
  43. 43. Programele reprezinta o modalitate de implementare a modelului ;
  44. 44. Programele pot contine reprezentari informatice ale lucrurilor care constituie solutiile problemelor reale; </li></ul>
  45. 45. Filosofie … deci Modalitatea orientata pe obiecte va fi semnificativ mai usoara, mai flexibila si mai eficienta fata de celelalte alternative pe masura ce problemele devin mai mari si mai complexe … daca este aplicata corect.
  46. 46. Invatarea unui limbaj de programare <ul><li>Asemenea unei limbi, un limbaj de programare are o sintaxa si niste regului gramaticale ;
  47. 47. Cunosterea reguluilor gramaticale nu este suficienta pentru a scrie programe bune;
  48. 48. Cel mai important lucru este sa ne concentram asupra conceptului fara a ne pierde in detalii de limbaj;
  49. 49. Tehnicile de proiectare sunt mult mai importante decat detaliile de implementare … acestea vin de la sine.
  50. 50. Intelegerea algoritmulu i este mai importanta decat invatarea “pe de rost” a implementarii sale in Microbe :)
  51. 51. Invatarea unui nou limbaj nu presupune imvatarea sintaxei ci a unei noi modalitati de a rezolva o cerinta, mai bine. </li></ul>Acesta este un curs de Programare Orientata pe Obiecte care are drept suport limbajul C# si NU un curs de C# .
  52. 52. Metrici ale calitatii software-ului <ul><li>Un program trebuie sa isi faca treaba corect. Trebuie sa fie
  53. 53. util si utilizabil;
  54. 54. Un program trebuie sa indeplineasca cerintele de timp;
  55. 55. Un program nu trebuie sa iroseasca resursele sistemului
  56. 56. (fizice si logice);
  57. 57. Trebuie sa fie fiabil;
  58. 58. Trebuie sa poata fi actualizat;
  59. 59. Trebuie sa aiba suficienta documentatie … de calitate </li></ul><ul><li>Codul sursa trebuie sa fie lizibil si inteligibil;
  60. 60. Programul trebuie sa poata si actualizat in concordanta
  61. 61. cu cerintele;
  62. 62. Localizarea erorilor;
  63. 63. Modulelele programului trebuie sa fie reutilizabile;
  64. 64. Proiectul trebuie sa fie finalizat inainte de deadline :)
  65. 65. Trebuie sa aiba sufiecienta documentatie … de dezvoltare </li></ul>Utilizator Programator
  66. 66. Filosofie … deci Modalitatea orientata pe obiecte permite crearea de programe calitative. Pe tot parcursul proiectarii si implementarii (codarii) unui program este necesar a se lua in considerare respectarea acestor metrici.
  67. 67. Modelare şi programare (1) Model : expresie a înţelegerii unui fenomen, proces, situaţie la un moment dat Model : o forma simplificata/asbtractizata a unei realitati fizice, care pastreaza doar elementele esentiale, caracteristice. <ul><li>Modelele au două roluri: explicativ şi predictiv
  68. 68. Modele: conceptuale (abstracte) sau fizice
  69. 69. Modelul nu se confundă cu realitatea </li></ul>
  70. 70. Modelare şi programare (2) Calculatorul : model fizic bazat pe un model conceptual pentru calcul Model de calcul concret = algoritm ==> program Există mai multe modele generice de calcul => mai multe arhitecturi de calculatoare Există mai mulţi algoritmi pentru o problemă Există distanţă conceptuală între domeniile de aplicaţii şi limbajele de programare
  71. 71. Paradigme de programare (1) Programarea structurată: Programul este descompus in structuri „elementare”, direct implementate in limbaj
  72. 72. Paradigme de programare (2) Programarea procedurală : porţiunile de cod care se repetă sunt separate în subprograme. Fiecare “instructiune” instruieste calculatorul “sa faca ceva” Programul este impartit in functii si, in mod ideal, fiecare functie are un scop si o interfata bine definite.
  73. 73. Paradigme de programare (3) Probleme ale programarii procedurale: <ul><li>Datele sunt subevaluate : spre exemplu intr-un program de gestiune a elevilor dintr-o scoala oricat ar fi de spectaculoase functiile care afiseaza elevii corigenti :P acesta nu fac altceva decat sa foloseasca datele brute si sa le interpreteze;
  74. 74. Programele procedurale (functiile si structurile de date) nu modeleaza lumea reala suficient de bine . Luma reala nu e compusa din functii :)
  75. 75. Datele globale pot fi corupte de functii care nu au nimic de a face cu respectivele date;
  76. 76. La modificarea tipului unor date, toate functiile care lucreaza cu acele date trebuie sa fie modificate;
  77. 77. Creearea de noi tipuri de date poate fi dificila. </li></ul>Este posibila crearea de programe “bune” si folosind programarea procedurala. POO ne ofera unele avantaje care ne permit sa scriem programe mai bine si mai usor .
  78. 78. Caracteristicile orientarii pe obiecte Încapsularea Ascunderea info./implem. Păstrarea stării Identitatea obiectelor Comunicarea prin mesaje Clase Moştenire Polimorfism Genericitate
  79. 79. Identitatea obiectelor <ul><li>Fiecare obiect este distinct şi identificabil separat pe toată durata existenţei, prin referinţă;
  80. 80. Referinţa poate fi înscrisă în mai multe locaţii;
  81. 81. Colectarea reziduurilor (când un obiect nu mai are referinţa în nici o locaţie) </li></ul>
  82. 82. Clase si obiecte
  83. 83. Scurt istoric al orientarii pe obiecte Smalltalk <ul><li>Creat cca 1970 : la firma Xerox, colectiv condus de Alan Kay
  84. 84. Cel mai “pur” limbaj OO
  85. 85. Slab tipizat
  86. 86. Doar 5 cuvinte cheie şi un număr redus de operatori (permite supraîncărcarea operatorilor)
  87. 87. Moştenire simplă
  88. 88. Colectarea reziduurilor
  89. 89. Toate operaţiile claselor sunt publice, toate variabilele sunt private
  90. 90. Are ierarhie predefinită de clase
  91. 91. Foloseşte maşină virtuală
  92. 92. A introdus un mediu integrat de dezvoltare (IDE)
  93. 93. A fost standardizat în 1998
  94. 94. Nu este “agreat” de marile firme de software, cu excepţia IBM </li></ul>
  95. 95. Scurt istoric al orientarii pe obiecte C++ <ul><li>Creat de Bjarne Stroustrup, cca 1983-1985 , ca “ un C mai bun ”
  96. 96. Permite moştenire multiplă cu precizarea funcţiilor care pot fi înlocuite în subclase
  97. 97. Obiectele se pot crea fie prin declararea unor variabile, fie prin
  98. 98. constructori
  99. 99. Nu are colectare a reziduurilor, clasele au destructori
  100. 100. Operatorii pot fi supraîncărcaţi
  101. 101. Controlul accesului: private, protected, public
  102. 102. Nu are o ierarhie de clase standard
  103. 103. Concepte mai recente: spaţii de nume, tipare pentru genericitate
  104. 104. Are bibliotecă standard de tipare (STL)
  105. 105. Este un limbaj complex, nu este pur obiectual
  106. 106. Compilatoarele generează cod executabil, foarte eficient la execuţie
  107. 107. Toate firmele mari de software oferă suport pentru C++ </li></ul>
  108. 108. Scurt istoric al orientarii pe obiecte Eiffel <ul><li>Creat de Bertrand Meyer în 1985
  109. 109. Denumirea sugerează “ proiect terminat la timp, cu costul prevăzut, cu un număr mic de tipare constructive robuste combinate pentru a obţine structuri complexe ” :)
  110. 110. Permite moştenire multiplă
  111. 111. “ Proiectarea prin contract ”: software-ul este construit pe baza unui contract între clienţi (apelanţi) şi furnizori (rutine), cu obligaţii şi beneficii explicitate prin aserţiuni (precondiţii, postcondiţii şi invarianţi)
  112. 112. Are mecanism pentru tratarea excepţiilor şi parametri formali generici pentru clase
  113. 113. Suport oferit de creator printr-o firmă proprie,dar există şi colaborări cu firmele mari (Microsoft, SUN) pentru a include Eiffel în platformele acestora </li></ul>
  114. 114. Scurt istoric al orientarii pe obiecte Java <ul><li>Creat de J. Gosling la SUN începând din 1991, public din 1995 ;
  115. 115. Mai puternic tipizat decât C++;
  116. 116. Nu există cod în afara claselor, clasa defineşte un tip
  117. 117. Tipurile numerice şi boolean nu sunt considerate clase (există însă clase înfăşurătoare)
  118. 118. Are moştenire simplă de implementare, conţine interfeţe pentru moştenire multiplă de proiectare
  119. 119. Nu are pointeri !!
  120. 120. Obiectele se creează numai prin apelarea explicită a unui constructor
  121. 121. Are ierarhie predefinită (clasa Object);
  122. 122. Include facilităţi de programare concurentă
  123. 123. Compilatorul produce cod virtual (WORA)
  124. 124. “Platforma Java”: J2SE, J2EE, J2ME
  125. 125. Nu are (încă!) standard recunoscut oficial </li></ul>
  126. 126. Scurt istoric al orientarii pe obiecte C# <ul><li>Introdus în 2000 ca parte a platformei .NET (Microsoft) de A. Hejlsberg şi S. Wiltamuth
  127. 127. .NET permite integrarea limbajelor de programare , astfel ca programe scrise în diverse limbaje să poată colabora fără dificultăţi
  128. 128. Are multe elemente comune cu Java : clase cu moştenire simplă, interfeţe, programare concurentă
  129. 129. Are colectare automată a reziduurilor , dar permite şi definirea de destructori, neapelabili direct
  130. 130. Are şi caracteristici comune cu C++: supraîncărcarea operatorilor, pointeri
  131. 131. Suport de dezvoltare oferit de Microsoft, dar există şi variante gratuite </li></ul>
  132. 132. Ciclul de viata al software-ului (1) <ul><li>Analiza : obtinerea unei imagini clare a “ ce se cere ”. Intelegerea cerintelor. Acestea se pot schimba in timpul dezvoltarii sistemului … sau dupa aceasta ;
  133. 133. Proiectarea : identificarea elementelor principale ale solutiei . Se creeaza modele ale acestora. Are impact mare asupra calitatii produsului => trebuie facuta verificarea modelului . Procesul de proiectare este legat de cel de implementare. In cazul nostru este vorba de proiectarea/programarea orientata pe obiecte ;
  134. 134. Implementarea/Codarea : modelul solutiei este transpus in limbaj de programare;
  135. 135. Documentarea : fiecare faza trebuie documentata corect si detaliat;
  136. 136. Testarea : Componentele si produsul final trebuie testate pentru verificarea corectitudinii de functionare (!!!); </li></ul>
  137. 137. Ciclul de viata al software-ului (2) Problema/Cerinta Analiza/Planificare Proiectare/Modelare Implementare Testare Documentatie Produs
  138. 138. Requirements changing
  139. 139. Intrebari ???

×