mahla 20. elokuuta 2008 klo 19.09

Polymorfismi aloittelijoille

• PHP

Polymorfismi on yksi kolmesta OOP-paradigmasta. Lyhyesti sanottuna polymorfismi on objektin kykyä käyttää johdetun luokan menetelmiä, joita ei ole olemassa perusluokan luomishetkellä. Niille, jotka eivät ole erityisen perillä OOP:sta, tämä kuulostaa luultavasti monimutkaiselta. Siksi tarkastellaan polymorfismin käyttöä esimerkin avulla.

Ongelman muotoilu

Yksinkertaisin mieleen tuleva vaihtoehto on kirjoittaa kolme erillistä luokkaa ja työskennellä niiden kanssa. Tai kirjoita yksi luokka, joka sisältää kaikki ominaisuudet, jotka ovat ominaisia ​​kaikille kolmelle julkaisutyypille, ja vain välttämättömiä käytetään. Mutta eri tyypeille logiikkaltaan samanlaisten menetelmien pitäisi toimia eri tavalla. Useiden samantyyppisten menetelmien tekeminen eri tyypeille (get_news, get_announcements, get_articles) on täysin tietämätöntä. Tässä polymorfia on hyödyllinen.

Abstrakti luokka

abstrakti luokka Julkaisu
{
// taulukko, joka tallentaa tietoja elementistä
suojattu $pöytä ;

// elementin ominaisuudet ovat meille tuntemattomia
suojattu $ominaisuudet = array();

// rakentaja

{
// Huomaa, että emme tiedä mistä taulukosta tiedot on saatava
$result = mysql_query ("SELECT * FROM `" . $this -> table . "` WHERE `id`="" . $id . "" RAJA 1" );
// emme myöskään tiedä, mitä tietoja saimme
$this -> ominaisuudet = mysql_fetch_assoc ($tulos);
}

//-menetelmä, joka on sama kaikille julkaisuille, palauttaa ominaisuuden arvon
julkinen funktio get_property ($nimi)
{
if (isset($this -> ominaisuudet [ $nimi ]))
palauttaa $this -> ominaisuudet [ $nimi ];

Return false ;
}

//-menetelmä, joka on sama kaikille julkaisuille, asettaa ominaisuuden arvon
julkinen funktio set_property ($nimi, $arvo)
{
if (!isset($this -> ominaisuudet [ $nimi ]))
return false ;

$this -> ominaisuudet [ $nimi ] = $arvo ;

Palauttaa $arvon ;
}

// ja tämän menetelmän pitäisi tulostaa julkaisu, mutta emme tiedä kuinka se tarkalleen tehdään, ja siksi julistamme sen abstraktiksi
abstrakti julkinen funktio do_print();
}

Johdetut luokat

luokka Uutiset laajentaa julkaisua
{
// uutisluokan rakentaja, johdettu julkaisuluokasta
julkinen funktio __konstrukti ($id)
{
// aseta sen taulukon arvo, johon uutiset tallennetaan
$this -> table = "uutistaulukko" ;
vanhempi :: __konstrukti ($id );
}

Julkinen funktio do_print()
{
echo $this -> ominaisuudet ["otsikko" ];
kaiku"

" ;
echo $this -> ominaisuudet ["teksti" ];
kaiku"
Lähde: " . $this -> properties [ "lähde" ​​];
}
}

Luokkailmoitus jatkaa julkaisua
{
// julkaisuluokasta johdetun mainosluokan rakentaja
julkinen funktio __konstrukti ($id)
{
// aseta sen taulukon arvo, johon mainostiedot on tallennettu
$this -> table = "ilmoitukset_taulukko" ;
// kutsuu yläluokan konstruktoria
vanhempi :: __konstrukti ($id );
}

// ohittaa abstraktin tulostustavan
julkinen funktio do_print()
{
echo $this -> ominaisuudet ["otsikko" ];
kaiku "
Huomio! Ilmoitus on voimassa asti ". $this -> ominaisuudet ["end_date" ];
kaiku"

" . $this -> ominaisuudet [ "teksti" ];
}
}

Luokan artikkeli laajentaa julkaisua
{
// artikkeliluokan rakentaja, johdettu julkaisuluokasta
julkinen funktio __konstrukti ($id)
{
// asettaa arvon taulukolle, johon artikkelitiedot tallennetaan
$this -> table = "artikkelitaulukko" ;
// kutsuu yläluokan konstruktoria
vanhempi :: __konstrukti ($id );
}

// ohittaa abstraktin tulostustavan
julkinen funktio do_print()
{
echo $this -> ominaisuudet ["otsikko" ];
kaiku"

" ;
echo $this -> ominaisuudet ["teksti" ];
kaiku"
" . $this -> ominaisuudet [ "author" ];
}
}

Nyt sitten käytöstä

// Täytä julkaisutaulukko julkaisusta johdetuilla objekteilla
$julkaisut = uudet uutiset ($news_id);
$julkaisut = uusi ilmoitus($ilmoituksen_id);
$julkaisut = uusi artikkeli($artikkelin_tunnus);

Foreach ($publications kuin $publication) (
// jos työskentelemme julkaisujen perillisten kanssa
if ($publication instanceof Publication) (
// Tulosta sitten tiedot
$julkaisu -> do_print();
) muu (
// poikkeuksen tai virheen käsittely
}
}

Siinä kaikki. Pienellä käden liikkeellä housuista tulee tyylikkäät shortsit :-).

Polymorfismin tärkein etu on uusien luokkien luomisen helppous, jotka käyttäytyvät samalla tavalla kuin sukulaisluokat, mikä puolestaan ​​mahdollistaa laajennettavuuden ja muunnettavuuden. Artikkeli näyttää vain primitiivisen esimerkin, mutta sekin osoittaa, kuinka abstraktioiden käyttö voi helpottaa kehitystä. Voimme työskennellä uutisten parissa aivan kuten mainosten tai artikkelien kanssa, eikä meidän edes tarvitse tietää, mitä teemme! Todellisissa, paljon monimutkaisemmissa sovelluksissa tämä hyöty on vielä suurempi.

Vähän teoriaa

