Inkapsulacija je pakiranje podatkov in funkcij v eno samo komponento. Inkapsulacija, polimorfizem, dedovanje: značilnosti

V poznih osemdesetih se ni zgodilo nič bistveno novega v programiranju. Bilo je veliko jezikov, veliko polemik in tam je bil Turbo Pascal 5.5, v paketu njegove dostave pa je bilo nekaj čudnih datotek in nekaj neobičajnih konstrukcij v skladnji.

Možno je, da objektno usmerjeno programiranje svoj videz dolguje neznanemu umetniku in morda več, vendar ideja o združevanju kode in podatkov v tistih časih ni imela posebej velike vrednosti. Bila je ohlapno in posredno povezana z izrazom "inkapsulacija".

Strukture, funkcije in postopki

Že v prvih različicah programskih jezikov, še pred pojavom prvih baz podatkov, je postalo popolnoma jasno, da to ni število ali niz znakov, ampak nekaj pomembnega. Naj bo spremenljivka "števec" v zanki ali tri male spremenljivke "priimek", "ime", "srednje ime", vendar je vedno smiselna takoj.

"Števec" je vedno po ciklu in deluje v njem. "Priimek", "prvo ime", "srednje ime" bodo objavljeni drug ob drugem, njihovo sodelovanje v številnih delih kode pa bo skupno. Nekje se bodo uporabljali samostojno, na splošno bodo imeli en pomen.

Funkcije in postopki so se prvotno pojavili kot skupni deli kode. Njihova uporaba je bila prvotno predvidena drugje v programu. Njihov pojav v programu je povzročil ponavljanje blokov istih dejanj. Ponavljanje v obliki funkcije ali postopka poenostavi mesta ponavljanja, zmanjša količino kode in poenostavi razhroščevanje.

To ni bilo objektno usmerjeno programiranje, ampak se je že od samega začetka njegovega razvoja klasični slog kodiranja ukvarjal z zbiranjem podatkov, ustvarjanjem struktur in funkcionalnih delov kode.

Razlogi za začetek enkapsulacije

Inkapsulacija v programiranju se je začela že pred pojavom OOP-a. Bilo je v globinah klasičnega stila, pomenilo je funkcionalno programiranje, strukturno in vse druge, ki so iskale pot v prihodnost.

Vsak prevajalnik in tolmač jezika sta skrbno vzela vse novo v svoji sintaksi, ponudila razvijalcem možnosti za izvajanje semantike.

Informacije še nikoli niso bile statične, samo programiranje je še vedno zadovoljivo s formalizirano različico. Toda čeprav so strogo formalizirane, informacije zagotavljajo delo kode, ki je z njo vedno povezana. Informacije nikoli ne morejo biti statične.

Najbolj nepomemben primer inkapsulacije, ki se je dolgo ohranil in je pomemben za ta dan. Tri spremenljivke "priimek", "prvo ime", "srednje ime", kjer koli so, vedno zahtevajo funkcije dodajanja, spreminjanja, brisanja. Poleg tega te spremenljivke zagotavljajo množico določenih ljudi, to je veliko primerov:

• Ivanov, Ivan, Ivanovič;
• Petrova, Irina, Vasiljevna;
• Kukushkina, Polina, Grigorievna;
• ... in abstraktni razred ...
• "priimek", "ime", "srednje ime";
• ... in tri večne funkcije ...
• add;
• spremembe;
• odstraniti.

Na vseh ravneh (naslovi, položaji, kadri, proizvodni načrt) je veliko različnih konstrukcij. In kompleksnost izvajanja drugačne zasnove bo neverjetno dolga.

Življenjska doba primera enkapsulacije

Inkapsulacija je podatek in koda.

• Beseda je enkapsulacija.
• Latinska različica - v kapsuli.

Beseda "kapsula" je tisto, kar pomeni. Dejstvo, da so mnogi jeziki in razvijalci mislili na to (javno, zaščiteno, zasebno), je ločena tema in ima relativni ali aplikacijski odnos do pomena enkapsulacije.

Na splošno je primer samo možnost (odtis, trenutek) podatkov in te tri metode živijo večno. Koda kot filter informacij "zagotavlja" življenje primerov, ker je ena za vse in mimogrede za zdaj :

• koda je "trajna";
• označuje najpreprostejše nespremenjeno dejanje.

