Kan du forklare forskellen mellem procedureprogrammering og OOP?


Svar 1:

Originalt spørgsmål:

Kan du forklare forskellen mellem procedureprogrammering og OOP?

Svar:

Først skal vi først definere, hvad proceduremæssig og objektorienteret programmering betyder.

Definition - Hvad betyder proceduresprog? Et proceduresprog er en type computerprogrammeringssprog, der specificerer en række velstrukturerede trin og procedurer inden for dens programmeringssammenhæng til at komponere et program. Det indeholder en systematisk rækkefølge af udsagn, funktioner og kommandoer til at gennemføre en beregningsopgave eller et program. Processtedssprog er også kendt som imperativt sprog.Techopedia forklarer Procedural Language Et proceduresprog, som navnet antyder, er afhængig af foruddefinerede og velorganiserede procedurer, funktioner eller underrutiner i et programs arkitektur ved at specificere alle de trin, computeren skal tage for at nå en ønsket tilstand eller output. Processproget adskiller et program inden for variabler, funktioner, udsagn og betingede operatører. Procedurer eller funktioner implementeres på dataene og variablerne for at udføre en opgave. Disse procedurer kan kaldes / påberåbes hvor som helst mellem programhierarkiet og af andre procedurer. Et program, der er skrevet på proceduresprog, indeholder en eller flere procedurer. Procesprog er et af de mest almindelige typer programmeringssprog, der er i brug, med bemærkelsesværdige sprog som C / C ++, Java, ColdFusion og PASCAL.

Lad os nu definere objektorienteret programmering.

Definition - Hvad betyder Objektorienteret programmering (OOP)? Objektorienteret programmering (OOP) er en softwareprogrammeringsmodel konstrueret omkring objekter. Denne model inddeler data i objekter (datafelter) og beskriver objektindhold og adfærd gennem erklæringen af ​​klasser (metoder). OOP-funktioner inkluderer følgende: Indkapsling: Dette gør programstrukturen lettere at styre, fordi hvert objekts implementering og tilstand er skjult bag veldefinerede grænser. Polymorfisme: Dette betyder, at abstrakte enheder implementeres på flere måder. Arv: Dette henviser til det hierarkiske arrangement af implementeringsfragmenter. Objektorienteret programmering muliggør forenklet programmering. Dens fordele inkluderer genanvendelighed, refactoring, udvidbarhed, vedligeholdelse og effektivitet. Tekopedia forklarer Objektorienteret programmering (OOP) OOP har været den valgte programmeringsmodel i det sidste årti eller mere. OOPs modulopbyggede design giver programmerere mulighed for at opbygge software i håndterbare bidder snarere end i store mængder af rækkefølge-kode. En af de store fordele ved OOP er skalerbarhed, med objekter og definitioner, der ikke har nogen begrænset begrænsning. Adskillelsen af ​​data fra metoden forhindrer også et almindeligt problem, der findes i ældre lineære softwaresprog. Hvis der vises en fejl i en lineær kode, kan den oversættes gennem et system og skabe masser af vanskelige at spore fejl. Omvendt er et OOP-program med dens adskillelse af metode og data ikke modtageligt for sådanne spredte fejl. Populære OOP-sprog inkluderer Java, C-familien af ​​sprog, VB.NET Shop og Python. Såkaldte "rene" OOP-sprog inkluderer Scala, Ruby, Eiffel, JADE, Smalltalk og Emerald.

Kilden til definitionerne kommer fra Hvad er objektorienteret programmering (OOP)? - Definition fra Techopedia, og hvad er et proceduresprog? - Definition fra Techopedia

Nu. Lad os se på forskellen implementering klogt.

Vi begynder med proceduremæssige, og den nemmeste måde at gøre dette på er at bruge C-sproget specifikt med Arduino, da det er det, jeg ved.

Jeg besluttede at bruge blinkende lysvejledningen som basis, da det er en af ​​de grundlæggende implementeringer.