• Menetelmiä, jotka vaativat ohittamista, kutsutaan abstrakteiksi. On loogista, että jos luokka sisältää ainakin yhden abstraktin menetelmän, se on myös abstrakti.
• On selvää, ettei abstraktin luokan objektia voida luoda, muuten se ei olisi abstrakti.
• Johdetulla luokalla on ominaisuuksia ja menetelmiä, jotka kuuluvat perusluokkaan, ja niillä voi myös olla omat menetelmänsä ja ominaisuutensa.
• Menetelmää, joka ohitetaan johdetussa luokassa, kutsutaan virtuaalimenetelmäksi. Tästä menetelmästä ei ole tietoa perusabstraktissa luokassa.
• Abstraktion tarkoitus on määrittää menetelmä paikassa, jossa on täydellisin tieto siitä, kuinka sen pitäisi toimia.

Ohjelmointi on prosessi, jossa kehitetään ratkaisuja "eläviin", dynaamisiin ongelmiin koodin, datan, funktioiden ja algoritmien jäykkien rakenteiden muodossa. Menettely tiukan syntaksin muodostamiseksi epämääräisestä semantiikasta. Reaalimaailman ongelmat ovat tunnetusti suuri algoritmisoinnin ongelma: halutun ratkaisun saavuttamiseksi ongelma on asetettava tarkkoihin syntaktisiin rakenteisiin.

OOP on kahdesti yrittänyt "rikkoa" tämän vanhan ohjelmointikonseptin, mutta klassisen datakoodauksen ja algoritmien "kahleet" ovat edelleen vahvoja.

Taso ja pätevyys

Tietojenkäsittely alkoi laskennalla, mutta nopeus, jolla liikkeen kiihtyvyys tiedonkäsittelyn alalla kasvaa, ei ole vielä tarpeeksi nopea, jotta klassinen ohjelmointi tulisi mahdottomaksi ja lakkaa olemasta.

On myös objektiivista, että kehittäjä ei vaadi eikä asiakas vaadi todellista ratkaisua todellisiin ongelmiin. Molemmat osapuolet ovat tottuneet siihen, että käytettävissä olevat työkalut ja tutut ominaisuudet rajoittavat heitä.

OOP-polymorfismin muodot, ideat koodin kapseloinnista ja ominaisuuksien (menetelmien) periytymisestä ovat ohjelmoinnin piirissä, mutta eivät ratkaistavan ongelman alueella.

Esimerkkinä tästä on PHPOffice/PHPWord-kirjasto. Sen käyttämiseen tarvitaan kehittäjän pätevyys, sinun on luotava oma objektijärjestelmä, mutta asiakkaan nykyinen taso (asiakasvaatimukset) on triviaali koostumus, jonka ohjelmoija kattaa omalla kehityksellään (muuten vaatimuksia ei voida täyttää ). Tilanne on jotakuinkin tällainen:

Tällöin kirjaston käyttö on asiakirjojen muotoilutehtävää, esimerkiksi diplomi tai väitöskirja on muotoiltava standardin mukaisesti. Asiakas esitti vaatimuksensa, ja ohjelmoija meni omalla tiellään paljon pidemmälle.

Asiakirjan täydellinen jäsentäminen suoritettiin, sen kokoaminen vaaditussa muodossa, työskentely minkä tahansa sisäkkäisen tason taulukoiden kanssa, solujen yhdistäminen ja jakaminen, tulostus mihin tahansa suuntaan jne.

Polymorfismi ja OOP

En voi keksiä parempaa määritelmää polymorfismille kuin viitata olio-ohjelmoinnin idean kehityshistoriaan, joka on nykyään niin suosittu, niin usein käytetty, mutta toteutumatta periaatteessa on edelleen.

• kapselointi;
• polymorfismi;
• perinnön.

Jotkut lisäävät myös: abstraktio, ja useimmiten tätä, ja oikeastaan ​​pääkohtaa, käytetään perustana kuvattaessa OOP:n olemusta.

Mielipiteet OOP:sta ovat siis polymorfisia: ne kuvaavat yhtä asiaa, on suunniteltu eri tavalla tai päinvastoin, ne kuvaavat eri asioita, mutta perustuvat neljään identtiseen kantaan.

Demokratian periaate ei ole tietotekniikan alalle ominaista, mutta sille on annettava ansionsa: useiden samasta asiasta olevien mielipiteiden yhdistelmä ja rinnakkaiselo on todellista monimuotoisuutta toiminnassa.

Polymorfismin suositut määritelmät

OOP on seuraava vaihe tietotekniikan kehityksessä. Harvat ihmiset kiistelevät tämän kanssa, mutta sen tärkeimmät aksioomat ja määräykset eroavat semantiikan suhteen niin paljon, että ne eivät ansaitse huomiota kokonaisuutensa ulkopuolella.

1. Ohjelmoinnin polymorfismi on kyky tarjota sama käyttöliittymä erilaisille taustalla oleville muodoille (tietotyypeille).
2. Polymorfismi on objektien kykyä toteuttaa erilaisia ​​toteutuksia.
3. Polymorfismi on funktion kyky...
4. Classic (C/C++:n luojalta): "yksi käyttöliittymä - monta toteutusta."
5. Parametrinen polymorfismi tarkoittaa...
6. Polymorfismi on tyyppiteorian säännös...
7. Abstraktio on mahdotonta ilman kapselointia ja periytymistä, aivan kuten polymorfismi on mahdotonta ilman periytymistä...

Voimme olla samaa mieltä siitä, että tämä kaikki viittaa samaan asiaan: mutta ajatuksen ilmaisumuoto, olemus ja sisältö eivät ole samanlaisia. Mutta jotain yhteistä on silti.

Entiteetti: kehittäjä - asiakas

Klassinen ohjelmakehitys edellyttää ohjelmoijan ja tehtävän (asiakas, asiakas) läsnäoloa. Ohjelmoija tutkii ongelman, muotoilee sen ja tekee koodin, joka johtaa ratkaisuun. Asiakas kiistää kaiken ehdotetun tai vain osan siitä, huomauttaen puutteista, ja ohjelmoija tekee työnsä uudelleen.

Tämä ongelmanratkaisuprosessin sykli viittaa siihen, että tässä on selkeästi yhdistetty kaksi täysin erilaista kokonaisuutta:

• tietokone ei pysty ratkaisemaan ongelmaa itse;
• tarvitaan ohjelma, jotta tietokone voi "ymmärtää" ja "ratkaista" ongelman.

Tehtävä on asiakkaan toimivalta, ohjelma on algoritmi tehtävän "sopeuttamiseksi" tietokoneen ominaisuuksiin - ohjelmoijan toimivaltaan. Jälkimmäisen tehtävänä on "sopeuttaa" tietokone tehtävän vaatimuksiin, ja tämä on tarpeetonta!