Toda drugi primer lahko "izloči" žarišče.

Če je primer uvrščen na seznam zaposlenih, bodo imeli direktor in računovodja v množici izvodov poseben pomen. Ostalo lahko ostane v običajni "obliki". Direktor in računovodja imata lahko lastne kode, torej svoje funkcije.

To pomeni, da življenjska doba primerka ne določa vedno funkcionalnosti treh čarobnih besed:

• add;
• spremembe;
• odstraniti.

Če je primer povezan s prvim letom s posadko v vesolje, potem bo ducat kandidatov za prve kozmonavte imelo veliko posebne funkcionalnosti, stotine ljudi (primerkov) jih bo opazovalo na poseben način, še veliko več možnosti za strokovnjake, ki bodo imeli veliko posebnih. funkcije.

Zaženite OOP

"Nujno moramo nekaj spremeniti," so mislili številni razvijalci in kot dober primer predlagali delo s predmeti na Turbo Pascal 6.0 Professional. To ni idealna ponudba, ampak zelo kakovostna, enostavna in učinkovita.

Ob predpostavki, da je "enkapsulacija, polimorfizem, dedovanje" osnova objekta, dobimo dober začetek. Polimorfizem daje potrebno dinamiko, ker imajo lahko primerki različno funkcionalnost. To je treba nekako "legitimirati" v predmetu. Dedičenje omogoča, da se odraža homogenost objekta, da se zgradi rodoslovno drevo formaliziranih informacij.

Zveni težko. Če predpostavimo, da je enkapsulacija podatkov preprosta kombinacija podatkov in kode, postane vse preprosto in pojavi se velik koncept.

Predmet so podatki in koda. Primer objekta je samo podatki, do katerih ima dostop njegova koda. Morda je veliko primerov, vendar je koda za njih vedno ista in ni povezana z vsemi, vendar je na voljo vsem.

Ko primerek objekta zahteva posebno pozornost, se pojavi še en predmet, ki bo imel izboljšano funkcionalnost, to je podedoval vse, kar je bilo v prvotnem predmetu, vendar dodaja nekaj svojega.

Svet se napolni s primerki drugega predmeta, ki ima tudi nove potrebe. Nova funkcionalnost in nov objekt.

Vendar ne morejo vsi novi predmeti imeti potomcev. Za nekatere niso več potrebni. Kot rezultat takšne konstrukcije se dobi razgibana slika objektov, v resnici pa daje življenje masi vzorcev, ki so med seboj povezani s pedigri in funkcionalnimi povezavami.

Idealna varianta uresničevanja nalog v slogu OOP je takrat, ko so enkapsulacija, polimorfizem, dedovanje tako kvalitetno premišljeni, da je koda v programu popolnoma odsotna . Predmeti sami opravljajo svoje funkcije, uporabljajo samo svojo kodo, gradijo odnose med seboj.

Življenjska doba OOP

V resnici je vse videti drugače. Inkapsulacija je dobra in tukaj se ne moremo prepirati. Ampak, da zgradimo sliko objektov pravilno, da premislimo o funkcionalnosti vsakega, da predvidimo, kako se bodo določeni vzorci obnašali in kaj se lahko pričakuje od podatkov, ni lahko. Bilo je treba poenostaviti razmere, PLO pa je šla na pot razvojne avtomatizacije delovne sile, namesto da bi reševala resnične težave.

Z vidika hitrosti pridobivanja izkušenj je to učinkovita zamisel, zakaj bi se moral OOP uporabiti za avtomatizacijo računovodskega dela, ko ga lahko vključimo v meni na HTML strani?

Vse je zelo preprosto: obstaja element menija, obstajajo njegove možnosti. Uporabnika lahko povabite, da izbere možnosti menija (navpično, vodoravno, spustno), gumbom pa lahko dodelite obliko (okrogla, kvadratna, zaobljena, itd.).

Malo ljudi se zanima za delo in življenje razvijalca. Vsakdo potrebuje računovodstvo, proizvodnjo, usposabljanje, ker moraš opravljati resnične naloge. Torej morate povečati kolektiv, toda potem bo sistem objektov izvajal različni strokovnjaki in lahko škodujejo drug drugemu.

