Cursul de programare orientată pe obiecte, condus de Alexandru Iovanovici, se concentrează pe utilizarea limbajului C# pentru a dezvolta programe eficiente, abordând concepte precum clase, moștenire și polimorfism. Cursul include atât sesiuni teoretice, cât și laboratoare practice, cu evaluări ale progresului și se bazează pe resurse precum cartea lui Ioan Jurca. Se subliniază importanța unei înțelegeri profunde a principiilor de proiectare pentru a reduce erorile și a îmbunătăți calitatea software-ului.

1. Programarea orientată pe obiecte Curs 1

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. Eu si cursul ...

4. Organizare (2) Evaluare la sfarsitul fiecarui laborator;

5. la sfarsitul cursului (lucrare scrisa)

6. pe activitate/ parcurs Notele vor fi folosite ca si note pe parcurs la informatica la clasele din care faceti parte (veti avea doua note in plus)

7. Portia de Dilbert

8. Bibliografie I. Jurca: “ Programarea orientată pe obiecte. Limbajul Java ”, Ed. de Vest, 2005

9. K. Arnold, J. Gosling, D. Holmes: “ The Java Programming Language ”, 4th edition, Addison Wesley, 2005

10. C. Marinescu, P. Mihancea: <cartea_de_lab>

11. Diverse altele, recomandate pe parcurs;

12. Google -;)

13. Multumiri 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 .

14. Roadmap (1) Introducere

15. Clase şi obiecte

16. Moştenire şi polimorfism

17. Interfeţe

18. Clase şi interfeţe încuibate

19. Excepţii şi aserţiuni

20. Pachete

21. Operaţii de intrare/ieşire

22. Colecţii

23. Programare concurentă în Java

24. Interfeţe grafice (GUI)

25. Roadmap (2) Modelare şi programare

26. Paradigme de programare

27. Caracteristicile orientării pe obiecte

28. Elemente ale UML

29. Ciclul de viaţă al software-ului

30. Maşini virtuale, cod virtual

31. Limbaje orientate pe obiecte

32. Obiective Introduerea conceptului de Programare Orientata pe Obiecte;

33. Prezentarea modului in care aceasta tehnica poate fi folosita pentru dezvoltarea de programe bune ; GOOD

34. De ce ? Probleme: Costurile de dezvoltare software cresc, iar pretul hardware-ului scade;

35. Timpii de dezvoltare ai software-ului cresc, la fel si timpii de intretinere;

36. Erorile / defectele de software devin tot mai dese pe cand cele de hardware sunt aproape inexistente;

37. Tot mai multe proiecte esueaza din epuizarea fondurilor; 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. Si totusi … de ce ? Asteptari: Reducerea eforturilor, complexitatii si costurilor de dezvoltare pentru sistemele software;

39. Reducerea timpului de “adaptare” a sistemelor existente => flexibilitate , reutilizabilitate ;

40. Cresterea fiabilitatii sistemului;

41. Filosofie … Ce este programarea ??? Ca si orice limbaj uman, un limbaj de programare asigura o modalitate de a exprima concepte ;

42. Dezvoltarea programelor implica crearea de modele ale situatiilor din lumea reala si scrierea programelor pe baza acelor modele;

43. Programele reprezinta o modalitate de implementare a modelului ;

44. Programele pot contine reprezentari informatice ale lucrurilor care constituie solutiile problemelor reale;

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. Invatarea unui limbaj de programare Asemenea unei limbi, un limbaj de programare are o sintaxa si niste regului gramaticale ;

47. Cunosterea reguluilor gramaticale nu este suficienta pentru a scrie programe bune;

48. Cel mai important lucru este sa ne concentram asupra conceptului fara a ne pierde in detalii de limbaj;

49. Tehnicile de proiectare sunt mult mai importante decat detaliile de implementare … acestea vin de la sine.

50. Intelegerea algoritmulu i este mai importanta decat invatarea “pe de rost” a implementarii sale in Microbe :)

51. Invatarea unui nou limbaj nu presupune imvatarea sintaxei ci a unei noi modalitati de a rezolva o cerinta, mai bine. Acesta este un curs de Programare Orientata pe Obiecte care are drept suport limbajul C# si NU un curs de C# .

52. Metrici ale calitatii software-ului Un program trebuie sa isi faca treaba corect. Trebuie sa fie

53. util si utilizabil;

54. Un program trebuie sa indeplineasca cerintele de timp;

55. Un program nu trebuie sa iroseasca resursele sistemului

56. (fizice si logice);

57. Trebuie sa fie fiabil;

58. Trebuie sa poata fi actualizat;

59. Trebuie sa aiba suficienta documentatie … de calitate Codul sursa trebuie sa fie lizibil si inteligibil;

60. Programul trebuie sa poata si actualizat in concordanta

61. cu cerintele;

62. Localizarea erorilor;

63. Modulelele programului trebuie sa fie reutilizabile;

64. Proiectul trebuie sa fie finalizat inainte de deadline :)

65. Trebuie sa aiba sufiecienta documentatie … de dezvoltare Utilizator Programator

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. 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. Modelele au două roluri: explicativ şi predictiv

68. Modele: conceptuale (abstracte) sau fizice

