(ALGORITMIZAVIMO IR PROGRAMAVIMO PAGRINDAI)

Programavimo paradigmos ir technologijos

1 skyriaus uždaviniai. Išstudijuoti „programavimo paradigmos“, „programavimo technologijos“ sąvokas. 2. Gauk bendra idėja O šiuolaikinės technologijos programinės įrangos kūrimas. 3. Išstudijuoti struktūrinės programos kūrimo etapus. 4. Susipažinkite su programinės įrangos kūrimo gyvavimo ciklo modeliais...

SE programavimo paradigmos

SWEBOK apima daugybę programavimo paradigmų Žr.: Lavrishcheva E. M. Assembly-type programing paradigms in software engineering // UKRProg-2014. Nr.2-3. 121-133 p. . Savo mokymo kursai programavimas apėmė šiuos dalykus: procedūrinis programavimas(kursas CS1011 „Programavimo pagrindai“),...
(PROGRAMINĖS ĮRANGOS INŽINERIJA IR TECHNOLOGIJOS SUDĖTINĖMS SISTEMoms PROGRAMUOTI)

PROGRAMAVIMO PARADIGMOS

MODULINIS PROGRAMAVIMAS. PAGRINDINĖS SĄVOKOS Vienas iš pagrindiniai klausimai modernus programavimas – pakartotinis modulių ir komponentų panaudojimas (KPI). Tai gali būti programos, paprogramės, algoritmai, specifikacijos ir pan., tinkami naudoti kuriant naują, sudėtingesnę programinę įrangą....
(PROGRAMINĖS ĮRANGOS INŽINERIJA. PARADIGMOS, TECHNOLOGIJOS IR CASE ĮRANKIAI)

Procedūrinė paradigma

Procedūrinė paradigma chronologiškai buvo pirmoji ir ilgą laiką vyravo. Šiuo metu ji pamažu užleidžia vietą objektinei paradigmai, nors vis dar užima apie pusę programinės įrangos kūrimo rinkos. Jis naudojamas visuose programinės įrangos kūrimo lygiuose...
(ALGORITMIZAVIMAS IR PROGRAMAVIMAS)

Deklaratyvioji ir procedūrinė atmintis

Kitas savarankiškas, nuo kitų nepriklausomas, funkcinio atminties organizavimo būdas yra jos padalijimas į deklaratyvus Ir procedūrinis.Šie du atminties organizavimo būdai turi visiškai suprantamą funkcinį pagrindą. Deklaracinės atminties forma yra skirta palaikyti psichinę...
(Psichologija ir pedagogika)

Įvertinimas: / 0
Išsami informacija Peržiūrų skaičius: 3084

Programavimo paradigmos

Kas vis dėlto yra paradigma? Galima sakyti, kad tai tam tikras požiūris į supančio pasaulio reiškinius ir galimų veiksmų su jais idėja. Programavime paradigma paprastai suprantama kaip apibendrinimas apie tai, kaip turėtų būti organizuojamas programos darbas.

Be kita ko, yra tokios programavimo paradigmos kaip direktyvinė (struktūrinė), objektinė ir deklaratyvioji (funkcinė-loginė). Daugelis kalbų palaiko kelias programavimo paradigmas. Kita vertus, yra kalbų, orientuotų tik į vienos paradigmos įgyvendinimą.

Struktūrinis programavimas

Kai kurie atstovai: Fortran, Pascal, C.

Vadovaujantis programa nurodo, kaip pasiekti rezultatą, žingsnis po žingsnio aprašant veiksmus. Todėl tokį programavimą gana lengva suprasti.

Struktūrizuotame programavime komandų vykdymo seka visiškai priklauso nuo įvesties duomenų.

Direktyviniame programavime vienu metu atsirado idėja lokalizuoti dalį kodo į vadinamąsias paprogrames (funkcijas, metodus), o vėliau jas iškvietus iš skirtingų pagrindinės programos vietų. Kai iškviečiama, paprogramė gali būti perduodama bet kokius duomenis argumentų forma; o paprogramė savo ruožtu gali grąžinti rezultatą (tai yra jos vykdymo metu gautus duomenis) į pagrindinę programą.

Funkcinis ir loginis programavimas

Funkcinių kalbų atstovai: List, Haskell.

Loginių kalbų atstovas: Prolog.

Deklaracinė programa nurodo (deklaruoja), ką reikia pasiekti kaip tikslą. Svarbu tiksliai suformuluoti problemą. Programuotojas nenurodo algoritmo, kaip tai išspręsti.

Funkcinis programavimas remiasi matematine funkcijos, kuri nekeičia savo aplinkos, samprata; Tai yra skirtumas tarp funkcinio programavimo ir funkcijų struktūrinėse kalbose. Funkcijų programą sudaro funkcijų apibrėžimų rinkinys, kuris savo ruožtu reiškia iškvietimus į kitas funkcijas ir teiginius, valdančius iškvietimų seką. Kiekviena funkcija grąžina tam tikrą reikšmę ją iškvietusiai funkcijai, kurios vertinimas vėliau tęsiamas; šis procesas kartojamas tol, kol pasiekiamas rezultatas.

Loginiame programavime programos išreiškiamos formulėmis matematinė logika, o problemos sprendimas pasiekiamas išvedant iš jų logines pasekmes.

Objektinis programavimas

Objektinių kalbų atstovai: C++, Java, Python.

Ypatingas dėmesys skiriamas duomenims, kurie programoje vaizduojami kaip objektai. Objektai sąveikauja tarpusavyje naudodami pranešimų perdavimo mechanizmą. Programuotojo užduotis yra įgyvendinti objektus taip, kad su jais sąveikaujant būtų galima gauti norimą rezultatą.

OOP skirta sudėtingesnėms ir sudėtingesnėms problemoms spręsti, palyginti su direktyviniu programavimu.

OOP yra pagrįsta tokiomis sąvokomis kaip paveldėjimas, polimorfizmas ir inkapsuliavimas.

Inkapsuliuojant daroma prielaida, kad nesvarbios objekto detalės yra paslėptos. Objektas, gavęs bet kokią komandą, „žino“, kaip jį apdoroti pagal klasę, kuriai jis priklauso.

Visi objektai yra klasių egzemplioriai, kurie vienas kito atžvilgiu gali veikti kaip tėvas-vaikas. Vaikų klasės paveldi tėvų savybes. Tuo atveju, kai nereikia 100% paveldėjimo, į pagalbą ateina vadinamasis polimorfizmas, kuris apima pirminės klasės metodus vaikų klasėse.