To je v mnogih pogledih postavilo PLO na proizvodne tračnice. Ni bilo več dvoma: enkapsulacija, dedovanje je dober način, ampak kako zaščititi predmete pred zunanjimi posegi, tako zunaj kot vzdolž rodbine? To ne bo nujno heker. Nenamerno povzroči škodo s spremembo podatkov o predniku, lahko drugi razvijalec.

Sodobno programiranje je veliko razvijalcev v številnih oddaljenih pisarnah. Tako kot čebele sodobni razvijalci zgradijo skupno objektno strukturo. Vsak objekt mora biti zgrajen v skladu s splošnimi pravili, tisti podatki in metode, za katere je odgovoren en programer, ne smejo biti dostopni drugim. Ko nekdo potrebuje nekaj, je druga tema. V skladu z osnovnim načelom vsakdo opravi svoje podjetje na svojem spletnem mestu.

Enkapsulacija je dobra, toda ...

PHPWord je močan izdelek, dobro izdelan in obetaven. Odličen sistem objektov, premišljen in delujoč.

Spodaj je začetek opisa notranjega predmeta tega izdelka. Ena preprosta abstrakcija celice tabele iz splošno prazne abstrakcije - nekakšen zabojnik. In to ni vse opis.

Ni potrebe, da se potopite v divjino, da bi razumeli. Uporaba številnih komentarjev tukaj ne daje jasnosti in besede zaščitene, zasebne in javne, najprej pravijo, da je razvijalec tretje osebe, ki uporablja to knjižnico, spremenil zasebno v javno na pravem mestu (glej komentar: "sc 06/19/2016 je bil zasebno

To je dejstvo napake v kodi, ki jo je razvijalec, ko je bil uporabljen, moral popraviti, zato je moral nekaj spremeniti.

Predvidevamo lahko, da je bilo v fazi razvoja potrebno omejiti dostop do teh ali drugih predmetov, toda tu je pomembna še ena stvar. Obstaja življenje primerov, obstaja življenje predmetov, vendar je že novo življenje - kaj se dogaja s sistemom objektov v njegovi uporabi.

Življenje v razvoju in življenju v aplikaciji. Značilnost sodobnega programiranja je togo zanikanje kontinuitete. Če je prej razvijalec zagotovil, da bo vsaka nova različica dopolnila in izboljšala prejšnjo, potem je danes vsaka nova različica predmeta, jezika, programskega okolja v osnovi ali vsaj bistveno drugačna od prejšnje.

Tudi pogoji gostovanja na gostovanju se lahko spremenijo, tako da morate ponovno izdelati kodo. Pogosto je to zelo težko.

Dobra dednost, dober pridelek

Nihče ni imun na napake. Vsako novo podjetje potrebuje znanje. PHPWord je dobra knjižnica in samo se morate navaditi nanj. Veliko strokovnjakov je porabilo veliko časa. Razvijalec, ki se je zbral za uporabo, bi moral nameniti dovolj časa za proučevanje strukture datoteke Word. To ni skrivnost.

Objektni sistem PHPWord bo postal pregleden in dostopen. Podana je taka, kot je, vendar če obstaja želja, da bi šla še dlje, ker je trenutna funkcionalnost nezadostna. Dobra ideja. Potem je to še en sistem objektov in bolje je, če gre še dlje.

Ni tako slaba ideja težkega zanikanja kontinuitete: spodbuja razvoj znanja. Objekti, ki jih je zgradila ena skupina razvijalcev, so njihove misli o tem, kako rešiti problem, kako predstaviti njegovo funkcionalnost.

Razumevanje te rešitve s strani drugega razvijalca je preobrazba izkušenj. Če si predstavljamo, da je to le prototip potrebnega sistema objektov, zakaj ga potem ne podedujemo? Dobra dednost - značilnost naravne inteligence, se zanaša na nekaj primernega s strani programiranja - to je s področja prihodnosti, čeprav najbližje.

Pravilna inkapsulacija

Inkapsulacija ni kombinacija podatkov in kode. To je kombinacija razpoložljivega in želenega. Če menite, da ne s podatki in algoritmi, ampak zaznavajo realnost in opravljajo ustrezno inkapsulacijo, podedovanje to dejanje od razvijalca do razvijalca, potem je verjetno: pojav sistemov objektov, ki se gibljejo in self-razvoju je še vedno mogoče.