Tarjoukset abstrakti. On esineitä - tämä on asiakkaan ala; on objektien toteutus - tämä on ohjelmoijan ala. Asiakkaan ja kehittäjän välillä ei ole "teknologista" yhteyttä. Idea on radikaali, ei toteutettu tähän päivään mennessä, mutta jokin toimii jo vakaasti.

Ikkunat, painikkeet ja muut esineet

Air Art Technologyn, Object Magazinen, Turbo Visionin, Graph Visionin historia on jo historiaa. Harvat ihmiset muistavat nämä OOP:n toteutukset, ne ovat käytännössä käyttämättömiä ja unohdettuja, mutta Windowsin ikkunakäyttöliittymä on tuttu miljoonille käyttäjille, ja PHP:n, JavaScriptin ja muiden Internet-teknologian kielien objekteja käyttävät sadat tuhannet koodinkehittäjät, ja miljoonat verkkoresurssien vierailijat tietävät niistä.

Tämä on luultavasti ainoa oikea tapa, jolla OOP:n olisi pitänyt kehittyä: kapselointi, periytyminen, polymorfismi kehittäjälle, mutta ei käyttäjälle. On ominaista, että tämä asema oli tärkein Windows-ohjelmistojen ja sovellusohjelmien, kuten Turbo Vision ja Graph Vision, visuaalisen suunnittelun (rajapinnan) kehittämisessä.

Tuotteiden, kuten Air Art Technology ja Object Magazine, konsepti oli huomattavasti erilainen. Tässä abstrakti objekti oli tietorakenteen ensimmäinen esi-isä, joka kapseloi tiedonkäsittelykoodin abstraktilla tasolla. Ikkunoiden, painikkeiden ja visuaalisen suunnittelun elementit olivat tässä toissijaisia.

Ensimmäisessä versiossa (Windows & jne.) OOP-paradigma: kapselointi, perinnöllisyys, polymorfismi määriteltiin abstraktin esi-isän tasolla ja koodin toteutus muodostettiin kunkin tietyn jälkeläisen tasolla perintöhaaran varrella. tarvittavaan rakenteeseen ja sisältöön.

Toisessa vaihtoehdossa (Air Art Technology and Object Magazine) abstraktin kohteen taso on tärkeä. Se, mitä tietyllä jälkeläisellä tulee, ei ole tärkeintä, pääasia on, että sen perintöhaara täyttää kaikkien vanhempien vaatimukset juurabstraktioon asti.

Objekti ja oliojärjestelmä: algoritmi

Ihanteellinen oliokeskeinen konsepti voi vain manipuloida objekteja ja objektijärjestelmiä.

Nykyaikaisissa ohjelmointikielissä objekti (luokka) ymmärretään yleensä objektin kuvaukseksi ja objektin ilmentymäksi, ja objektin kuvauksen käyttämiseksi kielet antavat ohjelmoijalle mahdollisuuden työskennellä staattisten objektien kanssa. dynaaminen objekti - kuvaukset, joilla on oma ainutlaatuinen sisältönsä ja rakenteeltaan, mutta käyttäen samoja kuvausmenetelmiä (ominaisuuksia).

Nykyinen käytäntö liittää objektin käsitteen työkaluun eli ohjelmointikieleen, käyttöliittymään, tietokantapääsyyn, verkkoyhteyteen, mutta mikään ei viittaa asiakkaan etuihin, ratkaistavaan ongelmaan.

Tämä on ihanteellinen yksinkertaiselle OOP:lle: polymorfismi mahdollistaa erityisesti monenlaisten suunnitteluelementtien tekemisen, mutta niiden hallinnan samalla koodilla. Mutta tässä ei puhuta ongelman kohteista, joita ei pidetä lainkaan olio-analyysin kohteena.

Ohjelmoijat ottivat OOP:n käyttöön keinona parantaa työnsä laatua ja tuottavuutta, mutta eivät luovuttaneet asiakkaalle ainuttakaan "alueestaan". OOP:n peruskäsitteet - kapselointi, periytyminen, polymorfismi - jäivät kehitysalueelle, eikä niitä siirretty tehtäväalueelle.

Objekti ja oliojärjestelmä: ongelma ja ratkaisu

Tietokone - ohjelmoija - tehtävä. Keskimmäinen linkki on tarpeeton. Ihannetapauksessa pitäisi olla vain kaksi suhteellisen riippuvaista piiriä: (tietokone - ohjelmoija) - tehtävä. Eli käyttäjällä, asiakkaalla tai vierailijalla on työkalu ratkaista ongelmansa. Asiakas ei välitä kuinka työkalu toteutetaan.

Ihannetapauksessa tämä on vain tietokone, joka pystyy ymmärtämään, mitä asiakas haluaa ja tekemään mitä hän haluaa. Miltä se näyttää: paikallinen ohjelma tai selaimen kautta avattava verkkosivusto, erityinen ohjelma hajautettuun tietojenkäsittelyyn, tietojärjestelmä asiakkaalle - sillä ei ole väliä.

On tärkeää, että tehtävän ja tietokoneen välillä ei ole turhaa yhteyttä, vaan toinen ymmärtää ja ratkaisee ensimmäisen. Tämän tavoitteen saavuttamiseksi tietokone ja asiakas on yhdistettävä yhdeksi objektijärjestelmäksi, ja kunkin objektin merkityksen, rakenteen ja sisällön määrittelee asiakas ja ohjelmoija toteuttaa objektien menetelmät ja ominaisuudet.

On ihanteellista, kun asiakkaan työ hänen tarvitsemansa objektijärjestelmän luomiseksi ja työ näiden kohteiden menetelmien ja ominaisuuksien toteuttamiseksi erotetaan ajallisesti. Mitä kauempana objektijärjestelmän toteutus (ohjelmoija) on sen semanttisesta sisällöstä (asiakas), sitä parempi on prosessin laatu.

Mikään ei estä asiakasta ja ohjelmoijaa olemasta vuorovaikutuksessa ongelmanratkaisuprosessissa, mutta semantiikan selkeä erottaminen on tärkeää. Jokaisen tulee huolehtia omista asioistaan, ohjelmoijalla ei ole velvollisuutta hallita tehtävän laajuutta, eikä asiakas saa ymmärtää koodia, eivätkä osapuolet saa neuvoa toisiaan siinä, mikä ei heitä koske.