Pačioje kompiuterių programavimo eros pradžioje atsiradusios bendrosios programavimo paradigmos, įskaitant taikomojo, teorinio ir funkcinio programavimo paradigmas, yra stabiliausios.

Taikomajam programavimui būdinga probleminė orientacija, atspindinti informacijos kompiuterizavimą ir skaitinio apdorojimo skaičiavimo procesus, tyrinėtą dar gerokai prieš kompiuterių atsiradimą. Čia greitai pasirodė aiškus praktinis rezultatas. Natūralu, kad tokiose srityse programavimas mažai kuo skiriasi nuo kodavimo, paprastai pakanka operatoriaus veiksmų vaizdavimo stiliaus. Taikomojo programavimo praktikoje įprasta pasitikėti patikrintais šablonais ir procedūrų bibliotekomis ir vengti rizikingų eksperimentų. Vertinamas mokslinių skaičiavimų tikslumas ir stabilumas. Fortran kalba, programų programavimo veteranė, šioje srityje palaipsniui pradėjo šiek tiek pasiduoti Pascal, C, o superkompiuteriuose - lygiagrečioms programavimo kalboms, tokioms kaip Sisal.

Teorinis programavimas vadovaujasi publikavimo orientacija, kuria siekiama palyginti mokslinių eksperimentų programavimo ir informatikos srityse rezultatus. Programavimas bando išreikšti savo formalius modelius, parodyti jų reikšmę ir esminį pobūdį. Šie modeliai paveldėjo pagrindines susijusių matematinių sąvokų ypatybes ir įsitvirtino kaip algoritminis metodas kompiuterių moksle. Konstrukcijų įrodymų troškimas ir jų efektyvumo, patikimumo, teisingumo, teisingumo ir kitų formalizuotų ryšių įvertinimas diagramose ir programų tekstuose buvo pagrindas struktūriniam programavimui ir kitiems metodams, padedantiems pasiekti programos kūrimo proceso patikimumą, pavyzdžiui, kompetentingo programavimo. . Standartiniai Algol ir Pascal pogrupiai, kurie buvo programavimo teorijos darbo medžiaga, buvo pakeisti patogesnėmis taikomosiomis kalbomis eksperimentams, tokioms kaip ML, Miranda, Scheme, Haskell ir kt. Dabar prie jų prisijungia C ir Java naujovės.

Funkcinis programavimas buvo suformuotas kaip duoklė matematinei mokslinių tyrimų ir plėtros orientacijai dirbtinis intelektas ir naujų kompiuterių mokslo horizontų tyrinėjimas. Abstraktus požiūris į informacijos pateikimą, lakoniškas, universalus funkcijų konstravimo stilius, skirtingų funkcijų kategorijų vykdymo aplinkos aiškumas, rekursinių konstrukcijų laisvė, pasitikėjimas matematiko ir tyrėjo intuicija, išvengimas per anksti naštos. Neprincipingų atminties paskirstymo problemų sprendimas, nepagrįstų apibrėžimų apimties apribojimų atmetimas - visa tai John McCarthy sieja su Lisp kalbos idėja. Pirmųjų Lisp diegimų apgalvotas ir metodinis pagrįstumas leido greitai sukaupti naujų problemų sprendimo patirtį ir paruošti jas taikomajam ir teoriniam programavimui. Šiuo metu yra šimtai funkcinių programavimo kalbų, skirtų skirtingoms užduočių klasėms ir techninių priemonių rūšims.

Padidėjus sprendžiamų problemų sudėtingumui, pasikeitė pagrindinės programavimo paradigmos. Atsirado programavimo priemonių ir metodų stratifikacija, priklausanti nuo kompiuterinių informacijos apdorojimo procesų organizavimo techninių detalių kūrimo gilumo ir bendrumo. Išsiskirti skirtingų stilių programavimas, iš kurių brandžiausias yra į mašiną orientuotas, sisteminis, loginis, transformacinis ir didelio našumo lygiagretusis programavimas.

Į mašiną orientuotam programavimui būdingas aparatinis požiūris į kompiuterio veikimo organizavimą, kuriuo siekiama pasiekti bet kokias aparatinės įrangos galimybes. Pagrindinis dėmesys skiriamas aparatinės įrangos konfigūracijai, atminties būsenai, komandoms, valdymo perdavimui, įvykių sekai, išimtims ir netikėtumams, įrenginio atsako laikui ir atsako sėkmei. Surinkėjas pagal pageidavimą vizualinė terpė Kurį laiką jis buvo prarastas Pascal ir C net mikroprogramavimo srityje, tačiau vartotojo sąsajos patobulinimai gali atstatyti savo poziciją.

Sistemų programavimas ilgą laiką buvo kuriamas spaudžiant aptarnavimo ir užsakomiesiems darbams. Tokiam darbui būdingas gamybos metodas remiasi pirmenybe atkuriamiems procesams ir stabilioms programoms, skirtoms pakartotiniam naudojimui. Tokioms programoms pateisinama kompiliavimo apdorojimo schema, statinė savybių analizė, automatizuotas optimizavimas ir valdymas. Šioje srityje vyrauja imperatyvus-procedūrinis programavimo stilius, kuris yra tiesioginis taikomojo programavimo operatoriaus stiliaus apibendrinimas. Tai leidžia atlikti tam tikrą standartizavimą ir modulinį programavimą, tačiau įgauna gana sudėtingas struktūras, specifikacijas, testavimo metodus, programų integravimo įrankius ir kt. Griežti efektyvumo ir patikimumo reikalavimai tenkinami kuriant profesionalius įrankius, kuriuose naudojama sudėtinga asociatyvi semantinė euristika kartu su sintaksiniu būdu pagrįsto projektavimo ir programų generavimo metodais. Neabejotinas tokių priemonių potencialas praktikoje ribojamas kūrimo sudėtingumo – atsiranda kvalifikacinis reikalavimas.

Didelio našumo programavimas yra skirtas pasiekti maksimalų įmanomą našumą sprendžiant specialias problemas. svarbias užduotis. Natūralus kompiuterio veikimo rezervas yra lygiagrečiai procesai. Jų organizavimui reikia išsamiai apsvarstyti laiko santykius ir neprivalomą veiksmų valdymo stilių. Superkompiuteriams, palaikantiems didelio našumo skaičiavimą, reikėjo specialių sistemų programavimo metodų. Grafinio tinklo požiūris į sistemų ir procesų atvaizdavimą lygiagrečioms architektūroms buvo išreikštas specializuotose lygiagrečios programavimo kalbose ir superkompiliatoriuose, pritaikytuose abstrakčiai užduočių lygio procesų hierarchijai susieti su specifine realios įrangos procesorių erdvine struktūra.