69. Modelul nu se confundă cu realitatea

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. Paradigme de programare (1) Programarea structurată: Programul este descompus in structuri „elementare”, direct implementate in limbaj

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. Paradigme de programare (3) Probleme ale programarii procedurale: 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. Programele procedurale (functiile si structurile de date) nu modeleaza lumea reala suficient de bine . Luma reala nu e compusa din functii :)

75. Datele globale pot fi corupte de functii care nu au nimic de a face cu respectivele date;

76. La modificarea tipului unor date, toate functiile care lucreaza cu acele date trebuie sa fie modificate;

77. Creearea de noi tipuri de date poate fi dificila. 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. Caracteristicile orientarii pe obiecte Încapsularea Ascunderea info./implem. Păstrarea stării Identitatea obiectelor Comunicarea prin mesaje Clase Moştenire Polimorfism Genericitate

79. Identitatea obiectelor Fiecare obiect este distinct şi identificabil separat pe toată durata existenţei, prin referinţă;

80. Referinţa poate fi înscrisă în mai multe locaţii;

81. Colectarea reziduurilor (când un obiect nu mai are referinţa în nici o locaţie)

82. Clase si obiecte

83. Scurt istoric al orientarii pe obiecte Smalltalk Creat cca 1970 : la firma Xerox, colectiv condus de Alan Kay

84. Cel mai “pur” limbaj OO

85. Slab tipizat

86. Doar 5 cuvinte cheie şi un număr redus de operatori (permite supraîncărcarea operatorilor)

87. Moştenire simplă

88. Colectarea reziduurilor

89. Toate operaţiile claselor sunt publice, toate variabilele sunt private

90. Are ierarhie predefinită de clase

91. Foloseşte maşină virtuală

92. A introdus un mediu integrat de dezvoltare (IDE)

93. A fost standardizat în 1998

94. Nu este “agreat” de marile firme de software, cu excepţia IBM

95. Scurt istoric al orientarii pe obiecte C++ Creat de Bjarne Stroustrup, cca 1983-1985 , ca “ un C mai bun ”

96. Permite moştenire multiplă cu precizarea funcţiilor care pot fi înlocuite în subclase

97. Obiectele se pot crea fie prin declararea unor variabile, fie prin

98. constructori

99. Nu are colectare a reziduurilor, clasele au destructori

100. Operatorii pot fi supraîncărcaţi

101. Controlul accesului: private, protected, public

102. Nu are o ierarhie de clase standard

103. Concepte mai recente: spaţii de nume, tipare pentru genericitate

104. Are bibliotecă standard de tipare (STL)

105. Este un limbaj complex, nu este pur obiectual

106. Compilatoarele generează cod executabil, foarte eficient la execuţie

107. Toate firmele mari de software oferă suport pentru C++

108. Scurt istoric al orientarii pe obiecte Eiffel Creat de Bertrand Meyer în 1985

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. Permite moştenire multiplă

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. Are mecanism pentru tratarea excepţiilor şi parametri formali generici pentru clase

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

114. Scurt istoric al orientarii pe obiecte Java Creat de J. Gosling la SUN începând din 1991, public din 1995 ;

115. Mai puternic tipizat decât C++;

116. Nu există cod în afara claselor, clasa defineşte un tip

117. Tipurile numerice şi boolean nu sunt considerate clase (există însă clase înfăşurătoare)

118. Are moştenire simplă de implementare, conţine interfeţe pentru moştenire multiplă de proiectare

119. Nu are pointeri !!

120. Obiectele se creează numai prin apelarea explicită a unui constructor

121. Are ierarhie predefinită (clasa Object);

122. Include facilităţi de programare concurentă

123. Compilatorul produce cod virtual (WORA)

124. “Platforma Java”: J2SE, J2EE, J2ME

125. Nu are (încă!) standard recunoscut oficial

126. Scurt istoric al orientarii pe obiecte C# Introdus în 2000 ca parte a platformei .NET (Microsoft) de A. Hejlsberg şi S. Wiltamuth

127. .NET permite integrarea limbajelor de programare , astfel ca programe scrise în diverse limbaje să poată colabora fără dificultăţi

128. Are multe elemente comune cu Java : clase cu moştenire simplă, interfeţe, programare concurentă

129. Are colectare automată a reziduurilor , dar permite şi definirea de destructori, neapelabili direct

130. Are şi caracteristici comune cu C++: supraîncărcarea operatorilor, pointeri

131. Suport de dezvoltare oferit de Microsoft, dar există şi variante gratuite

132. Ciclul de viata al software-ului (1) Analiza : obtinerea unei imagini clare a “ ce se cere ”. Intelegerea cerintelor. Acestea se pot schimba in timpul dezvoltarii sistemului … sau dupa aceasta ;

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. Implementarea/Codarea : modelul solutiei este transpus in limbaj de programare;

135. Documentarea : fiecare faza trebuie documentata corect si detaliat;

136. Testarea : Componentele si produsul final trebuie testate pentru verificarea corectitudinii de functionare (!!!);

137. Ciclul de viata al software-ului (2) Problema/Cerinta Analiza/Planificare Proiectare/Modelare Implementare Testare Documentatie Produs

138. Requirements changing

139. Intrebari ???