Perinteinen ja objektiohjelmointi

OOP:n peruspostulaatit: kapselointi, perinnöllisyys, polymorfismi siinä muodossa, jossa ne ovat tulleet tutuiksi ja kysytyiksi, johtavat huomattavaan koodin laadun ja luotettavuuden paranemiseen, nopeuttavat merkittävästi ohjelmoijan työtä ja niillä on paljon muista positiivisista ominaisuuksista.

Mutta asiat ovat edelleen olemassa: klassinen ohjelmointi ei ole huonompi kuin asemansa, ja monet olio-ideat toteutetaan klassisessa koodissa.

OOP:n ja rekursion ideat johtivat kuitenkin riittävään vaikutukseen klassisten syntaksioperaattoreiden syntaksiin, tavallisen koodin konstruointilogiikkaan, jolla ei ole mitään tekemistä oliosuuntautuneen kirjoitus- ja ajattelutavan kanssa.

Listoja ja jonoja muutettiin, taulukon ensimmäisen ja viimeisen elementin käsite ilmestyi, "jokaiselle" -silmukat ilmestyivät ja viitevaihtoehdot nimeämiseen, käyttöön ja suorittamiseen tulivat entistä suositummiksi.

Itse asiassa se tosiasia, että muuttujat ovat menettäneet "selkeän" kasvonsa (muuttujan tyyppi voi muuttua tarpeen mukaan, eikä muuttujaa tarvitse kuvailla ollenkaan), kertoo, että klassikoista tuli itse asiassa kauan sitten objekti- orientoitunut ja tunnistanut OOP:n perusperiaatteet: kapselointi, periytyminen, polymorfismi merkittävän tärkeänä ideana.

Mihin se perustuu: esineeseen vai järjestelmään?

Abstraktio, OOP:n pääkäsitteellinen asema, riippumatta siitä, missä kohteen vastuualue (toteutus) sijaitsee - ensimmäisen abstraktin objektin tasolla tai tietyn jälkeläisen tasolla - jättää kysymyksen avoimeksi: mistä aloittaa kaikki, kohteesta vai järjestelmästä?

Jos asetat objektin perustaksi, siitä ei koskaan tule järjestelmää, koska järjestelmä on sen sisällä, ja siitä itsestään tulee jäykkä kuva hyvin tietystä alusta. Tässä syntyy ongelmia abstraktion kanssa: alkuobjekti vangitsee tarkasti pääasia ratkaistavassa ongelmassa, eli se ei ole enää siirrettävissä toiseen ongelmaan.

Jos perustamme sen oliojärjestelmään, saamme järjestelmien järjestelmän. Tätä on vaikea kuvitella suhteessa tiettyyn tehtävään, ja on myös vaikea ymmärtää, mistä kehitys kannattaa aloittaa. Yleisesti ottaen OOP:n polymorfismi kokonaisuutensa, toteutusmuotoineen ja funktioiden todellisten parametrien lukumääräineen antaa käsityksen alussa olevasta järjestelmästä seuraavasti:

• ongelmanratkaisuvaihtoehdoista (esimerkiksi valikko);
• alkuolosuhteista (ongelman soveltaminen eri olosuhteissa, tiedot);
• käyttötavoista (testaus, asetus, käyttö).

Mutta tämä ja vastaavat eivät anna mitään perustetta perustaa ongelman ratkaisua oliojärjestelmään. Usein riittää, että määritellään yksi aloitusobjekti.

Ongelmanratkaisuprosessin historia

OOP:n tärkeimmät periaatteet: polymorfismi ja abstraktio - priorisoi alkuperäinen kohde oliojärjestelmänä. Keskustelussa siitä, kumpi tulee olla ensin, kana vai muna, tässä kana voittaa.

Ei ole epäilystäkään siitä, että kaiken täytyy alkaa abstraktista esineestä, ei objektijärjestelmästä. Mutta jos otamme huomioon aikatekijän ja soveltamme sitä jokaisen kohteen tasolla, alkaen aivan ensimmäisestä abstraktista, niin ristiriitainen ajatus sekä kohteen että järjestelmän asettamisesta päätöksen alkuun on ainoa järkevä.

Jos klassinen ohjelmoinnin käsite muuttaa ongelman ratkaisemisen aikana dataa, tietokannan sisältöä, muuttaa tiedostoja jne., niin OOP:n käsitteessä polymorfismi, kapselointi ja aikatekijä muuttavat sisältöä, rakennetta ja ratkaistavan ongelman objektijärjestelmän ominaisuudet.

OOP:n ohjelmoija on vähiten kiinnostunut tiedoston, tietokannan, algoritmin käsitteestä - nämä ovat yksityiskohtia; tässä ohjelmoija ajattelee objekteissa, mutta objektit ovat olemassa ajassa ja muuttuvat halutun saavuttamisen myötä.

Alussa siis on objekti oliojärjestelmänä ja tämän järjestelmän logiikka - aika-asteikko: tehtävän käynnistäminen, ensimmäisen objektin muodostaminen, tietojen syöttäminen tai kerääminen, seuraavan objektin muodostaminen, mutta mikään ei estä ensimmäistä objektia tekemästä siirrytään seuraavaan ratkaisuun.

Jokainen objektitaso toimii itsenäisenä esinejärjestelmänä, eli se on yksi objekti, mutta alkaneen prosessin ja ajan merkityksen kontekstissa se on aika-asteikon objektijärjestelmä. OOP:n täysimääräistä toteutusta varten polymorfismi, periytyminen ja aikatekijä yhdessä varmistavat ensimmäisen dynamiikan, eli objekti ei voi vain muuttua ajan myötä, vaan myös tuottaa objekteja, joita kehittäjä ei ole aikonut ja jotka luodaan suorittamalla asiakkaan suunnittelema tehtävä prosessin aikana.

Todellinen OOP-polymorfismi, esimerkki

OOP:n tekemien ongelmien monimutkaisuus ei ole verrattavissa siihen, mikä on mahdollista kirjoitusohjelmien klassisen version kanssa. Tietenkin on aina mahdollista ratkaista mikä tahansa ongelma tavanomaisella tavalla, mutta kysymys siitä, kuinka paljon se "maksaa" aikaa ja vaivaa, tekee tuloksesta usein hyödyttömän.

