U kasnim 80-ima prošlog stoljeća ništa se nije temeljito promijenilo u programiranju. Bilo je mnogo jezika, mnogo kontroverzi i tu je bio Turbo Pascal 5.5, au isporuci paketa bilo je nekoliko čudnih datoteka i nekoliko nekonvencionalnih struktura u sintaksi.
Vjerojatno je objektno orijentirano programiranje posljedica pojave nepoznatog umjetnika, a možda i nekoliko, ali osobito velike vrijednosti, ideja kombiniranja koda i podataka u ta davna vremena nije nosila. Pojam "enkapsulacija" bio je slabo i neizravno povezan.
Strukture, funkcije i procedure
Već u prvim verzijama programskih jezika, prije nego što su se pojavile prve baze podataka, bilo je apsolutno jasno da to nije broj, a ne niz simbola, već nešto smisleno. Neka to bude varijabla "counter" u petlji ili tri retka varijable "prezime", "ime", "patronymic", ali to je uvijek odmah smisleno.
"Brojač" se uvijek nalazi nakon ciklusa i radi u njemu. I "prezime", "ime", "patronymic" će biti objavljeni zajedno, i njihovo sudjelovanje u mnogim dijelovima koda će se dijeliti. Tamo gdje će se koristiti samostalno, općenito, imat će jedan smisao. Funkcije i postupci izvorno su se pojavljivali kao uobičajeni dijelovi koda. Njihova je uporaba u početku bila predviđena na drugim mjestima programa. Njihovo pojavljivanje u programu uvjetovalo je ponavljanje blokova istih akcija. Uklanjanje ponavljanja u obliku funkcije ili postupka pojednostavljuje mjesto ponavljanja, smanjuje količinu koda i pojednostavljujeispravljanje pogrešaka.
To nije bilo objektno orijentirano programiranje, već je klasični stil kodiranja od samog početka evolucije bio uključen u generalizaciju podataka, stvaranje struktura i funkcionalnih područja koda.
Razlozi za pokretanje enkapsulacije
Inkapsulacija u programiranju počela je mnogo prije OP-a. Bilo je to u dubinama klasičnog stila, nije se uzelo u obzir funkcionalno programiranje, strukturno i sve ostalo što je tražilo put u budućnost. Svaki prevodilac i tumač jezika marljivo je uzeo sve novo u svojoj sintaksi, nudeći programerima opcije za implementaciju semantike. Informacije nikada nisu bile statične, samo je programiranje još uvijek zadovoljno formalnom verzijom. Ali čak i ako je strogo formaliziran, informacija daje radni kod koji je uvijek povezan s njim. Informacije nikada ne mogu biti statične.
Najviše trivijalan primjer enkapsulacije, koji je odavno sačuvan do danas. Tri varijable "prezime", "ime", "patronymic", gdje god se nalazile, uvijek zahtijevaju funkcije dodavanja, uređivanja, brisanja. Štoviše, ove varijable pružaju masu konkretnih ljudi, tj. Mnogo primjeraka:
Ivanov, Ivan, Ivanovič;Petrova, Irina Vasylivna;
Kukushkina, Polina, Grigorievna; i apstraktna klasa "prezime", "ime", "patronymic"; i tri vječne funkcije; promjena; brisanje.Takvi nacrti na bilo kojoj razini (adrese, poslovi, osoblje, plan proizvodnje)mnogo se toga možete sjetiti. I složenost implementacije drugog dizajna bit će iznimno duga.
Životni vijek instance enkapsulacije
Encapsulacija je podatak i kod.
Inkapsulacija riječi. Latinska verzija - u kapsuli. Riječ "kapsula" je ono što ona znači. Činjenica da su mnogi jezici i programeri osmislili (javni, zaštićeni, privatni) - tema je odvojena i sadržaj enkapsulacije ima ili relativni ili primijenjeni stav. Općenito, instanca je jednostavno varijanta podataka (trenutaka), a te tri metode žive vječno. Kôd kao filtar informacija "osigurava" život instanci, jer je jedinstven za svakoga i, usput, do sada:
kod je "konstantan"; označava najjednostavniji nepromjenjivi učinak.Ali drugi primjer može "odbaciti" trik. "Ako se primjer pripiše kadrovskom popisu tvrtke, tada će direktor i računovođa biti od posebne važnosti u skupu primjeraka, dok drugi mogu ostati u uobičajenom obliku." Ravnatelj i računovođa mogu imati svoje vlastite kodove, odnosno svoje funkcije. To znači da život instance nije uvijek određen funkcionalnošću triju magičnih riječi:
add; promjena; brisanje.Ako se primjer pripiše prvom ljudskom letu u svemir, onda će dobrih desetak kandidata za prve astronaute imati puno posebne funkcionalnosti, dobre stotine ljudi (primjerci) će ih slijediti na poseban način, i dalje će biti mnogo mogućnosti za profesionalce koji će biti vrlo mnoge posebne značajke.
Početak OOP-a
"Hitno je nešto promijeniti", - mislio je određeni broj programera, teKao dobar primjer, predložio sam rad s objektima na Turbo Pascal 6.0 Professionalu. To nije idealna ponuda, ali vrlo visoka kvaliteta je jednostavna i učinkovita.
Stavljajući da je "enkapsulacija, polimorfizam, nasljeđivanje temelj nekog objekta, dobivamo dobar početak." Teško je prikazati homogenost objekta, izgraditi genealoško stablo formaliziranih informacija, a teško je reći da je enkapsuliranje podataka jednostavna kombinacija podataka i kodova, sve je vrlo jednostavno i postoji veliki koncept. Primjer objekta - to su samo podaci koji imaju pristup njegovom kodu. Može biti puno primjeraka, ali kôd za njih je uvijek isti i nije vezan za svakoga, ali je dostupan svima. objekt koji će imati poboljšanu funkcionalnost, tj. nasljeđuje sve što je bilo u izvornom objektu, ali dodaje svoje.
Svijet se nadopunjuje kopijama drugog objekta, koji također ima nove potrebe. Nova funkcionalnost i novi objekt. Ali ne može svaki novi objekt imati potomke. Neki ih više niti ne trebaju. Kao rezultat ove konstrukcije dobiva se granska slika objekata, au stvarnosti ona daje život velikom broju kopija koje su međusobno povezane rodovnim i funkcionalnim spojevima. Idealan način za izvršenje zadatka u OOP stilu je kadaenkapsulacija, polimorfizam, nasljeđivanje su tako kvalitativno promišljeni da je kod u programu potpuno odsutan. Predmeti sami obavljaju svoje funkcije, koriste samo svoj kod, grade međusobne odnose.
Život OOP-a
U stvarnosti, sve izgleda vrlo različito. Inkapsulacija je dobra i ne raspravljate ovdje. No, ispravno konstruirati sliku objekata, razmisliti o funkcionalnosti svakog od njih, predvidjeti kako se izvjesni ili drugi slučajevi koji se mogu očekivati od podataka ponašaju sami po sebi nije lako. Morao sam pojednostaviti situaciju, a OOP je krenuo putem automatizacije rada razvojnog inženjera, umjesto rješavanja stvarnih problema. Sa stajališta brzine stjecanja iskustva - to je djelotvorna ideja, jer što OOP treba učiniti za automatizaciju računovodstvenog rada kada se može dodati izborniku na HTML stranici? Vrlo je jednostavno: tu je stavka izbornika, postoje njezine varijante. Možete predložiti korisniku da odabere opcije izbornika (okomito, vodoravno, padajuće), možete dati obliku gumba (okrugli, kvadratni, zaobljeni itd.).
Malo je ljudi zainteresirano za rad i život developera. Svatko treba knjigovodstvo, proizvodnju i obuku, jer je potrebno izvršiti stvarne zadatke. Dakle, trebate povećati timove, ali tada će sustav objekata provoditi različiti stručnjaci i oni mogu naškoditi jedni drugima. U mnogim je aspektima PLO stavio na proizvodne tračnice. Već nije bilo sumnje: enkapsulacija, nasljeđivanje je dobar način, ali kako zaštititi objekte od smetnji treće strane, kako sa strane, tako i kroz rodovnicu? Ovo nije nužno haker.Slučajno oštetite promjenom podataka pretka, možda drugog developera. Moderno programiranje je puno programera koji su u skupu udaljenih ureda. Kao pčele, moderni programeri grade jednu zajedničku strukturu objekata. Svaki objekt mora biti izgrađen u skladu s općim pravilima, a podaci i metode za koje jedan programer odgovara ne moraju biti dostupni drugima. Kada netko nešto treba - to je još jedna tema. Na osnovnom principu, svatko radi svoju stvar na svom području.
Encapsulacija je dobra, ali
PHPWord je snažan, dobro napravljen i obećavajući proizvod. Izvrstan sustav objekata, dobro osmišljen i učinkovit. Ispod je početak opisa unutarnjeg objekta ovog proizvoda. Jedna jednostavna apstrakcija ćelije tablice iz općenito prazne apstrakcije - kontejner. A to je daleko od cijelog opisa.
Ne morate se uroniti u blato da biste razumjeli. Koristeći ovdje brojne komentare, ne dodaje se jasnoća, a riječi zaštićene, privatne i javne općenito govore, prije svega, da se programer treće strane, koji koristi ovu knjižnicu, promijenio na pravom mjestu privatno u javnom (vidi komentar: "sc 19062016 je privatan)" , To je pogreška u kodu koju je, kada se primijeni, programer bio prisiljen popraviti, i stoga je morao nešto promijeniti. Možemo pretpostaviti da u fazi razvoja trebate ograničiti pristup određenim objektima, ali ovdje je važno potpuno drugačije. Postoji život instanci, postoji život objekata, ali postoji novi život - što se događa sa sustavom objekata u njegovoj primjeni. Život u dizajnu i životu u primjeni. svojstvoznačajka modernog programiranja - kruta negacija kontinuiteta. Ako je ranije programer osigurao da svaka nova verzija dopuni i poboljša prethodnu, danas svaka nova verzija objekta, jezika, programskog okruženja je fundamentalno ili barem bitno različita od prethodne. Čak i uvjeti smještaja na usluzi hostinga mogu se promijeniti tako da ćete morati obraditi kôd. Često je to vrlo teško.
Dobra baština, dobar izlaz
Nema grešaka koje je netko osigurao. A svaki novi posao zahtijeva znanje. PHPWord je dobra knjižnica i samo se morate naviknuti na nju. Mnogi stručnjaci proveli su mnogo vremena. Programer koji će ga primijeniti mora posvetiti dovoljno vremena proučavanju strukture Vordovian datoteke. To nije tajna. Sustav PHPWord objekata bit će transparentan i pristupačan. Daje se onakvim kakav jest, ali ako postoji želja da se ide dalje, jer trenutna funkcionalnost nije dovoljna. Dobra ideja. Onda je ovo još jedan sustav objekata, i bolje ako ide dalje. Nije tako loše ideja o krutom odbacivanju kontinuiteta: ona potiče razvoj znanja. Objekti koje je izgradio jedan tim programera su njihova razmišljanja o tome kako riješiti zadatak, kako predstaviti njegov funkcionalan.
Razumijevanje ove odluke druge razvojne tvrtke je transformacija iskustva. Ako zamislite da je ovo samo prototip željenog sustava objekata, zašto ga jednostavno ne naslijediti? Dobra nasljednost - obilježje prirodne inteligencije, oslanja se na nešto prikladno sa strane programiranja - to je s terenabudućnost, iako najbliža.
Ispravno enkapsuliranje
Encapsulacija uopće nije kombinacija podataka i koda. To je kombinacija pristupačnog i poželjnog. Ako razmišljate o podacima i algoritmima, ali da biste uočili valjanost i implementirali adekvatnu enkapsulaciju, nasljedstvo ove akcije od razvijatelja do dobavljača, onda je vjerojatno: pojavljivanje sustava pokretnih objekata i samo-razvoja, još je moguće.