Loginis programavimas atsirado kaip matematikų ir kalbininkų funkcinio programavimo supaprastinimas, problemų sprendėjai simbolinis apdorojimas. Ypač patraukli yra galimybė naudoti nedeterminizmą kaip konceptualų pagrindą, kuris išlaisvina mus nuo ankstyvo užsakymo programuojant formulių apdorojimą. Procesų generavimo su grąža gamybos stilius yra pakankamai natūralus lingvistiniam požiūriui į formalizuotas žinias ekspertams patikslinti ir sumažina pradinį barjerą.

Transformacinis programavimas metodologiškai sujungė programos optimizavimo, makrogeneravimo ir dalinio skaičiavimo technikas. Pagrindinė šios srities sąvoka yra informacijos lygiavertiškumas. Ji pasireiškia apibrėžiant programų ir procesų transformacijas, ieškant transformacijų pritaikomumo kriterijų, pasirenkant jų panaudojimo strategiją. Mišrūs skaičiavimai, atidėti veiksmai, tingus programavimas, uždelsti procesai ir kt. yra naudojami kaip informacijos apdorojimo efektyvumo didinimo metodai tam tikromis papildomai nustatytomis sąlygomis.

Platus programavimo metodas yra natūralus atsakas į radikalius techninės įrangos ir kompiuterių tinklų veikimo patobulinimus. Vyksta skaičiavimo priemonių perėjimas iš techninių priemonių klasės į buitinės technikos klasę. Atsirado pagrindas atnaujinti požiūrį į programavimą, taip pat galimybę atkurti senas idėjas, kurios buvo menkai išplėtotos dėl žemų technologijų ir kompiuterių našumo. Įdomu formuoti mokslinius, evoliucinius, pažintinius ir adaptacinius programavimo metodus, kurie sukuria realių informacijos išteklių ir kompiuterių potencialo racionalios plėtros perspektyvą.

Profesionalaus, edukacinio ir mėgėjiško programavimo edukacinio žaidimo stiliaus tyrimo metodas gali duoti impulsą ieškoti išradingumo tobulinant programavimo technologijas, kurios negalėjo susidoroti su krizės reiškiniais ankstesnių elementų pagrindu. Evoliucinis požiūris su mobiliuoju programų tobulinimo stiliumi gana aiškiai matosi objektinio programavimo samprata, kuri pamažu perauga į dalykinį programavimą. Pakartotinis apibrėžimų naudojimas ir objekto savybių paveldėjimas gali pailgėti gyvavimo ciklas derinamas informacines aplinkas, padidina jų veikimo patikimumą ir naudojimo paprastumą.

Kognityvinis požiūris su sąveikiu vaizdinės sąsajos kūrimo stiliumi atviros sistemos o naujų garso ir vaizdo įrankių bei nestandartinių prietaisų naudojimas atveria būdus pagerinti sudėtingos informacijos suvokimą ir supaprastinti tinkamą jos apdorojimą.

Prisitaikantis požiūris su ergonomišku stiliumi, individualiai pritaikytu dizainu informacines sistemas suteikia kompiuterių mokslininkams galimybę kompetentingai programuoti, organizuoti ir teikti technologiniai procesai realiu laiku, jautrus žmogiškasis faktorius. Programavimo paradigmos raidos kryptis atspindi besidominčių informacinių sistemų kūrimu ir taikymu rato kaitą. Daug svarbių programavimo praktikai sąvokų, tokių kaip įvykiai, išimtys ir klaidos, potencialas, konstrukcijų hierarchija ir ortogonalumas, ekstrapoliacijos ir programos augimo taškai, kokybės matavimas ir kt. nepasiekė pakankamo abstrakcijos ir formalizavimo lygio. Tai leidžia numatyti programavimo paradigmų raidą ir pasirinkti mokomoji medžiaga apie komponentų programavimo ateitį. Jei tradicinėms daugkartinio naudojimo komponentų atrankos priemonėms ir būdams buvo taikomas moduliškumo kriterijus, suprantamas kaip optimalus minimalios sukabinimo su maksimaliu funkcionalumu pasirinkimas, tai moderni elementų bazė leidžia valdyti kelių kontaktų įrenginius, kurie atlieka paprastos operacijos. Tačiau su visais šiais tipais ir programavimo paradigmomis galime susipažinti net naudodamiesi Vikipedija. Šiuo metu yra labai platus programavimo kūrimo spektras įvairiomis kryptimis.

Paaiškėjo, kad tos paradigmos, kurios anksčiau su prakaitu ir krauju prasiskverbdavo į šviesą per minias tradicinių metodų šalininkų, pamažu pamirštamos. Šios paradigmos atsirado programavimo pradžioje ir kodėl jos atsirado, kokius privalumus suteikė ir kodėl jos vis dar naudojamos, vis dar naudinga žinoti bet kuriam kūrėjui.

Gerai. Įžanga labai smagi, bet vis tiek jos neskaitysi, tad jei kam įdomu, kviečiame į pjūvį!

Būtinas programavimas

Istoriškai didžioji dauguma kompiuterinės technologijos, kurį mes programuojame, turi būseną ir yra programuojama instrukcijomis, todėl pirmosios programavimo kalbos daugiausia buvo grynai imperatyvios, t.y. nepalaikė jokių kitų paradigmų, išskyrus imperatyviąją.

Tai apėmė mašininius kodus, surinkimo kalbas ir ankstyvąsias aukšto lygio kalbas, tokias kaip Fortran.

Pagrindiniai punktai:

Šioje paradigmoje skaičiavimas apibūdinamas kaip instrukcijos, kurios žingsnis po žingsnio keičia programos būseną.

Žemo lygio kalbomis (pvz., surinkimo kalba) būsena gali būti atmintis, registrai ir vėliavėlės, o instrukcijos gali būti tos instrukcijos, kurias palaiko tikslinis procesorius.

Aukštesnio lygio (pvz., C) būsena yra tik atmintis, todėl instrukcijos gali būti sudėtingesnės ir dėl to gali būti paskirstoma atmintis ir jos atskyrimas.

Labai aukšto lygio programose (pvz., Python, jei ją užprogramuojate būtinai), būsena apsiriboja tik kintamaisiais, o komandos gali būti sudėtingos operacijos, kurioms surinkimo kalba prireiktų šimtų eilučių.

Pagrindinės sąvokos:

- Instrukcijos
– Valstybė

Sukurtos sąvokos:

- Užduotis
- Perėjimas
- Atmintis
- Indeksas

Kaip pagrindinis:

- Asamblėjos kalbos
- Fortranas
- Algolis
-Kobolas
- Paskalis
– C
- C++
-Ada

Kaip pagalbinė priemonė:

- Python
- Rubinas
- Java
- C#
-PHP
- Haskell (per monadas)

Verta pažymėti, kad daugumašiuolaikines kalbas įvairiais laipsniais palaiko privalomas programavimas. Net švariai funkcinė kalba Haskell gali būti parašytas imperatyviai.

Struktūrinis programavimas

Struktūrinis programavimas yra programavimo paradigma (dažnai naudojama ir kaip kūrimo metodika), kuri buvo pirmasis didelis žingsnis programavimo kūrimo procese.

Struktūrinio programavimo pradininkai buvo tokie žinomi žmonės kaip E. Dijkstra ir N. Wirth.

Šios paradigmos pradininkės buvo Fortran, Algol ir B kalbos, vėliau jas pakeitė Pascalis ir C.

Pagrindiniai punktai:

Ši paradigma pristato naujas sąvokas, kurios sujungia dažniausiai naudojamus imperatyvaus kodo rašymo modelius.

Struktūriniame programavime vis dar dirbame su būsena ir instrukcijomis, tačiau įvedama sudėtinės instrukcijos (bloko), šakos ir kilpos nurodymų sąvoka.

Šių dėka paprasti pakeitimai Daugeliu atvejų galima pašalinti goto teiginį, o tai supaprastina kodą.

Kartais goto daro kodą lengviau skaitomą, todėl jis vis dar plačiai naudojamas, nepaisant visų oponentų tvirtinimų.

Pagrindinės sąvokos:

- Blokas
- Dviratis
- Šakojantis

Kalbos, palaikančios šią paradigmą:

Kaip pagrindinis:

– C
- Paskalis
– Pagrindinis

Kaip pagalbinė priemonė:

- C#
- Java
- Python
- Rubinas
- JavaScript

Iš dalies palaikoma:
- Kai kurie makrokomandų surinkėjai (naudojant makrokomandas)

Vėlgi, dauguma šiuolaikinių kalbų palaiko struktūrinę paradigmą.

Procedūrinis programavimas

Vėlgi, didėjantis programinės įrangos sudėtingumas privertė programuotojus ieškoti kitų būdų, kaip aprašyti skaičiavimus.

Tiesą sakant, vėl buvo pristatytos papildomos sąvokos, kurios leido mums naujai pažvelgti į programavimą.

Ši koncepcija šį kartą buvo procedūra.

Dėl to atsirado nauja programų rašymo metodika, kuri sveikintina iki šiol – pirminė problema išskaidoma į smulkesnes (naudojant procedūras) ir taip vyksta tol, kol visų konkrečių procedūrų sprendimas pasirodo esąs menkas.

Pagrindiniai punktai:

Procedūra yra nepriklausoma kodo dalis, kuri gali būti vykdoma kaip viena instrukcija.

Šiuolaikiniame programavime procedūra gali turėti kelis išėjimo taškus (grįžimą į C panašiomis kalbomis), kelis įėjimo taškus (naudojant išeigą Python arba statinius vietinius kintamuosius C++), turėti argumentus, grąžinti reikšmę kaip jos vykdymo rezultatą, būti perkrautas skaičiumi, parametrų tipu ir daug daugiau.

Pagrindinės sąvokos:

- Procedūra

Sukurtos sąvokos:

- Iššūkis
– Argumentai
- Grįžti
- Rekursija
- Perkrova

Kalbos, palaikančios šią paradigmą:

Kaip pagrindinis:

– C
- C++
- Paskalis
- Objektas Paskalis

Kaip pagalbinė priemonė:

- C#
- Java
- Rubinas
- Python
- JavaScript

Iš dalies palaikoma:
- Early Basic

Verta paminėti, kad keli įėjimo taškai iš visų šių kalbų palaikomi tik Python.

Modulinis programavimas

Dar kartą didėjantis programų sudėtingumas privertė kūrėjus dalytis savo kodu. Šį kartą procedūrų nepakako ir šį kartą buvo pristatyta nauja koncepcija – modulis.

Žvelgdamas į ateitį, pasakysiu, kad moduliai taip pat nesugebėjo neįtikėtinu greičiu sutalpinti augančio programinės įrangos sudėtingumo, o vėliau – paketų (tai irgi modulinis programavimas), klasių (tai jau yra OOP) ir šablonų (generalizuotas programavimas). ) pasirodė.

Modulinio programavimo stiliumi aprašyta programa yra modulių rinkinys. Kas yra viduje, klasės, privalomas kodas ar grynos funkcijos, nesvarbu.

Modulių dėka pirmą kartą programuojant atsirado rimta inkapsuliacija – galima naudoti bet kokias esybes modulio viduje, bet nerodyti jų išoriniam pasauliui.

Pagrindiniai punktai:

Modulis yra atskiras pavadintas programos vienetas, jungiantis kitus panašių funkcijų programos vienetus.

Pavyzdžiui, faile List.mod yra Sąrašo klasė
ir darbo su juo funkcijos – modulis.

Aplankas Geometry, kuriame yra Shape, Stačiakampio ir Trikampio moduliai, taip pat yra modulis, nors kai kurios kalbos atskiria modulio ir paketo sąvokas (tokiomis kalbomis paketas yra modulių ir (arba) kitų elementų rinkinys. paketai).

Modulius galima importuoti (sujungti), kad būtų galima naudoti juose deklaruojamus subjektus.

Pagrindinės sąvokos:

- Modulis
- Importuoti

Sukurtos sąvokos:

- Plastikinis maišelis
- Inkapsuliavimas

Kalbos, palaikančios šią paradigmą:

Kaip pagrindinis:

- Haskelas
- Paskalis
- Python

Kaip pagalbinė priemonė:

- Java
- C#
– „ActionScript 3“.

Iš dalies palaikoma:
- C/C++

Kai kurios kalbos įveda atskiras modulių abstrakcijas, o kitose moduliams įgyvendinti gali būti naudojami antraštės failai (C/C++), vardų erdvės, statinės klasės ir (arba) dinaminių nuorodų bibliotekos.

Vietoj išvados

Šiame straipsnyje neaprašiau dabar populiaraus objektinio, bendrojo ir funkcinio programavimo. Tiesiog todėl, kad turiu savo, gana radikalią nuomonę šiuo klausimu ir nenorėjau pradėti holivaro. Bent jau kol kas. Jei tema pasirodys naudinga bendruomenei, planuoju parašyti keletą straipsnių, kuriuose išsamiai apibūdinsiu kiekvienos iš šių paradigmų pagrindus.