PHPOffice/PHPWord-kirjasto kehitettiin vähän aikaa sitten, mutta sen ominaisuuksien käyttäminen edellyttää melkein aina oman objektijärjestelmän luomista. Esimerkiksi yksinkertainen *.docx-tiedosto:

on zip-arkisto monista tiedostoista ja kansioista Office Open XML -muodossa (OpenXML, OOXML). Jokainen tiedosto on kirjoitettu XML-tunnisteilla, ja kun kirjaimia, sanoja, taulukoita, luetteloita ja muita elementtejä lisätään, muutetaan ja poistetaan, tiedostojen sisältö alkaa edustaa sarjaa tunnisteita, jotka eivät aina sisällä kokonaisia ​​elementtejä; usein yksi elementti on kirjoitettu useilla tunnisteilla.

Jos kuvittelet tämän tiedoston tunnisteiden sarjana, saat mielenkiintoisen kuvan:

On helppo huomata, että asiakirjan ensimmäinen ja ainoa kappale on esitetty useilla tunnisteilla. Mitä tulee taulukkoon ja siihen rakennettuihin taulukoihin, kaikkien elementtien kuvauksen määrää ei voida havaita, mutta se on oliosovelluksen käytettävissä.

Itse asiassa kuvassa vihreä on tunnisteiden testitulos, keltainen on tunnisteen parametrit ja tyyppi ja beige on sisältö. Luodut objektit on suunnattu konekäsittelyyn. Vain asiakirjatiedoston avaamis-, muotoilu- ja kirjoitustoiminnot tulevat henkilön saataville.

Ratkaisu on yksinkertainen ja käytännöllinen, mutta toteutus on enemmän tietokone- kuin ihmislähtöistä suoritettujen toimintojen määrän ja monimutkaisten objektien välisten suhteiden vuoksi.

OOP-alueen osavaltio

Verkkosivustojen hallintajärjestelmien kehitys, palvelinten perustamis- ja hallintateknologiat sekä kokemus dynaamisten verkkosivustojen kehittämisestä ovat tehneet olio-ohjelmoinnin kaikkien saatavilla. Ongelmana on, kuinka muuttaa ajatteluasi ja tottua ajattelemaan objektien tasolla, ei peräkkäin suoritettavan koodin yhteydessä.

Tyypillisesti siirtyminen klassisesta ohjelmoinnista olioohjelmointiin kestää kahdesta kolmeen kuukautta, mutta kustannukset ovat enemmän kuin sen arvoisia. Nykyaikaisten ohjelmointikielten, ensisijaisesti PHP:n ja JavaScriptin, mahdollisuudet tyydyttävät kaikkein edistyneimmätkin kehittäjät.

Nykyaikainen OOP - polymorfismi, periytyminen ja kyky muodostaa objektin ominaisuuksia - ovat käteviä ja käytännöllisiä, kielen syntaksi ja aputyökalut varmistavat käytön helppouden ja koodin tehokkuuden.

Näkökulmat esineideaan

On melko vaikea sanoa, kuinka kauan klassinen ohjelmointi kestää ja miten OOP kehittyy. Ilmeisesti työkalujen kehittäjät eivät aio ottaa huomioon kuluttajan kontekstia (käyttäjä, asiakas).

OOP-työkalut - polymorfismi, periytyminen, kapselointi ja abstraktio - ovat kehittäjäkeskeisiä.

Nykyaikaiset tietojärjestelmät ja verkkoresurssit pyrkivät heijastamaan todellisuutta, varmistamaan todellisten esineiden toiminnan ja luomaan niiden toiminnalle ympäristön, joka on niin yksinkertainen, että se on ohjelmoinnista kaukana olevan ja täysin omaan alueeseensa uppoutuneen kuluttajan saatavilla. pätevyyttä.

PHP, OOP, kapselointi, perinnöllisyys, polymorfismi

Tällä oppitunnilla kerron kolmesta olio-ohjelmoinnin peruskäsitteestä: kapselointi, periytyminen, polymorfismi; Ja opetan sinulle kuinka niitä käytetään kehityksessä.

Kapselointi

Kapselointi - omaisuutta ohjelmointikieli, jonka avulla voit yhdistää ja suojata tietoja ja koodia objektiksi ja piilota toteutus objekti käyttäjältä (ohjelmoijalta). Samaan aikaan käyttäjä tarjotaan vain määritys ( käyttöliittymä) objekti.

Toisin sanoen, kun työskentelemme hyvin suunnitellun luokan kanssa, voimme nauttia vain hänen menetelmillään, syventymättä miten ne rakennetaan ja miten ne toimivat luokkakenttien kanssa. Puhumme tilanteesta, jossa työskentelemme muiden ohjelmoijien kehittämän luokan kanssa. Käytämme vain jo toteutettuja toimintoja.

Otetaan toinen esimerkki. Kapseloinnin periaatteet sisäisen toteutuksen piilottamiseen on upotettu mihin tahansa PHP-toimintoon. Saatat jo tietää toiminnon strpos() PHP-standardikirjaston merkkijonojen kanssa työskentelyyn. Tämä funktio etsii merkkijonosta tiettyä merkkijonoa ja palauttaa sen sijainnin numerona. Jos ajattelemme tämän funktion toteutusta, voimme olettaa, että meidän on kierrettävä jokainen merkki rivin alusta, jotta voimme löytää vastaavuuden etsityn sekvenssin alkuperäisen merkin kanssa, ja jos on, vertaa kahta seuraavaa merkkiä, jne. Mutta meille ohjelmoijille ei tarvitse ajatella tämän yläpuolelle ja syventyä tämän toiminnon toteuttamisen monimutkaisuuteen. Meillä on tarpeeksi tietää parametrit jonka se hyväksyy ja muoto palautusarvo. Strpos()-funktio kapseloi ratkaisun alimerkkijonon löytämisen ongelmaan ja tarjoaa meille vain ulkoisen käyttöliittymän sen käyttöä varten.

Samoin hyvin suunnitellut luokat piilottavat sisäisen toteutuksensa paljastamalla käyttöliittymän ulkoisille käyttäjille joukkona menetelmiä.

PHP-kielessä kapseloinnin käsite on toteutettu erityisten kenttien ja luokkamenetelmien pääsymuutosten muodossa. Puhumme tästä myöhemmin.

Perintö