// opsætningsfunktionen kører én gang, når du trykker på nulstilling eller tænder opsætningen af ​​tomrættet for ugyldighed () {// initialiser digital pin LED_BUILTIN som en udgang. pinMode (LED_BUILTIN, OUTPUT); } // loop-funktionen kører igen og igen for evigt void loop () {digitalWrite (LED_BUILTIN, HIGH); // tænd LED'en (HIGH er spændingsniveauet) forsinkelse (1000); // vent på en anden digitalWrite (LED_BUILTIN, LAV); // Sluk for LED ved at foretage spændingen LAV forsinkelse (1000); // vent et øjeblik}

Lad mig nu forklare koden lidt bedre. Du har to funktioner Setup og Loop. Loopen kaldes gentagne gange, og opsætningen kaldes kun én gang. Du sender digitalWrite-kommandoen til lysdioden for at sætte effektgraden til henholdsvis høj og lav. Forsinkelse er, hvor længe lyset vil forblive tændt eller slukket, i dette tilfælde 1000 ms eller ca. 1 sekund. Temmelig lige frem, men dette viser, at du er det væsentlige ved procedureprogrammering. Du skriver en procedure eller en instruktion, og den gentages, indtil den slutter. Der er ingen yderligere kompleksitet til den krævede kode.

C # og OOP eksempel tid.