Be to, aš nieko nerašiau apie egzotiškas paradigmas, tokias kaip automatai, aplikacinis, aspektas / agentas / komponentas orientuotas programavimas. Nenorėjau, kad straipsnis būtų labai didelis, ir vėlgi, jei tema bus paklausi, parašysiu apie šias paradigmas, galbūt išsamiau ir su kodų pavyzdžiais.

Ir atrodė, kad niekas neginčijo dizaino ir programavimo OOP stiliaus poreikio. Bet vis tiek laikui bėgant susidūriau su nesusipratimais. Tai bus grynai istorinis teorinis straipsnis. Žinoma, net nesistengiant aprėpti visos temos platybės. Bet tai, galima sakyti, žinutė jaunam kūrėjui, kuris skaito iš viršaus ir negali pasirinkti, kurių principų ir taisyklių laikytis, kas yra pirmutinė, o kas antraeilė.

Šios temos pavadinimas dabar daugeliui gali pasirodyti labai prieštaringas (ir gana tyčia provokuojantis, bet dėl ​​reikalo :)). Bet vis tiek čia pabandysime tai pagrįsti ir suprasti, kokias savybes turi turėti programavimo paradigma, kad ji turėtų teisę vadintis paradigma.

Vienintelis dalykas, kurio prašau, jei skaitote įstrižai, komentuokite santūriai.

Ką Floydas mums sako apie paradigmas?

Terminą „programavimo paradigma“ įvedė Robertas Floydas („R. W. Floyd.“ „Communications of the ACM“, 22(8):455-460, 1979. Vertimą į rusų kalbą rasite knygoje: Lectures of Turing Award laureatų už pirmieji dvidešimt metų (1966-1985), M.: MIR, 1993.). Savo paskaitoje 1979 m. jis sako:

Žinomas programavimo paradigmos pavyzdys yra struktūrizuotas programavimas, kuris, atrodo, yra dominuojanti paradigma programavimo metodikoje. Jis yra padalintas į dvi fazes. Pirmajame etape, projektuojant iš viršaus į apačią, problema yra padalinta į keletą paprastesnių subproblemų. Šis laipsniškas hierarchinis skaidymas tęsiasi tol, kol nustatomos antrinės problemos, kurios yra pakankamai paprastos, kad jas būtų galima spręsti tiesiogiai. Antrasis struktūrinio programavimo paradigmos etapas apima darbą nuo konkrečių objektų ir funkcijų prie abstraktesnių objektų ir funkcijų, naudojamų visuose moduliuose, kuriuos sukūrė dizainas iš viršaus į apačią. Tačiau struktūrinio programavimo paradigma nėra universali. Net aršiausi jos gynėjai pripažintų, kad vien to neužtenka visko padaryti sudėtingos problemos plaučiai. Kitos paradigmos aukšto lygio labiau specializuoti tipai tebėra svarbūs. (Tai nėra tikslus vertimas, o autorinis rinkinys, paremtas R. Floydo paskaita, tačiau kiek įmanoma laikantis jo žodžių. Formuluotė pakeista ir sutvarkyta tik siekiant išryškinti pagrindinę R. Floydo ir jo mintį. aiškus pristatymas.)

Toliau jis mini dinaminį programavimą ir loginį programavimą, taip pat vadindamas juos paradigmomis. Tačiau jų ypatumas yra tas, kad jie buvo sukurti iš specializuotos dalykinės srities, buvo rasti keli sėkmingi algoritmai ir sukurtos atitinkamos programinės įrangos sistemos. Jis tęsia, kad programavimo kalbos turi palaikyti programavimo paradigmas. Ir tuo pat metu jis nurodo, kad struktūrinio programavimo paradigma yra aukštesnio lygio paradigma:

Aukštesnio lygmens abstrakcijos paradigma nei „struktūrinio programavimo paradigma""" yra kalbų hierarchijos konstravimas, kai aukščiausio lygio kalbos programos sąveikauja su abstrakčiais objektais ir išversti juos į programas kito aukštesnio lygio kalba žemas lygis.

Aukštesnio lygio paradigmų bruožai

Kaip matome, R. Floydas taip pat skyrė paradigmas į aukštesnio lygio ir labiau specializuotas. Kokie paradigmų bruožai leidžia teigti, kad jos yra aukštesnio lygio? Žinoma, tai yra galimybė juos pritaikyti įvairioms dalykinėms problemoms spręsti. Bet kas daro paradigmas pritaikytas skirtingoms domenų problemoms? Žinoma, čia nekalbama apie dalykinės problemos specifiką, kurią galima išspręsti vienu ar kitu požiūriu. Visos paradigmos, kurios siūlo kurti algoritmus vienaip ar kitaip specializuotu būdu, nėra paradigmos, tai tik specialus požiūris aukštesnio lygio paradigmos rėmuose.

Ir yra tik dvi aukšto lygio paradigmos: struktūrinis programavimas ir dar aukštesnio lygio objektinis programavimas. Be to, šios dvi paradigmos aukštu lygiu prieštarauja viena kitai, tačiau žemame lygyje, algoritmų konstravimo lygyje, jos sutampa. Ir jau požiūriai (žemo lygio paradigmos), tokie kaip loginiai, dinaminiai, funkciniai, gali būti naudojami struktūrinio programavimo paradigmos rėmuose ir kai kurios atsiradusios specializacijos - aspektais pagrįstos, orientuotos į agentą, orientuotos į įvykį, yra naudojami objektinio programavimo paradigmos rėmuose. Taigi tai nereiškia, kad programuotojams tereikia žinoti vieną ar dvi aukšto lygio paradigmas, tačiau kitų požiūrių žinios pravers sprendžiant labiau specializuotą, žemo lygio problemą. Bet tuo pačiu metu, kai reikia kurti programinė įranga, reikia pradėti nuo aukštesnio lygio paradigmų ir, jei reikia, pereiti prie žemesnio lygio paradigmų. Bet jei iškyla problema pasirinkti, kuriems principams teikti pirmenybę, žemesnio lygio paradigmų principai niekada neturėtų dominuoti aukštesnio lygio paradigmų principuose. Pavyzdžiui, struktūrinio programavimo principų neturėtų būti laikomasi objektinio programavimo principų nenaudai, o funkcinio ar loginio programavimo principai neturėtų pažeisti struktūrinio programavimo principų. Vienintelė išimtis yra algoritmų veikimas, o tai yra kompiliatorių kodo optimizavimo problema. Tačiau kadangi ne visada įmanoma sukurti tobulus kompiliatorius, o aukštesnio lygio paradigmų interpretacija, žinoma, yra sudėtingesnė nei žemo lygio, kartais tenka prieštarauti aukšto lygio paradigmų principams.

Bet grįžkime prie mūsų klausimo: dėl ko paradigmos taikomos įvairioms dalykinėms problemoms? Tačiau norėdami į tai atsakyti, turime padaryti istorinė ekskursija.

Struktūrinio programavimo paradigmos pagrindai

Žinome, kad idėjos apie struktūrinį programavimą kilo po E. Dijkstros pranešimo dar 1965 metais, kur jis pagrindė GOTO operatoriaus atsisakymą. Būtent šis operatorius programas pavertė nestruktūruotomis (Spaghetti kodas), o Dijkstra įrodė, kad galima parašyti programas ir nenaudojant šio operatoriaus, ko pasekoje programos taps struktūrizuotos.

Tačiau teorija yra viena, praktika – kita. Šia prasme įdomu pasvarstyti, kokia padėtis buvo 1975 m. Tai aiškiai matyti iš E. Yodano knygos (). Svarbu tai apsvarstyti, nes dabar, praėjus daugiau nei 30 metų, principai, kurie tada buvo gerai žinomi, dabar atrandami ir keliami į naują rangą. Tačiau kartu prarandamas istorinis kontekstas ir šių principų svarbos hierarchija, kas pirmutinė, o kas antraeilė. Ši amorfiškumo situacija labai gerai apibūdina dabartinę programavimo būklę.

Bet kas tada atsitiko? Kaip aprašo Yodanas, viskas prasideda nuo atsakymo į klausimą: „Ką reiškia rašyti gera programa?. Tai pirmasis kriterijus, į kokius klausimus turėtų atsakyti aukšto lygio programavimo paradigma. Jei jis tiesiogiai neatsako į šį klausimą, o nurodo, kaip galite gauti įdomių savo programos funkcijų, tai reiškia, kad susiduriate su žemo lygio programavimo paradigma.

Programavimo aušroje buvo toks požiūris į programuotojų vertinimą pagal programų rašymo greitį. Ar tai reiškia, kad jis rašo geras programas? Ar jam patinka ypatinga vadovybės malonė ir pagarba? Jei atsakymas į paskutinį klausimą yra teigiamas, tai visi programavimo tobulinimo klausimai yra gana akademiniai. Tačiau vadovybė taip pat gali pastebėti, kad kai kurie superprogramuotojai gali labai greitai sukurti programas arba labai rašyti veiksmingos programos, tačiau šios programos kartais lieka nesuformuotos ir jų neįmanoma suprasti, prižiūrėti ar modifikuoti. O pastarasis taip pat užima daug laiko.

Pažymėtinas gana būdingas programuotojų ginčas:
* Programuotojas A: „Mano programa yra dešimt kartų greitesnė nei jūsų ir užima tris kartus mažiau atminties!
* Programuotojas B: „Taip, bet tavo programa neveikia, o mano veikia!

Tačiau programos nuolat tampa sudėtingesnės, todėl mums neužtenka to, kad programa tik veikia. Norint patikrinti, ar programa ir pats programuotojas veikia teisingai, reikalingi tam tikri metodai. Be to, tai nėra programos testavimas, o tam tikros sisteminės procedūros, skirtos tiksliai patikrinti programos teisingumą jos vidinės organizavimo prasme, atlikimas. Tai jau tada kalba šiuolaikinė kalba, kalbėjo apie kodo peržiūrą.

Be to, jau tada buvo kalbama apie programos lankstumą – lengvumą ją keisti, plėsti ir modifikuoti. Norėdami tai padaryti, turite nuolat atsakyti į tam tikro tipo klausimus. „Kas atsitiks, jei norime išplėsti šią lentelę?“, „Kas nutiks, jei vieną dieną norime apibrėžti nauja programa pakeitimus?“, „O jeigu turėsime pakeisti tokių ir tokių išvesties duomenų formatą?“, „Kas nutiks, jei kas nors nuspręs kitaip įvesti duomenis į programą?“.

Taip pat buvo kalbama apie sąsajos specifikacijų svarbą, t.y. formalizuotas požiūris į įėjimų, funkcijų ir išėjimų, kuriuos turi įgyvendinti kiekvienas modulis, specifikaciją.

Be to, pagrindinis dėmesys buvo skiriamas modulio dydžiui ir nekintamumui. Be to, kalbant apie modulio nekintamumą, jis buvo vertinamas ne kaip visuma, o identifikuojant atskirus veiksnius:
1. Programos loginė struktūra, t.y. algoritmas. Jei visa programa priklauso nuo kažkokio specialaus požiūrio, kiek modulių reikės modifikuoti pasikeitus algoritmui?
2. Modulio argumentai arba parametrai. Tie. sąsajos specifikacijos pakeitimas.
3. Vidiniai lentelės kintamieji ir konstantos. Daugelis modulių priklauso nuo bendrosios lentelės, pasikeitus tokių lentelių struktūrai, galime tikėtis, kad keisis ir moduliai.
4. Duomenų bazės struktūra ir formatas. Didesniu mastu ši priklausomybė yra panaši į pirmiau minėtą priklausomybę nuo bendrų kintamųjų ir lentelių, su tuo skirtumu, kad praktiniu požiūriu patogiau laikyti duomenų bazę nepriklausoma nuo programos.
5. Modulinė programos valdymo struktūra. Kai kurie žmonės rašo modulį tikrai negalvodami, kaip jis bus naudojamas. Bet jei pasikeitė reikalavimai. Kiek modulio loginės struktūros turėsime pakeisti?

Šie ir daugelis kitų aspektų (kurių čia nenagrinėjome) paprastai suformuluoja struktūrinio programavimo idėją. Rūpinimasis šiais aspektais daro struktūrinį programavimą aukšto lygio paradigma.

Objektinio programavimo paradigmos pagrindai

Kaip matome, struktūrizuotame programavime atsižvelgiama į visus gerų programų organizavimo principus. Ar dar vieno ar grupės anksčiau nežinomų gerų programų rašymo principų atsiradimas galėtų pakeisti paradigmą? Nr. Tai tik praplėstų struktūrinių programų rašymo būdus ir ideologiją, t.y. struktūrinio programavimo paradigma.

Bet jei aukšto lygio paradigmos yra skirtos atsakyti į klausimą, kaip parašyti gerą programą, o naujos techninės technikos atsiradimas arba naujų veiksnių įvertinimas neleidžia peržengti struktūrinio programavimo ribų (kadangi išliks struktūrinis, nepaisant technikų ir veiksnių skaičiaus), tada Kas tada leis peržengti šios paradigmos ribas. Iš tiesų, kaip žinome iš mokslo, paradigmos paprastai nesikeičia taip greitai. Mokslo revoliucijos retai įvyksta, kai ankstesnė paradigma, praktiškai, remiantis esamomis teorinėmis pažiūromis, tiesiog negali paaiškinti vykstančių reiškinių. Panaši situacija yra keičiant paradigmą iš struktūrinės į objektinę.

Jau dabar pripažįstama, kad objektinės paradigmos atsiradimo priežastis buvo poreikis rašyti vis sudėtingesnes programas, o struktūrinio programavimo paradigma turi tam tikrą ribą, po kurios kurti programą tampa nepakeliamai sunku. Štai, pavyzdžiui, G. Schildtas rašo:

Kiekviename programavimo kūrimo etape metodai ir įrankiai atrodė „panaudoti“ didėjantį programų sudėtingumą. Ir kiekviename tokiame etape naujas požiūrisįsisavino viską, kas geriausia iš ankstesnių, žyminčių programavimo pažangą. Tą patį galima pasakyti apie OOP. Prieš OOP daugelis projektų pasiekė (o kartais ir viršijo) ribą, kurią peržengus struktūrizuotas požiūris į programavimą nebeveiks. Todėl, norint įveikti sunkumus, susijusius su didėjančiu programų sudėtingumu, iškilo OOP poreikis. ()

Norėdami suprasti priežastį, kodėl objektinis programavimas leido rašyti sudėtingesnes programas ir praktiškai pašalinti sudėtingumo ribos atsiradimo problemą, kreipkimės į vieną iš OOP įkūrėjų - Gradi Buci (). OOP paaiškinimą jis pradeda nuo to, ką reiškia sudėtingumas ir kokios sistemos gali būti laikomos sudėtingomis. Tai yra, jis tikslingai sprendžia sudėtingų programų rašymo klausimą. Toliau jis pereina prie sudėtingumo ir žmogaus galimybių suprasti šį sudėtingumą ryšio klausimo:

Yra ir kitas pagrindinė problema: fiziniai asmens galimybių apribojimai dirbant su sudėtingomis sistemomis. Kai pradedame analizuoti sudėtingą programinės įrangos sistemą, ji atskleidžia daugybę komponentai, kurios tarpusavyje sąveikauja įvairiai, ir nei pačios sistemos dalys, nei jų sąveikos metodai nerodo jokio panašumo. Tai netvarkingo sudėtingumo pavyzdys. Kai pradedame organizuoti sistemą jos kūrimo proceso metu, reikia galvoti apie daugybę dalykų vienu metu. Deja, vienas žmogus negali viso to stebėti vienu metu. Psichologų, tokių kaip Milleris, eksperimentai tai rodo maksimalus kiekis Struktūrinių informacijos vienetų, kuriuos žmogaus smegenys gali stebėti vienu metu, skaičius yra maždaug septyni, plius arba minus du. Taigi mes susiduriame su rimta dilema. """Programinės įrangos sistemų sudėtingumas didėja, bet mūsų smegenų gebėjimas susidoroti su šiuo sudėtingumu yra ribotas. Kaip mes galime išeiti iš šios keblios padėties?"""

Tada jis kalba apie skaidymą:

Išskaidymas: algoritminis ar objektinis? Kuris sudėtingos sistemos skaidymas teisingesnis – pagal algoritmus ar pagal objektus? Šis klausimas slypi, ir teisingas atsakymas į jį yra tas, kad svarbūs abu aspektai. Atskyrimas pagal algoritmus sutelkia dėmesį į įvykių eiliškumą, o atskyrimas pagal objektus suteikia ypatinga prasmė agentai, kurie yra veiksmo objektai arba subjektai. Tačiau mes negalime projektuoti sudėtinga sistema dviem būdais vienu metu. Turime pradėti skaidyti sistemą pagal algoritmą arba pagal objektą, o tada, naudodamiesi gauta struktūra, pabandyti pažvelgti į problemą kitu požiūriu. Patirtis rodo, kad naudingiau pradėti nuo objektų skaidymo. Ši pradžia padės mums geriau atlikti darbą, kad organizacija būtų pritaikyta sudėtingoms programinės įrangos sistemoms.

Taigi jis taip pat teikia pirmenybę objektiniams principams, o ne struktūriniams principams, tačiau pabrėžia abiejų svarbą. Kitaip tariant, struktūriniai principai turi paklusti objektiniams principams, kad žmogaus smegenys galėtų susidoroti su sudėtingomis problemomis, su kuriomis susiduriama. Jis taip pat pabrėžia modelio svarbą:

Modelio kūrimo svarba. Modeliavimas yra plačiai paplitęs inžinerinės disciplinos, daugiausia dėl to, kad jame įgyvendinami skaidymo, abstrakcijos ir hierarchijos principai. Kiekvienas modelis apibūdina tam tikrą nagrinėjamos sistemos dalį, o mes savo ruožtu kuriame naujus modelius pagal senus, kuriais daugiau ar mažiau pasitikime. Modeliai leidžia mums kontroliuoti savo nesėkmes. Įvertiname kiekvieno modelio elgesį įprastose ir neįprastose situacijose, o tada atliekame atitinkamus koregavimus, jei esame kažkuo nepatenkinti. Naudingiausia kurti modelius, orientuotus į objektus, esančius pačiame domene, suformuojant tai, ką vadiname objektiniu išskaidymu.

Dabar, atidžiau pažvelgus, paaiškėja, kad objektinė paradigma yra ne kas kita, kaip modeliavimas apskritai, kurio svarbiausią aspektą aiškiausiai išreiškė S. Lemas:

Modeliavimas yra gamtos imitacija, atsižvelgiant į keletą jos savybių. Kodėl tik keli? Dėl mūsų nesugebėjimo? Nr. Pirmiausia todėl, kad turime apsisaugoti nuo informacijos pertekliaus. Tačiau toks perteklius gali reikšti ir jo neprieinamumą. Menininkas piešia paveikslus, bet nors galėtume su juo pasikalbėti, kaip jis kuria savo darbus, nežinosime. Jis pats nežino, kas darosi jo smegenyse, kai piešia paveikslą. Informacija apie tai yra jo galvoje, bet ji mums neprieinama. Modeliuodami turėtume supaprastinti: mašina, galinti nutapyti labai kuklų paveikslą, daugiau pasakytų apie tapybos medžiagą, tai yra, smegenų, pagrindus, nei toks tobulas menininko „modelis“ kaip jo brolis dvynys. Modeliavimo praktika apima kai kuriuos kintamuosius, o kitų atsisakymą. Modelis ir originalas būtų identiški, jei juose vykstantys procesai sutaptų. Tai neįvyksta. Modelio kūrimo rezultatai skiriasi nuo faktinio kūrimo. Šį skirtumą gali įtakoti trys veiksniai: modelio supaprastinimas, palyginti su originalu, modelio savybės, kurios yra svetimos originalui, ir, galiausiai, paties originalo neapibrėžtumas. (darbo „Technologijų suma“ fragmentas, Stanislav Lem, 1967)

Taigi S. Lem kalba apie abstrakciją kaip modeliavimo pagrindą. Tuo pačiu metu abstrakcija yra pagrindinė savybėį objektą orientuota paradigma. G. Butchas apie tai rašo:

Pagrįstas klasifikavimas neabejotinai yra bet kurio mokslo dalis. Michalskis ir Steppas teigia: „Neatsiejama mokslo užduotis yra sukurti reikšmingą stebimų objektų ar situacijų klasifikaciją. Ši klasifikacija labai palengvina pagrindinės problemos supratimą ir tolesnė plėtra mokslinė teorija“ Kodėl klasifikuoti taip sunku? Tai siejame su „tobulos“ klasifikacijos trūkumu, nors, žinoma, kai kurios klasifikacijos yra geresnės už kitas. Coombs, Raffia ir Thrale teigia, kad „yra tiek daug būdų, kaip padalinti pasaulį į objektų sistemas, kiek yra mokslininkų, kurie imasi užduoties“. Bet kokia klasifikacija priklauso nuo tiriamojo požiūrio. Flood ir Carson pateikia pavyzdį: „Jungtinę Karalystę... ekonomistai gali vertinti kaip ekonominę instituciją, sociologai – kaip visuomenę, advokatai. aplinką- kaip mirštantis gamtos kampelis, Amerikos turistai - kaip turistų traukos objektas, sovietų lyderiai - kaip karinė grėsmė„Pagaliau, romantiškiausi iš mūsų, britų, yra tarsi žalios mūsų tėvynės pievos.

"""Ieškokite ir pasirinkite raktų abstrakcijas."""Rakto abstrakcija yra klasė arba objektas, įtrauktas į problemos srities žodyną. """Svarbiausia pagrindinių abstrakcijų vertė yra ta, kad jos apibrėžia mūsų problemos ribas""": jos išryškina tai, kas įtraukta į mūsų sistemą ir todėl mums svarbu, ir pašalina tai, kas nereikalinga. Užduotis nustatyti tokias abstrakcijas būdinga probleminei sričiai. Kaip teigia Goldbergas, teisingas pasirinkimas objektai priklauso nuo paraiškos tikslo ir apdorojamos informacijos išsamumo.

Kaip jau minėjome, pagrindinių abstrakcijų nustatymas apima du procesus: atradimą ir išradimą. Abstrakcijas atrandame klausydami srities ekspertų: jei ekspertas apie tai kalba, tada ta abstrakcija dažniausiai yra tikrai svarbi. Išradę sukuriame naujas klases ir objektus, kurie nebūtinai yra domeno dalis, bet yra naudingi kuriant ar diegiant sistemą. Pavyzdžiui, bankomato vartotojas sako „sąskaita, išimti, deponuoti“; šie terminai yra domeno žodyno dalis. Sistemos kūrėjas jas naudoja, bet prideda savo, pavyzdžiui, duomenų bazę, ekrano tvarkyklę, sąrašą, eilę ir pan. Šios pagrindinės abstrakcijos kuriamos ne pagal domeną, o pagal dizainą.

Dauguma galingu būdu pagrindinių abstrakcijų išryškinimas – užduoties sumažinimas iki jau žinomų klasių ir objektų.

Taigi objektinė paradigma tampa aukšto lygio paradigma ir dominuoja struktūrinio programavimo paradigmos principuose, nes užsiima tikrovės modeliavimu, dalykinių sričių modelių kūrimu šių sričių specialistų kalba. Jei to nepaisysite ir sukursite gerą programą, kurią būtų lengva modifikuoti, išplėsti ir kuri turės aiškias sąsajas bei nepriklausomus modulius, grįšite į struktūrinio programavimo paradigmos lygį. Jūsų programa bus naudinga visiems, bet nebus suprantama, nes neatitiks tikrovės, ji bus paaiškinta tik jums žinomais terminais, o specialistas, išmanantis dalykinę sritį, programos nesupras. be tavo pagalbos. Galų gale sunkumas sumažės labai siaurame diapazone, net jei suorganizavote gerą programą. Bet tai programa, o ne modelis. Modelio nebuvimas ar tik paviršutiniškas jo atvaizdavimas „susprogdins“ jūsų gerą programą iš vidaus, neleis jos toliau tobulinti ir išlaikyti. Kai įvedate klases, kurioms abstrakcijų nėra, kai šios klasės yra grynai sisteminės ir neturi nieko bendra su dalykine sritimi, kai jos įvedamos tik siekiant supaprastinti kitų klasių sąveikos srautą - jūsų programinė įranga tampa „barzdota“, ir jei refaktoringas nebus laikomasi už tokių sričių, vienu metu jūsų programinės įrangos kūrimas sustos ir taps neįmanomas – pasieksite struktūrinio programavimo ribą (o ar manėte, kad klasių ir objektų naudojimas jums negresia?).

upd. Pagalvojau, tai jautri tema, aš jos nekomentuosiu. Straipsnyje pateikiau faktus, bet nenoriu slysti į holivaro lygį. Jei tai nepadėjo pagalvoti, šį kartą nesiseka. Iš tiesų, bus konstruktyvu, jei parašysite kontrargumentus atskirame straipsnyje. Aš nesiimu griauti masinių stereotipų.

Taip, ir, kad būtų aišku, nusprendžiau paskelbti po diskusijų čia. Užprogramuokime Rosenblatto perceptroną? , kur akivaizdžiai paaiškėjo, kad funkcinis programavimas kuriant blogą modelį OOP veikia daug prasčiau. Ir tai, kad jie gali pasigirti dideliu greičiu, yra fikcija, teisingas modelis yra svarbus. Kai kuriems (palyginti nedaug tokių užduočių) funkcinis programavimas gali būti sėkmingas, tačiau jis neturėtų būti naudojamas visur, kur jis nieko gero neduoda. Na, ar taip - ar galima ten aptartą kūrinį parašyti TIK funkcionaliu stiliumi, ir taip, kad jis veiktų greičiau nei su OOP renginiais?

Žymos: pridėti žymų