Periytys on olio-ohjelmointimekanismi, jonka avulla voit kuvata uutta luokkaa perustuu jo olemassa oleviin(emoluokka), kun taas uusi luokka lainaa yläluokan ominaisuudet ja toiminnot.

Otetaanpa tosielämän esimerkki perinnöstä. Voit ottaa luokan geometrisen hahmon. Samanaikaisesti emme täsmennä, mikä tietty luku pitäisi olla. Mitä ominaisuuksia kuviosta voidaan tunnistaa? Oletetaan, että sillä on väriä. Tällöin kuviota kuvaavalla luokalla tulee olla vastaava merkkijonotyyppinen kenttä, joka määrittää kuvion värin. Lisäksi kaikilla geometrisilla kuvioilla on alue. Olkoon pinta-ala luokkamme toinen ominaisuus.

Oletetaan nyt, että ohjelmamme on toimittava tietyt geometriset muodot: neliöitä Ja kolmiot mukaan lukien niiden geometrinen sijainti tasossa. Ilmeisesti kolmioiden ja neliöiden kuvaaminen luokan avulla Kuva ei riitä, koska se ei tallenna geometristä sijaintitietoa. Siksi meidän on lisättävä kaksi luokkaa: Neliö Ja Kolmio. Sanotaan samalla, että ohjelmassamme tarvitaan myös figuurien värejä ja alueita. Tämä tilanne vaatii nimenomaan perinnön käyttöä. Koska mikä tahansa neliö ja kolmio ohjelmassa on ilmeisesti kuvio, eli sillä on väri ja pinta-ala. Samanaikaisesti jokainen kuva vaatii lisätietoa (värin ja alueen lisäksi) kuvaukseensa, mikä ratkaistaan ​​ottamalla käyttöön kaksi lisäluokkaa neliöitä Ja kolmiot, jotka on peritty luokasta Kuva.

Tämä tarkoittaa sitä, että luokissa Neliö Ja Kolmio meidän ei tarvitse määrittää väri- ja aluekenttiä uudelleen. Riittää, kun osoitetaan, että mainitut luokat perivät Figure-luokasta.

Katsotaanpa nyt toista esimerkkiä, joka on lähempänä web-ohjelmoijien todellisuutta. Nykyään erilaiset blogit ovat saavuttaneet valtavan suosion Internetissä. Itse asiassa blogi on vain kokoelma artikkeleita. Ja avainolemus blogin kehittämisessä on artikkeli.

Kuvitellaan nyt, että tulevassa blogissamme artikkelit voivat olla erilaisia. Keskitytään ensin kahteen tyyppiin: tavalliseen muistiinpanoartikkeliin ja uutisartikkeliin. Uutisartikkelille sen julkaisupäivä on tärkeä, koska se sisältää tiettyjä uutisia.

Tämän tilanteen toteuttamiseksi PHP:ssä meidän on määritettävä kaksi luokkaa: luokka tavalliselle muistiinpanoartikkelille ja luokka uutisartikkelille. Samalla saa uutisartikkelin laajentaa tavallisen artikkelin ominaisuuksia, ts. peritty häneltä. PHP:n luokkien perimiseksi käytetään avainsanaa ulottuu.