ved hjælp af system; ved hjælp af System.Collections.Generic; ved hjælp af System.Linq; ved hjælp af System.Text; namespace ups {public class customer {// Member Variables public int CustID; offentlig streng Navn; offentlig streng adresse; // constuctor til initialisering af felter kunde () {CustID = 1101; Name = "Tom"; Adresse = "USA"; } // metode til visning af kundeposter (funktionalitet) public void displayData () {Console.WriteLine ("Customer =" + CustID); Console.WriteLine ( "name =" + navn); Console.WriteLine ( "Address =" + adresse); } // Kode til indgangspunkt}} Klasseprogram {statisk tomrum Main (streng [] args) {// objekt instantiation customer obj = new customer (); // Metode til opkald til obj.displayData (); // felter, der ringer Console.WriteLine (obj.CustID); Console.WriteLine (obj.Name); Console.WriteLine (obj.Address); }}}

Her er et klassisk eksempel på OOP. Du har en kundeklasse, der definerer alle de objekter, du har til rådighed for dig. Du har stadig funktioner / metoder til at skrive. Men den vigtigste forskel er, at du vil dele hver metode / funktion op efter, hvad den skal gøre. Derfra er din hovedmetode programmets indgangspunkt og bør derfor have din kritiske kode her.


Svar 2:

OOPS-koncept i Java

Proceduresprog er baseret på funktioner, men objektorienteret sprog er baseret på objekter i den virkelige verden.Proceduresprog giver betydning for sekvensen af ​​funktionsudførelse, men objektorienteret sprog giver betydning for objekternes tilstand og opførsel. Processproget udsætter dataene for hele programmet men objektorienteret sprog indkapsler dataene. Procesformatisk sprog følger top-down programmeringsparadigme, men objektorienteret sprog følger bunden op-programmeringsparadigmet. Projektursprog er komplekst i naturen, så det er vanskeligt at ændre, udvide og vedligeholde, men objektorienteret sprog er mindre kompliceret så det er lettere at ændre, udvide og vedligeholde. Processproget giver mindre omfang af kode genbrug, men objektorienteret sprog giver mere omfang af kode genbrug.


Svar 3:

Procedureprogrammering er programmering med procedurer som den primære abstraktionsmekanisme. Huh.

Hvad er en procedure? Det er en navngivet klump med kode, der kan påberåbes ved navn, og som modtager værdier og referencer fra den kontekst, hvor den påberopes, parametrene, og kan returnere værdier og referencer til den kontekst efter at have udført noget arbejde.

Ofte vil en bestemt værdi blive angivet i proceduren som returværdien. På sprog, der understøtter procedurer, er det almindeligt at se dem bruges som om de var funktioner, hvor parametrene behandles som argumenter, og returværdien beregnes inden for proceduren som værdien af ​​funktionen for disse argumenter. Men det er også idiomatisk at få proceduren til at returnere en eller flere værdier til dens opkaldskontekst via parametre, enten “ud” -parametre, hvis sproget understøtter det, eller ved at ændre en værdi, der er bestået ved henvisning, og at bruge selve værdien til en flag, status eller fejlindikator. I programmeringskulturer, der er stærkt påvirket af Unix, vil du ofte se, at 0 returneres for at indikere succes (eller i det mindste fraværet af kendte fejl) og et negativt tal for at indikere en kendt fejltilstand.

Det er ikke strengt nødvendigt for modellen, men jeg kan ikke tænke på et sprog, der bruger procedurer som dets vigtigste abstraktionsmekanisme, som ikke også har flow-of-control ved hjælp af stort set det samme sæt af velkendte semi-magiske ting som:

hvis (betingelse) {doThisThing ()} andet {doThatThing ()}

og

mens (betingelse) {keepOnDoingThisThing ()}

Jeg tror, ​​at "procedurel" programmering i de fleste programmerers sind er temmelig i konflikt med "struktureret programmering". Tilbage i dagen, hvor struktureret programmering var ny, blev det fundet, at der er et praktisk sæt flow-of-control-konstruktioner, hvorfra alle nødvendige mønstre for flow-of-control inden for en procedure kunne konstrueres:

valg af alternativer

  • hvis så andet (to valg, baseret på en boolsk) sag eller switch (mange valg, baseret på ethvert sæt)

gentagelse

med kendte grænser:

  • for løkker (normalt et givet antal iterationer) søger løkker (iterere så mange gange som størrelsen på en samling, måske over medlemmerne selv)

med ad-hoc-grænser:

  • mens do (0 eller flere iterationer) gør mens (1 eller flere iterationer)

og den desværre upopulære:

  • exit-når-loop

som udfører koden før udgangen mindst en gang, og koden efter udgangen nul eller flere gange.

Disse strukturer kan implementeres ud fra hinanden, men det er overraskende svært i nogle tilfælde. Udsagn / sag-udsagn er meget vanskelige at efterligne nøjagtigt med indlejrede ifs. Og den vigtige ting til vores formål er, at disse næsten altid er indbygget i sprogimplementeringen, og de kan gøre ting, som du, den fungerende programmør, vil kæmpe for at skrive kode for at gøre. På ethvert rent eller primært proceduremæssigt sprog, jeg kan tænke på, ville det være meget hårdt og i mange tilfælde fladt ud umuligt at skrive dine egne kontrolstrukturer, der fungerede på samme måde som de indbyggede. Så du bruger dem, der er indbygget. Procedurel, struktureret, programmering er en meget begrænset verden.

Procedureprogrammeringssprog har også en tendens til at have en slags modulkoncept, en navngivet container til en masse procedurer. Nogle af disse procedurer vil være synlige og anvendelige uden for modulet, nogle vil kun være synlige og anvendelige inde i modulet, dvs. ved andre procedurer også inden for det samme modul. På de fleste sprog med moduler kan et modul også have variabler, som er synlige for og deles mellem procedurerne, der er defineret i modulet. Selv C kan gøre dette. Et sådant modulsystem giver mulighed for en grad af indkapsling og skjult information: disse procedurer og variabler inde i modulet, hvilket giver implementeringen af ​​procedurerne, der er synlige uden for modulet, kan hjælpe med at styre koblingen på tværs af et systems struktur. Hvilket er rart.

Hvis du går et skridt videre og tillader flere anvendelser af det samme modul, hvor hver brug har sin egen kopi af variablerne defineret i modulet, begynder modulet at ligne en primitiv slags objekt. Og hvis du så gør forekomsterne af modulerne med variablerne til den primære ting og deler procedurerne mellem dem på en eller anden måde, så du kun har en kopi af disse, så er du temmelig tæt på, hvad C ++ gør. Denne finkornede modulære, proceduremæssige, strukturerede programmering er ikke objektorienteret programmering.

Objektorienteret programmering programmerer med objekter som den primære abstraktionsmekanisme. Huh.

Hvad er et objekt? Det er en beregnet enhed med lang levetid, der kan blive bedt om at gøre noget. En arketype og et eksempel på objektorienteret programmering er Smalltalk. I Smalltalk er hver værdi et objekt (eller i det mindste får de meget få værdier, der ikke er objekter, til at se ud som om de er). Beregningen foregår ved objekter, der sender meddelelser til hinanden. Implementeringer af Smalltalk varierer noget, men dette er den generelle idé:

Objekter placeret rundt i hukommelsen. Når et objekt ønsker, at et andet objekt skal gøre noget, bygger det en besked, der beder om det, og sender det til det tilsigtede objekt. Meddelelser er objekter. Objekter er ansvarlige for at opretholde tilstand, det vil sige at de har variabler. De kører ikke kode. Når et objekt modtager en meddelelse, videresendes det til sin klasse. Klasser er genstande. Klasser er ansvarlige for at oprette og administrere objekter, de kører ikke kode. Klassen videregiver beskeden til dens metaklasse. Metaclasses er genstande. Metaclasses er ansvarlige for styring af metoder. Metaklassen ser på dens metoder og finder den, der svarer til meddelelsen. Metoder er genstande. Undervejs blev beskedobjektet dekoreret med forskellige ekstra oplysninger, inklusive en henvisning til det objekt, der modtog meddelelsen. Metoden er ansvarlig for kørsel af kode, og den bruger alle argumenter, der er sendt i den originale meddelelse til at gøre det. Metoden kører dens kode i sammenhæng med det objekt, der modtog meddelelsen. Metodens kode er kun et script med beskeder, der skal bygges og sendes til andre objekter. Hvis metaklassen ikke kan finde en metode til at matche meddelelsen, begynder en søgning metaklassene for de overordnede klasser i objektets klasse. Dette kaldes ”arv”.

Det kan være, at den ene eller den anden implementering har visse metoder indbygget i implementeringen af ​​effektivitetshensyn, men i princippet kan et helt Smalltalk-system fungere netop på denne måde.

Programmering, i Smalltalk, betyder en kombination af scriptmeddelelse, der sendes til at gå i metoder, og oprette nye klasser (med metaclasses) til metoder at leve i. Og det er ligesom ækvivalenten med flow-of-control som det er for noget andet.

På et proceduresprog kan du muligvis tage nogle handlinger for hvert medlem af en samling med kode lidt som denne pseudokode:

Foreach (theThing in aCollection) doThisActionOn (theThing)

I en typisk Smalltalk kan det ækvivalente script af meddelelsessendelser se sådan ud:

aCollection do: [aThing | aThing takeThisAction].

Her er takeThisAction en meddelelse, der sendes til hvert aThing-objekt i samlingen aCollection. (Forresten er koden inden i firkantede parenteser en blok, hvilket er, hvad Smalltalk kalder en lambda. Det er et objekt.) Hvis vi sammenligner de to, kan vi se nogle kritiske egenskaber ved objektorienteret programmering i modsætning til proceduremæssige:

  • I procedurekoden vælger vi, hvordan vi skal krydse medlemmerne af samlingen, vi vælger foreach-mekanismen. I den objektorienterede kode beder vi samlingen om at foretage en gennemgang, vi ved ikke, hvordan den gør det. I procedurekoden skal opkaldskoden have adgang til den procedure, der hedder doThisActionOn, i den objektorienterede kode takeThisAction er bare et symbol. Vi ved ikke, hvordan objekterne i samlingen vil fortolke det.

Dette er essensen af ​​objektorienteret programmering, og dens er blevet beskrevet som "programmering ved at gå forbi bukken". Ved procedureprogrammering skal vi på den anden side udtrykkeligt angive, hvad enhver beregning gør.