Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.

Nedostaci objektno orjenitisane metodologije, i ima li ih uopšte?

[es] :: Art of Programming :: Nedostaci objektno orjenitisane metodologije, i ima li ih uopšte?

Strane: < .. 1 2 3 4

[ Pregleda: 19780 | Odgovora: 63 ] > FB > Twit

Postavi temu Odgovori

Autor

Pretraga teme: Traži
Markiranje Štampanje RSS

Anemia
Beograd

Član broj: 200828
Poruke: 6
*.dynamic.sbb.rs.



Profil

icon Re: Nedostaci objektno orjenitisane metodologije, i ima li ih uopšte?12.11.2008. u 07:27 - pre 188 meseci
@ topic

Ne znam koliko OO pristup moze da podrzi upravljanje, razvoj i stalne promene. npr. Imas poveci broj objekata koji komuniciraju medju sobom, i sada se u jednom trenutku promeni nacin poslovanja, pa ti sada moras opet u kod da idesh da menjas i td..., to je potpuno neprakticno ako imas veliki broj ucesnika. Jednostavno ne znam koliko je ovaj pristup dobar na promene, da li na lak nacin moze da ih podrzi itd...
 
Odgovor na temu

Valerij Zajcev

Član broj: 40886
Poruke: 1374
*.hermes.si.



+2 Profil

icon Re: Nedostaci objektno orjenitisane metodologije, i ima li ih uopšte?13.11.2008. u 07:23 - pre 188 meseci
Citat:

@ topic

Ne znam koliko OO pristup moze da podrzi upravljanje, razvoj i stalne promene. npr. Imas poveci broj objekata koji komuniciraju medju sobom, i sada se u jednom trenutku promeni nacin poslovanja, pa ti sada moras opet u kod da idesh da menjas i td..., to je potpuno neprakticno ako imas veliki broj ucesnika. Jednostavno ne znam koliko je ovaj pristup dobar na promene, da li na lak nacin moze da ih podrzi itd...


OOP je i zamisljen da resi ovakve situacije, da kada dodje do promene necega u sistemu, da se to nesto zameni lako i tako da korisnik to ne primeti.
Evo ovako: Recimo da imas neku aplikaciju, 3-tier, i za "data layer" si koristio klasu ciji objekti pristupaju MS SQL DBMS-u, i to je ok. Ali korisniku sine da umesto MS SQL odluci da koristi recimo "MS Access DBMS" i sve sada sto developer treba da uradi jeste da zameni klasu u "data layer-u".
Tako da ako se promeni nacin poslovanja obicno ima neko ko je vec napisao neku ako ne istu onda slicnu klasu koju mozes samo da nasledis i dodas sta ti treba.
OO je bas dobar za stalne promene.

PozZ
 
Odgovor na temu

MarkoBalkan

Član broj: 141124
Poruke: 1624
*.ipc.hr.



+19 Profil

icon Re: Nedostaci objektno orjenitisane metodologije, i ima li ih uopšte?14.11.2008. u 05:57 - pre 188 meseci
Citat:
Valerij Zajcev: OOP je i zamisljen da resi ovakve situacije, da kada dodje do promene necega u sistemu, da se to nesto zameni lako i tako da korisnik to ne primeti.
Evo ovako: Recimo da imas neku aplikaciju, 3-tier, i za "data layer" si koristio klasu ciji objekti pristupaju MS SQL DBMS-u, i to je ok. Ali korisniku sine da umesto MS SQL odluci da koristi recimo "MS Access DBMS" i sve sada sto developer treba da uradi jeste da zameni klasu u "data layer-u".
Tako da ako se promeni nacin poslovanja obicno ima neko ko je vec napisao neku ako ne istu onda slicnu klasu koju mozes samo da nasledis i dodas sta ti treba.
OO je bas dobar za stalne promene.

PozZ


a ako si daš truda, u datalayer ubaciš klase za nekoliko baza, i promjenom imena baze u opcijama automatski se aplikacija kači na tu bazu.
 
Odgovor na temu

saigon_from_europe

Član broj: 73547
Poruke: 34
*.ptt.rs.



+1 Profil

icon Re: Nedostaci objektno orjenitisane metodologije, i ima li ih uopšte?16.11.2008. u 15:22 - pre 188 meseci
Citat:
Anemia: @ topic

Ne znam koliko OO pristup moze da podrzi upravljanje, razvoj i stalne promene. npr. Imas poveci broj objekata koji komuniciraju medju sobom, i sada se u jednom trenutku promeni nacin poslovanja, pa ti sada moras opet u kod da idesh da menjas i td..., to je potpuno neprakticno ako imas veliki broj ucesnika. Jednostavno ne znam koliko je ovaj pristup dobar na promene, da li na lak nacin moze da ih podrzi itd...


Poenta objektno baziranog programiranja, a to je veci deo objektno orijentisanog programiranja, je da se veze izmedju entiteta jasno odvoje i vide. Konkretno, ono sto je stvar samog entiteta (klase u OOP) se vise ne vidi spolja, pa veze izmedju entiteta postaju jasne.

To nije nikakva nova ideja, tako su ljudi radili i pre OOP jezika (i pre OBP jezika, kakav je npr. VB6), ali nije bilo sintaksnih ogranicenja (npr. kljucne reci "private") da to zaista spreci programera da napravi da neka funkcija krene da "krlja" po strukturi koja joj je prosledjena, a gde se ocekivalo da ona samo procita neke podatke.

(Naravno, OOP je vise od ovoga, ali ovo - enkapsulacija - je verovatno najbitnija stvar OOP-a.)

Medjutim, nece OOP da te spasi loseg dizajna. A tipican primer loseg dizajna je kada je proces komunikacije izmedju objekata los. Na primer, kada jedan logicki kanal komunikacije (npr. logicki tok podataka, proistekao iz biznis logike) implementaciono razbijes na nekoliko, pa se onda pola koda svede na pokusaje sinhronizacije komunikacije, i kada svaka izmena zahteva da se sve to ponovo natera da radi.

Lako je naci programe u kojima postoji previse veza. Iako formalno postoji enkapsulacija, ona se krsi time sto su objekti/klase medjusobno previse spregnuti, jer objekat A prestaje da radi ako objekat B nije tacno u stanju X, koje se postize time sto se operacije a, b i c izvrsavaju tacno tim redom i nijednim drugim...

OOP pomaze da se stvari zaista zaokruze u nezavisne celine, ali ni jedan nacin programiranja, pa ni OOP ne moze da sam od sebe resi probleme loseg dizajna.

Dalje, zaokruzivanje stvari u celine (bilo preko OOP ili na primer, pravljenjem multi tier aplikacije) pravi probleme same po sebi. Ako kasno u projektu otkrijes da neki podaci nisu dostavljeni tamo gde bi trebalo da budu, to najcesce znaci da se mora menjati nekoliko entiteta. E, tu ljudima padaju na pamet razne ideje kako doturiti podatke.
 
Odgovor na temu

[es] :: Art of Programming :: Nedostaci objektno orjenitisane metodologije, i ima li ih uopšte?

Strane: < .. 1 2 3 4

[ Pregleda: 19780 | Odgovora: 63 ] > FB > Twit

Postavi temu Odgovori

Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.