Luokka (... // luokan sisältö) luokka (... // luokan sisältö)

Seuraava koodi määrittelee luokan Uutisartikkeli perillisenä Artikla. Luokka Artikla puolestaan ​​on luokan vanhempi Uutisartikkeli. Tämä tarkoittaa, että luokan kentät ja menetelmät Artikla on myös läsnä luokassa Uutisartikkeli, eikä niitä tarvitse määritellä uudelleen.

Perinnön avulla voit rakentaa kokonaisen luokkien hierarkian perimällä toisiaan. Samanaikaisesti missä tahansa luokassa voi olla vain yksi vanhempi:

Joskus saatamme tarvita uudelleenmääritellä yksi emoluokan menetelmistä. Näytetään luokan toteutus uudelleen Artikla:

Luokkaartikkeli ( ... // luokkakentät // artikkelin funktion näyttämistoiminto view() ( echo "

$this->titteli

$tämä->sisältö

Oletetaan, että uutisartikkelin tulosteen tulee olla erilainen kuin tavallisen artikkelin esityksen, ja lisäksi tulisi tulostaa uutisen julkaisuaika. Samaan aikaan luokassa Artikla menetelmä on jo olemassa katso(), joka vastaa artikkelin tulostamisesta. Voit tehdä sen kahdella tavalla. Ensimmäisessä tapauksessa voit keksiä uuden menetelmän luokassa Uutisartikkeli esimerkiksi nimellä katso uutiset() erityisesti uutisten näyttämiseen. On kuitenkin oikeampaa käyttää samoja menetelmiä samanlaisten toimien suorittamiseen perityissä luokissa. Siksi on parempi, jos menetelmä uutisten näyttämiseen luokassa Uutisartikkeli kutsutaan samalla nimellä kuin pääluokassa - katso(). Tällaisen logiikan toteuttamiseksi PHP:ssä on mahdollista ohittaa ylätason menetelmät, eli asettaa menetelmiä lapsiluokkiin, joiden nimet vastaavat yläluokkia. Näiden menetelmien toteuttaminen yläluokissa on tässä tapauksessa merkityksetöntä jälkeläisluokille. Otetaan esimerkki luokasta Uutisartikkeli ohitetulla menetelmällä katso():

Luokka NewsArticle laajentaa artikkelia ( $datetime; // uutisen julkaisupäivä // artikkelin funktionäkymän näyttämistoiminto() ( echo "

$this->titteli

$tämä->sisältö

Seuraava koodi käyttää toimintoa strftime(), jonka avulla voit näyttää päivämäärät kätevässä muodossa. Ymmärtääksesi koodin paremmin, tutustu tämän toiminnon spesifikaatioihin viitteessä. Meille nyt on tärkeää, että kiinnität huomiota siihen, että luokka Uutisartikkeli, yhtä hyvin kuin Artikla, määrittelee menetelmän katso(). Näin ollen kaikki tämän luokan objektit käyttävät menetelmää katso() ilmoitettu luokassa Uutisartikkeli, ei mukana Artikla.

Saatat ihmetellä: miksi on tärkeää ohittaa jotkin menetelmät sen sijaan, että ottaisit käyttöön uusia menetelmiä jälkeläisluokissa? Tämän ymmärtäminen tulee ymmärtämään seuraavaksi tärkeintä OOP:n käsitettä.

Polymorfismi

Polymorfismi - esineiden vaihdettavuus samalla käyttöliittymällä.

Ohjelmointikieli tukee polymorfismia, jos saman spesifikaation luokilla voi olla erilaisia ​​toteutuksia - esimerkiksi luokan toteutusta voidaan muuttaa periytymisprosessin kautta. Juuri tämän näimme edellisen artikkelin esimerkissä.

Katsotaanpa seuraavaa esimerkkiä, joka antaa polymorfismin olemuksen ymmärtäminen:

Luokka A (funktio Test() ( echo "Tämä on luokka A
"; ) Function Call() ( $this->Test(); ) ) luokka B laajentaa A:n (funktio Test() ( echo "Tämä on luokka B
"; ) ) $a = uusi A(); $b = uusi B(); $a->Call(); // tulostaa: "Tämä on luokka A" $b->Test(); // tulostaa: "Tämä on luokka B" $b->

Kiinnitä huomiota kolmen viimeisen rivin kommentteihin. Kokeile itse selitä tämä tulos. On suositeltavaa toteuttaa ja testata tämä esimerkki itse. Käytä aikaa varmistaaksesi, että käsikirjoituksen toiminta tulee sinulle täysin selväksi, sillä tämä pieni esimerkki sisältää OOP:n syvän merkityksen. Yritetään nyt jäsentää ehdotettu koodi yhdessä.

$a->Soita(); // tulostaa: "Tämä on luokka A"

Tämä rivi kutsuu menetelmää Puhelu() luokan objektissa A. Kuten funktiossa on määritelty Puhelu() luokkaa A, menetelmää kutsutaan Testata(). Menetelmän harjoitteleminen Testata() luokan objektissa A, ja teksti "Tämä on luokka A" näkyy näytöllä.

$b->Testi(); // tulostaa: "Tämä on luokka B"

Tämä rivi kutsuu menetelmää Testata() luokan objektissa B. Menetelmä Testata() luokkaa B näyttää tekstin "Tämä on luokka B".

$b->Soita(); // tulostaa: "Tämä on luokka B"

Lopuksi viimeinen rivi kutsuu luokkaa Puhelu() luokan objektissa SISÄÄN. Mutta luokan toteutuksessa B emme näe tällaista menetelmää, mikä tarkoittaa, että se on peritty luokasta A, koska luokka B on luokan jälkeläinen A. Mitä näemme menetelmän toteutuksessa? Puhelu() luokkaa A? Seuraava koodi:

$this->Test();

Menetelmä Puhelu() kutsuu menetelmää Testata() esine, jossa se sijaitsee. Tämä tarkoittaa, että menetelmä toimii Testata() luokan objekti B. Tämä selittää näytöllä näkyvän tuloksen.

Tästä on kyse polymorfismin periaate. Luokilla voi olla samat menetelmät, mutta niiden toteutus on erilainen. Kun kehitämme skriptikoodia, voimme tietää vain niiden menetelmien yleiset määrittelyt luokkaryhmälle, mutta meillä ei ole aavistustakaan, mitä esiintymää mistä luokasta käytetään tietyllä hetkellä.

Kapseloinnin, periytymisen ja polymorfismin käsitteitä voidaan kutsua OOP:n kolme pilaria. Näiden käsitteiden periaatteiden ymmärtäminen ja asiantunteva soveltaminen - menestyksen resepti kehittäminen OOP:n avulla.

Hei! Tämä on artikkeli yhdestä OOP:n periaatteesta - polymorfismista.

Mikä on polymorfismi

Polymorfismin määritelmä kuulostaa pelottavalta :)

Polymorfismi- tämä on mahdollisuus käyttää samannimistä menetelmiä samoilla tai eri parametrijouksilla yhdessä luokassa tai periytymissuhteen kautta liittyvien luokkaryhmien ryhmässä.

sana" polymorfismi"voi tuntua monimutkaiselta - mutta se ei ole sitä. Sinun tarvitsee vain jakaa tämä määritelmä osiin ja näyttää esimerkein, mitä tarkoitetaan. Usko minua, artikkelin lopussa tämä polymorfismin määritelmä näyttää sinulle selvältä :)

Polymorfismi, jos käännetään, tämä tarkoittaa "monia muotoja" Esimerkiksi näyttelijä teatterissa voi kokeilla monia rooleja - tai ottaa "monia muotoja".

Koodimme on sama - polymorfismin ansiosta siitä tulee joustavampi kuin ohjelmointikielissä, jotka eivät käytä OOP-periaatteita.

Mistä muodoista siis puhumme? Otetaan ensin esimerkkejä ja osoitetaan kuinka polymorfismi ilmenee käytännössä, ja sitten palataan sen määritelmään.

Miten polymorfismi ilmenee?

Tosiasia on, että jos Javalla ei olisi polymorfismin periaatetta, kääntäjä tulkitsee tämän virheeksi:

Kuten näette, kuvan menetelmät eroavat niiden hyväksymistä arvoista:

• ensin hyväksyy int
• ja toinen hyväksyy merkkijono

Koska Java kuitenkin käyttää polymorfismin periaatetta, kääntäjä ei käsittele tätä virheenä, koska tällaisia ​​menetelmiä pidetään erilaisina:

Nimeämismenetelmät sama on erittäin kätevä. Jos meillä on esimerkiksi menetelmä, joka etsii luvun neliöjuurta, on paljon helpompi muistaa yksi nimi (esim. sqrt()) kuin yksi erillinen nimi samalle menetelmälle, joka on kirjoitettu kullekin tyypille:

Kuten näette, meidän ei tarvitse keksiä jokaiselle menetelmälle erillistä nimeä - mutta tärkeintä on muistaa ne! Erittäin mukavasti.

Nyt voit ymmärtää, miksi tätä periaatetta kuvataan usein lauseella:

Yksi käyttöliittymä - monta menetelmää

Tämä olettaa, että voimme täyttää yhden nimen (yhden käyttöliittymän), jonka kautta voimme käyttää useita menetelmiä.

Menetelmän ylikuormitus

Sitä, mitä yllä näytimme - useita menetelmiä samalla nimellä ja eri parametreilla - kutsutaan ylikuormitus. Mutta tämä oli esimerkki menetelmän ylikuormituksesta yhdessä luokassa. Mutta on toinenkin tapaus - pääluokan ohittavat menetelmät.

Vanhemman menetelmien ohittaminen

Kun perimme luokan, perimme kaikki sen menetelmät. Mutta jos haluamme muuttaa jotakin perimistämme menetelmistä, voimme vain ohittaa sen. Meillä ei ole esimerkiksi velvollisuutta luoda tarpeisiimme erillistä samannimistä menetelmää, vaan perinnöllinen menetelmä on luokassamme ”kuollut paino”.

Sitä tosiasiaa, että voimme luoda luokan jälkeläisluokkaan, jolla on sama nimi kuin vanhemmalta perimällämme luokka, kutsutaan ohittamiseksi.

Esimerkki

Kuvitellaan, että meillä on tämä rakenne:

Luokkahierarkian huipulla on luokka Eläin. Sen on perinyt kolme luokkaa - Kissa, Koira Ja Lehmä.

"Animal"-luokassa on "ääni"-menetelmä. Tämä menetelmä näyttää "Voice"-viestin näytöllä. Luonnollisesti koira tai kissa ei sano "Voice" :) Haukkuu ja miau. Vastaavasti sinun on asetettava eri menetelmä luokille Kissa, Koira Ja Lehmä- niin, että kissa miau, koira haukkuu ja lehmä sanoo "Moo".

Siksi jälkeläisluokissa ohitamme menetelmän ääni(), jotta saamme "Meow", "Woof" ja "Moo" konsoliin.

• Huomaa: ennen ohitettavaa menetelmää kirjoitamme " @Ohittaa". Tämä kertoo kääntäjälle, että haluamme ohittaa menetelmän.

Mitä on polymorfismi

Polymorfismi on kuitenkin periaate. Kaikki yllä antamamme todelliset esimerkit ovat oikeita tavoilla polymorfismin toteutus.

Katsotaanpa uudelleen määritelmää, jonka annoimme artikkelin alussa:

Polymorfismi- kyky käyttää samannimisiä menetelmiä samoilla tai erilaisilla parametreilla yhdessä luokassa tai periytymissuhteen kautta liittyvien luokkaryhmien ryhmässä.

Näyttää selkeämmältä, eikö? Näitimme, kuinka voit:

• luo "samannimiset menetelmät" yhteen luokkaan ("method overloading")
• tai muuttaa yläluokan menetelmien käyttäytymistä ("metodin ohittaminen").

Kaikki nämä ovat ilmentymiä oliosuuntautuneiden kielten "lisääntyneestä joustavuudesta", joka johtuu polymorfismista.

Toivomme, että artikkelistamme oli sinulle hyötyä. Voit ilmoittautua Java-kursseillemmemeillä on päällä.

Polymorfismi on OOP-periaate, jonka avulla voit käyttää yhtä käyttöliittymää ja erilaisia ​​algoritmeja. Polymorfismin tavoitteena OOP:hen sovelletuna on käyttää yhtä nimeä eri toimien määrittämiseen. Toiminnon suorittaminen määräytyy tietotyypin mukaan.

Polymorfismin tyypit:

Staattinen (määritetty käännöshetkellä). Ylikuormitetaan toimintoja, menetelmiä, operaattoreita jne.

Dynaaminen (määritetty ajon aikana). Sisältää virtuaalisia toimintoja ja menetelmiä.

22. Periytys mekanismina polymorfismin toteuttamiseksi ja luokkahierarkioiden luomiseksi. Perinnön tyypit.

Periytys on OOP-mekanismi, jonka avulla luodaan uusia luokkia olemassa olevien luokkien perusteella. Nämä luokat perivät perusluokkien ominaisuudet ja käyttäytymisen ja voivat hankkia uusia. Näin voit pienentää ohjelman kokoa ja sen kehittämisen aikaa. Polymorfismin avulla voimme kirjoittaa ohjelmia käsittelemään monenlaisia ​​loogisesti toisiinsa liittyviä luokkia. Periytys ja polymorfismi ovat tehokkaita tekniikoita monimutkaisten ohjelmien kehittämiseen.

Perinnön tyypit: suora ja epäsuora, yksinkertainen ja moninkertainen.

23. Luokat. Perus, johdettu, polymorfinen, abstrakti, virtuaalinen. Esimerkkejä.

Luokka on erityinen tietotyyppi, joka kuvaa sekä tietomääritteitä että määritteille suoritettuja toimia.

Perusluokka on luokka, jonka jäsenet ovat periytyviä.

Johdettu luokka on luokka, joka perii muut jäsenet.

Polymorfinen luokka on luokka, joka sisältää virtuaalisia menetelmiä.

Abstrakti luokka on luokka, joka sisältää puhtaasti virtuaalisia menetelmiä.

Virtuaaliluokka on luokka, joka ei moniperinnön aikana sisälly jälkeläisluokkiin, vaan korvataan niissä olevalla viitteellä päällekkäisyyden välttämiseksi.

24. Aikaisen ja myöhäisen sitomisen periaatteet.

Sidonta on menettely, jolla muodostetaan yhteys ohjelmakoodissa käytetyn tunnisteen ja sen fyysisen objektin (yleensä mikä tahansa ohjelmistokomponentti: muuttuja, menettely, moduuli, sovellus jne.) välille.

Varhainen sidonta on tällaisten yhteyksien muodostamista ennen ohjelman suorittamisen aloittamista. Tämä tarkoittaa yleensä lähdemoduulien linkittämistä ja suoritettavan moduulin linkittämistä objektimoduuleista käännösprosessin aikana.

Myöhäinen sidonta on yhteyksien muodostamista ohjelman suorittamisen aikana. Yleensä puhutaan joko dynaamisista yhteyksistä (kun vain sovelluksen toiminnan aikana määritetään, mitä objekteja tarvitaan) tai tällaisten objektien muodostumisesta toiminnan aikana.

25. UML:n käyttäminen määrittelyyn

26. Luokkahierarkioiden kuvaus uml-kaavioilla.

Luokkasuhteet kautta . Ja näytä erilaisia ​​suhteita: suoria, epäsuoria, useita.

27. Malliluokat. Kuvaus uml.

Luokkamalli on C++-kielen työkalu, joka on suunniteltu koodaamaan yleistettyjä luokkaalgoritmeja ilman viittausta tiettyihin parametreihin (esimerkiksi tietotyypit, puskurin koot, oletusarvot).

Syntaksi:

sapluuna

luokka NAME_CLASS

NAME_CLASS B; //Puhelu