Pumunta sa nilalaman

Object-oriented programming

Mula sa Wikipedia, ang malayang ensiklopedya
Notasyon ng UML para sa isang class. Ang Button class na ito ay may mga baryabol para sa datos at mga function. Sa pamamagitan ng inheritance, maaaring lumikha ng isang subclass bilang isang subset ng Button class. Ang mga object ay mga instance ng isang class.

Ang object-oriented programming (OOP, literal: pagpoprogramang nakatuon sa bagay) ay isang paradigma (paradigm) sa pagpoprograma na nakabatay sa mga object (o bagay)[1] – mga entidad ng software na naglalaman (encapsulate) ng datos at mga punsyon o function. Ang isang programang pang-kompyuter na OOP ay binubuo ng mga object na nakikipag-ugnayan sa isa't isa.[2][3] Ang isang wikang OOP ay yaong nagbibigay ng mga katangian ng object-oriented programming, subalit dahil pinagtatalunan kung alin-alin ang mga katangiang bumubuo sa OOP, napagdedebatehan kung maituturing bang OOP ang isang wika – at kung hanggang saan nito sinusuportahan ang OOP. Dahil ang mga paradigma ay hindi magkakahiwalay o eksklusibo sa isa’t isa, maaaring maging maramihang-paradigma ang isang wika (ibig sabihin, maaari itong ikategorya sa higit pa sa OOP lamang).

Kabilang sa mga kilalang wikang pamprograma may suporta sa OOP ang Ada, ActionScript, C++, Common Lisp, C#, Dart, Eiffel, Fortran 2003, Haxe, Java,[4] JavaScript, Kotlin, Logo, MATLAB, Objective-C, Object Pascal, Perl, PHP, Python, R, Raku, Ruby, Scala, SIMSCRIPT, Simula, Smalltalk, Swift, Vala, at Visual Basic (.NET).

Kasaysayan

[baguhin | baguhin ang wikitext]

Ang ideya ng mga "object" sa programming ay nagsimula sa pangkat ng artipisyal na intelihensiya sa Massachusetts Institute of Technology (MIT) noong huling bahagi ng dekada 1950 at unang bahagi ng dekada 1960. Dito, ang "object" ay tumutukoy sa mga atom ng LISP na may natukoy na mga katangian (attributes).[5][6] Isa pang maagang halimbawa ang Sketchpad na nilikha ni Ivan Sutherland sa MIT noong 1960 hanggang 1961. Sa talahuluganan ng kaniyang teknikal na ulat, tinukoy ni Sutherland ang mga terminong gaya ng "object" at "instance" (na ang konsepto ng class ay saklaw ng "master" o "definition"), bagaman nakatuon ito sa interaksiyong grapikal.[7] Pagkaraan, noong 1968, ang AED-0, bersiyon ng MIT ng wikang ALGOL, ay nag-ugnay ng mga estruktura ng datos ("plexes") at mga procedure, na nagpauna sa mga konseptong kalauna’y tinawag na "messages", "methods", at "member functions".[8][9] Sa panahong ito, karaniwang paksa ng talakayan ang data abstraction (abstraksyon ng datos) at modular programming (pagpoprogramang modular).

Samantala, sa Norway, binuo ang Simula mula 1961 hanggang 1967.[8] Ipinakilala ng Simula ang mahahalagang ideya ng object-oriented programming, gaya ng mga class, inheritance, at dynamic binding.[10] Pangunahing ginamit ang Simula ng mga mananaliksik na sangkot sa pisikal na pagmomodelo, tulad ng galaw ng mga barko at ng kanilang kargamento sa mga pantalan.[10] Karaniwang kinikilala ang Simula bilang unang wika na nagtataglay ng pangunahing mga katangian at balangkas ng isang object-oriented na wika.[11]

Naimpluwensiyahan ng MIT at ng Simula, sinimulan ni Alan Kay ang paglinang ng kaniyang sariling mga ideya noong Nobyembre 1966. Kalaunan, nilikha niya ang Smalltalk, isang makapangyarihang wikang OOP. Pagsapit ng 1967, ginagamit na ni Kay ang katawagang "object-oriented programming" sa mga pag-uusap.[1] Bagaman madalas siyang tawaging "ama" ng OOP,[12] sinabi ni Kay na naiiba ang kaniyang mga ideya sa karaniwang pagkaunawa sa OOP, at ipinahiwatig niyang hindi tinanggap ng establisimyento ng agham pangkompyuter ang kaniyang pananaw.[1] Sa isang memo ng MIT noong 1976 na inakdaan nina Barbara Liskov at iba pa, nakalista ang Simula 67, CLU, at Alphard bilang mga wikang object-oriented, subalit hindi nabanggit ang Smalltalk.[13]

Noong dekada 1970, binuo sa Xerox PARC ang unang bersiyon ng wikang Smalltalk nina Alan Kay, Dan Ingalls, at Adele Goldberg. Namukod-tangi ang Smalltalk-72 dahil sa paggamit ng mga object sa antas ng wika at sa grapikal na environment sa pag-develop.[14] Ganap na dinamiko ang Smalltalk, na nagpapahintulot sa mga gumagamit na lumikha at magbago ng mga class habang sila’y gumagawa. Malaking bahagi ng teorya ng OOP ang na-develop sa konteksto ng Smalltalk, tulad ng multiple inheritance.[15]

Noong huling bahagi ng dekada 1970 at dekada 1980, lalo pang sumikat ang OOP. Nilikha ang Flavors, isang object-oriented na Lisp, simula 1979, na nagpakilala ng multiple inheritance at mixins.[16] Noong Agosto 1981, itinampok ng Byte Magazine ang Smalltalk at OOP, na nagpakilala ng mga ideyang ito sa mas malawak na madla.[17] Ang LOOPS, ang object system para sa Interlisp-D, ay naimpluwensiyahan ng Smalltalk at Flavors, at nailathala ang isang papel tungkol dito noong 1982.[18] Noong 1986, dinaluhan ng 1,000 katao ang unang Kumperensiya sa Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA). Minarkahan ng kumperensiyang ito ang simula ng mga pagsisikap na pagsamahin ang mga object system ng Lisp, na kalauna'y humantong sa Common Lisp Object System. Noong dekada 1980, may ilang tangkang magdisenyo ng mga processor architecture na may suporta sa hardware para sa mga object sa memorya, subalit hindi nagtagumpay ang mga ito. Kabilang sa mga halimbawa ang Intel iAPX 432 at ang Linn Smart Rekursiv.

Noong kalagitnaan ng dekada 1980, lumitaw ang mga bagong wikang object-oriented tulad ng Objective-C, C++, at Eiffel. Binuo ang Objective-C ni Brad Cox, na gumamit ng Smalltalk sa ITT Inc. Nilikha ni Bjarne Stroustrup ang C++ batay sa kaniyang karanasan sa paggamit ng Simula para sa kaniyang tesis sa doktorado.[14] Inilabas ni Bertrand Meyer ang unang disenyo ng wikang Eiffel noong 1985, na nakatuon sa kalidad ng software sa pamamagitan ng design by contract (disenyo ayon sa kontrata) na pamamaraan.[19]

Noong dekada 1990, naging pangunahing paraan ng programming ang OOP, lalo na nang mas maraming wika ang sumuporta rito. Kabilang dito ang Visual FoxPro 3.0[20][21] at C++.[22] Lalong sumikat ang OOP kasabay ng pag-usbong ng mga graphical user interface, na gumagamit ng mga object para sa mga pindutan, menu, at iba pang elemento. Isang kilalang halimbawa ang framework na Cocoa ng Apple, na ginagamit sa macOS at nakasulat sa Objective-C.

Sa ETH Zürich, lumikha si Niklaus Wirth at ang kaniyang mga kasamahan ng mga bagong lapit sa OOP. Ang Modula-2 (1978) at Oberon (1987) ay nagtatampok ng natatanging pagtingin sa object orientation, mga class, at type checking sa kabila ng mga hangganan ng mga module. Hindi lantad ang inheritance sa disenyo ni Wirth dahil kabaligtaran ang direksiyon ng kaniyang terminolohiya: tinatawag itong type extension, at ang pananaw ay mula sa magulang (o parent) pababa sa nagmamana.

Maraming wikang pamprograma na unang na-develop bago pa sumikat ang OOP ang kalauna'y dinagdagan ng mga katangiang object-oriented, kabilang ang Ada, BASIC, Fortran, Pascal, at COBOL.

Mga katangian

[baguhin | baguhin ang wikitext]

Nagkakaiba-iba ang mga katangiang OOP na ibinibigay ng bawat wika. Nasa ibaba ang ilang karaniwang katangian ng mga wikang OOP.[23][24][25][26] Mahirap ihambing ang OOP sa iba pang estilo, gaya ng relational programming (pagpoprogramang relasyonal), dahil walang malinaw at pinagkaisahang depinisyon ng OOP.[27]

Encapsulation at information hiding

[baguhin | baguhin ang wikitext]

Ang information hiding (pagtatago ng impormasyon) at encapsulation (enkapsulasyon) ay maaaring tumukoy sa ilang magkakaugnay na konsepto:

  • Cohesion (pagkakaugnay), ang pagsasama-sama ng magkakaugnay na mga field at method. Ang field (kilala rin bilang attribute o property) ay naglalaman ng impormasyon (tinatawag ding state) bilang isang variable. Ang method (kilala rin bilang function o action) ay naglalarawan ng asal (behavior) sa pamamagitan ng lohikal na code (kodigo).
  • Decoupling (pagkakahiwalay ng mga bahagi), ang pag-oorganisa ng code upang ang piling bahagi lamang ng datos ang ginagamit ng mga kaugnay na function. Pinapadali ng decoupling ang pagbabago sa panloob na paggana ng isang object nang hindi naaapektuhan ang ibang bahagi ng codebase, gaya sa code refactoring (o muling pagsasaayos ng kodigo).[28] Ang mga object ay nagsisilbing hangganan sa pagitan ng kanilang panloob na mekanismo at ng panlabas na code na gumagamit sa kanila.
  • Data hiding (pagtatago ng datos), ang pagtatago ng mga panloob na detalye ng isang object mula sa panlabas na code. Ang code na gumagamit ay maaari lamang makipag-ugnayan sa object sa pamamagitan ng mga public member, dahil nagbibigay ang wika ng mga access modifier na kumokontrol kung paano nakikita (visibility) ang isang variable, method o class ng isang programa.

Ang ilang wikang pamprograma, gaya ng Java, ay nagbibigay ng information hiding sa pamamagitan ng mga visibility keyword tulad ng private at public.[29] Ang ibang wika, gaya ng Python, ay walang pormal na visibility feature, subalit sinusunod ng mga developer (o tagagawa ng programa) ang isang kumbensiyon tulad ng pagsisimula ng pangalan ng private member sa salungguhitan. Mayroon ding mga antas ng akses na nasa pagitan, gaya ng keyword na protected ng Java (na nagpapahintulot ng akses mula sa parehong class at mga subclass nito, subalit hindi mula sa mga object ng ibang class), at ang keyword na internal sa C#, Swift, at Kotlin, na naglilimita ng akses sa mga file sa loob ng iisang module.[30]

Sinasabi ng mga tagasuporta ng information hiding at data abstraction (abstraksyon ng dataos) na pinapadali nito ang muling paggamit ng code at intuitibong kumakatawan sa mga sitwasyon sa tunay na mundo.[31][32] Gayunman, may mga tumututol at nagsasabing hindi pinahuhusay ng OOP ang madaling pagbasa (readability) o modularidad.[33][34] Isinulat ni Eric S. Raymond na ang mga wikang OOP ay may tendensiyang maghikayat ng makakapal na patong-patong na mga programa na sumisira sa kalinawas. Inihahambing niya ito nang hindi pabor sa lapit ng Unix at ng wikang C.[35]

Kasama sa SOLID ang prinsipyong bukas/nakasara (open/closed principle), na nagsasaad na ang mga class at function ay dapat na "bukas para sa ekstensyon, subalit sarado para sa pagbabago". Ipinahayag ni Luca Cardelli na ang mga wikang OOP ay may "napakahinang katangian ng modularidad pagdating sa pagpapalawig at pagbabago ng class", at may tendensiyang maging labis na komplikado.[33] Inulit ang puntong ito ni Joe Armstrong, pangunahing imbentor ng Erlang, na sinipi na nagsabing:[34]

Ang problema sa mga wikang object-oriented ay dala-dala nila ang lahat ng di-tahas na kapaligirang nito. Gusto mo ng saging, pero ang nakuha mo ay isang gorilya na may hawak na saging at ang buong gubat.

Sinabi ni Leo Brodie na ang information hiding ay maaaring humantong sa pagdodoble ng code,[36] na sumasalungat sa patakarang don't repeat yourself (huwag mong ulitin ang sarili mo) sa pagde-develop ng software.[37]

Inheritance

[baguhin | baguhin ang wikitext]

Maaaring suportahan ang inheritance o pagmamana sa pamamagitan ng class o prototype. Magkaiba man ang mga ito, gumagamit sila ng magkakatulad na termino tulad ng object at instance.

Batay sa class

[baguhin | baguhin ang wikitext]

Sa class-based programming (o pagpoprograma batay sa class), ang pinakakaraniwang uri ng OOP, ang isang object ay isang instance ng isang class. Tinutukoy ng class ang datos (mga variable) at mga method (lohika). Nililikha ang object sa pamamagitan ng constructor. Ang bawat instance ng class ay may parehong hanay ng mga variable at method. Maaaring kabilang ang mga elemento sa:

  • Class variable – pag-aari ng mismong class; iisang kopya lamang ang pinagsasaluhan ng lahat ng object ng class
  • Instance variable – pag-aari ng object; bawat object ay may sariling bersyon ng mga variable na ito
  • Member variable – tumutukoy kapwa sa class variable at instance variable ng isang class
  • Class method – maaari lamang gumamit ng class variable
  • Instance method – pag-aari ng object; maaaring gumamit ng parehong instance at class variable

Maaaring magmana ang mga class mula sa iba pang class, na lumilikha ng isang herarkiya ng mga class: isang kaso ng subclass na nagmamana mula sa super-class. Halimbawa, ang class na Empleyado ay maaaring magmana mula sa class na Persona, na nagbibigay sa object na Empleyado ng mga variable mula sa Persona. Maaaring magdagdag ang subclass ng mga variable at method na hindi nakaaapekto sa super-class. Pinahihintulutan din ng karamihan sa mga wika ang subclass na i-override ang mga method ng super-class. Sinusuportahan ng ilang wika ang maramihang inheritance, kung saan ang isang class ay maaaring magmana mula sa higit sa isang class, at may iba namang sumusuporta sa mga mixin o trait. Halimbawa, ang isang mixin na tinatawag na UnicodeConversionMixin ay maaaring magdagdag ng method na unicode_tungong_ascii() sa parehong class na FileReader at WebPageScraper.

Ang isang abstract class ay hindi maaaring direktang gawing object. Ginagamit lamang ito bilang super-class.

Mayroon ding mga utility class na naglalaman lamang ng mga class variable at class method, at hindi nilalayong gawing instance o gawing basehan ng subclass.[38]

Batay sa prototype

[baguhin | baguhin ang wikitext]

Sa halip na magbigay ng konsepto ng class, sa prototype-based programming (o pagpoprograma batay sa prototype), ang isang object ay iniuugnay sa isa pang object na tinatawag na prototype o parent. Sa Self, maaaring magkaroon ang isang object ng marami o walang parent, subalit sa pinakapopular na wikang nakabatay sa prototype, ang JavaScript, ang isang object ay may eksaktong isang prototype link, hanggang sa batayang object na ang prototype ay null.

Ang prototype ay nagsisilbing modelo para sa mga bagong object. Halimbawa, kung mayroon kang object na prutas, maaari kang lumikha ng dalawang object na mansanas at narangha na nagbabahagi ng mga katangian ng prototype na prutas. Pinahihintulutan din ng mga wikang nakabatay sa prototype ang mga object na magkaroon ng kani-kanilang natatanging katangian, kaya maaaring magkaroon ang object na mansanas ng attribute na dami_ng_asukal, samantalang wala nito ang object na narangha o prutas.

Walang inheritance

[baguhin | baguhin ang wikitext]

Sa lahat ng wikang OOP, sa pamamagitan ng object composition, maaaring maglaman ang isang object ng iba pang mga object. Halimbawa, ang object na Empleyado ay maaaring maglaman ng object na Tirahan, kasama ng iba pang impormasyon tulad ng pangalan at posisyon. Ang composition ay isang ugnayang "mayroon" (has-a), tulad ng "ang empleyado ay may tirahan". Ang ilang wika, gaya ng Go, ay hindi sumusuporta sa inheritance.[39] Sa halip, hinihikayat nila ang prinsipyong "composition over inheritance" (komposisyon kaysa pagmamana), kung saan binubuo ang mga object gamit ang mas maliliit na bahagi sa halip na ugnayang parent at child. Halimbawa, sa halip na magmana mula sa class na Persona, maaaring maglaman na lamang ang class na Empleyado ng isang object na Persona. Pinahihintulutan nito ang class na Empleyado na kontrolin kung gaano karami sa Persona ang ilalantad nito sa ibang bahagi ng programa. Ang delegation ay isa pang katangian ng wika na maaaring gamitin bilang alternatibo sa inheritance.

Magkakaiba ang pananaw ng mga programmer o tagapagprograma tungkol sa inheritance. Ipinahayag ni Bjarne Stroustrup, may-akda ng C++, na posibleng gumawa ng OOP nang walang inheritance.[40] Pinuna naman ni Rob Pike ang inheritance dahil lumilikha ito ng masalimuot na herarkiya sa halip na mas payak na mga solusyon.[41]

Inheritance at behavioral subtyping

[baguhin | baguhin ang wikitext]

Madalas isipin na kapag ang isang class ay nagmana mula sa isa pa, nangangahulugan itong ang subclass ay "isang mas tiyak na uri" ng orihinal na class. Ipinapalagay nito na sa semantika ng programa, ang mga object mula sa subclass ay maaaring palaging ipalit sa mga object ng orihinal na class nang walang problema. Ang konseptong ito ay kilala bilang behavioral subtyping (o pagsa-subtipo ng pagkilos), partikular ang prinsipyong substitusyong Liskov.

Gayunman, madalas itong hindi totoo, lalo na sa mga wikang pamprograma na nagpapahintulot ng mga mutable object, mga object na nagbabago matapos malikha. Sa katunayan, ang subtype polymorphism na ipinapatupad ng type checker sa mga wikang OOP ay hindi makagagarantiya ng behavioral subtyping sa karamihan, kung hindi man sa lahat, ng konteksto. Halimbawa, ang circle-ellipse problem (o suliraning bilog-elipse) ay kilalang mahirap lutasin gamit ang konsepto ng inheritance sa OOP. Ang behavioral subtyping ay di-matukoy sa pangkalahatan, kaya hindi ito madaling ipatupad ng isang compiler. Dahil dito, kailangang maingat na idisenyo ng mga programmer ang mga herarkiya ng class upang maiwasan ang mga pagkakamaling hindi kayang hulihin ng mismong wika.

Dynamic dispatch

[baguhin | baguhin ang wikitext]

Maaaring tawagin ang isang method sa pamamagitan ng dynamic dispatch (o pagtatalagang dinamiko), kung saan pinipili ang method sa runtime (o oras ng pagtakbo) sa halip na sa oras ng pag-compile. Kapag ang pagpili ng method ay nakabatay sa higit sa isang uri ng object (tulad ng ibang mga object na ipinapasa bilang mga parameter), ito ay tinatawag na multiple dispatch (o maramihang pagtatalaga). Sa kontekstong ito, ang pagtawag sa method ay tinatawag ding message passing (o pagpapasa ng mensahe), na nangangahulugang ang pangalan ng method at ang mga input o ipinasok nito ay parang isang mensaheng ipinapadala sa object upang ito ay kumilos.[42]

Gumagana ang dynamic dispatch kasabay ng inheritance: kung ang isang object ay walang hinihinging method, hahanapin nito ito sa parent class (delegation), at magpapatuloy pataas sa kadena hanggang sa makahanap ng tumutugmang method.

Polymorphism

[baguhin | baguhin ang wikitext]

Ang polymorphism (polimorpismo) sa OOP ay tumutukoy sa subtyping o subtype polymorphism, kung saan ang isang function ay maaaring gumana gamit ang isang tiyak na interface at sa gayon ay manipulahin ang mga entidad ng iba't ibang class sa iisang paraan.[43]

Halimbawa, isipin ang isang programa na may dalawang hugis: bilog at parisukat. Pareho silang nagmula sa isang karaniwang class na tinatawag na Hugis. Bawat hugis ay may sariling paraan ng pagguhit ng sarili nito. Sa subtype polymorphism, hindi na kailangang malaman ng programa ang eksaktong uri ng bawat hugis, at maaari na lamang nitong tawagin ang method na Guhit para sa bawat isa. Sisiguruhin ng runtime ng wika na ang tamang bersyon ng method na Guhit ang tatakbo para sa bawat hugis. Dahil ang mga detalye ng bawat hugis ay pinangangasiwaan sa loob ng kani-kanilang class, nagiging mas simple at mas organisado ang code, at napapalakas ang malinaw na paghihiwalay ng mga tungkulin (separation of concerns).

Open recursion

[baguhin | baguhin ang wikitext]

Maaaring ma-access o tawagin ng mga method ng isang object ang datos ng mismong object. Maraming wikang pamprograma ang gumagamit ng isang espesyal na salita, tulad ng this o self, upang tukuyin ang kasalukuyang object. Sa mga wikang sumusuporta sa open recursion (rekursyong bukas), ang isang method sa loob ng isang object ay maaaring tumawag ng iba pang mga method sa parehong object, kabilang ang sarili nito, gamit ang espesyal na salitang ito. Pinahihintulutan nito ang isang method sa isang class na tumawag ng isa pang method na tinukoy sa kalaunang subclass, isang katangiang kilala bilang late binding (huling pagtatalaga).

Kasikatan at pagtanggap

[baguhin | baguhin ang wikitext]

Maraming tanyag na wikang pamprograma, gaya ng C++, Java, at Python, ang gumagamit ng OOP. Noong nakaraan, malawak na tinanggap ang OOP,[44] subalit sa mga nakaraang taon, may ilang programmer o tapagprograma na pumuna rito at mas pinipili na ngayon ang functional programming o pagpoprogramang punsyunal.[45] Natuklasan sa isang pag-aaral nina Potok at iba pa na walang malaking pagkakaiba sa produktibidad sa pagitan ng OOP at procedural programming (pagpoprogramang pamamaraan).[46]

Naniniwala ang ilan na labis na binibigyang-diin ng OOP ang paggamit ng mga object kaysa sa mga algoritmo at estruktura ng datos.[47][48] Halimbawa, binigyang-diin ng programmer na si Rob Pike na maaaring magdulot ang OOP ng labis na pagtuon ng mga programmer sa herarkiya ng mga uri (type hierarchy) sa halip na sa komposisyon. Tinawag pa niya ang OOP na "mga numerong Romano ng kompyuting".[49] Inilarawan naman ni Rich Hickey, lumikha ng Clojure, ang OOP bilang labis na pinasimple, lalo na pagdating sa paglalarawan ng mga bagay sa tunay na mundo na nagbabago sa paglipas ng panahon.[48] Sinabi ni Alexander Stepanov na sinusubukan ng OOP na ipasok ang lahat sa iisang uri (type), na maaaring maging limitasyon. Iginiit niya na kung minsan ay kailangan ang alhebrang may maraming uri: mga pamilya ng interface na sumasaklaw sa maraming uri, gaya sa generic programming (o pagpoprogramang pangkalahatan). Dagdag pa niya, ang pagtawag sa lahat bilang "object" ay hindi gaanong nakadaragdag sa pag-unawa.[47]

Nilikha ang OOP upang gawing mas madali ang muling paggamit at pagpapanatili ng code.[50] Gayunman, hindi ito dinisenyo upang malinaw na ipakita ang daloy ng mga tagubilin ng isang programa. Ipinagkatiwala ito sa compiler. Habang nagsimulang gumamit ang mga kompyuter ng mas maraming parallel processing o sabay-sabay na pagproseso at multiple threads (o maramihang tagabulin), naging mas mahalaga ang pag-unawa at pagkontrol sa daloy ng mga tagubilin. Mahirap itong gawin gamit ang OOP.[51][52][53][54]

Naniniwala si Paul Graham, isang kilalang siyentista sa agham pangkompyuter, na gusto ng malalaking kumpanya ang OOP dahil nakatutulong ito sa pamamahala ng malalaking pangkat ng mga karaniwang programmer. Ayon sa kaniya, nagdaragdag ang OOP ng istruktura, kaya mas mahirap para sa isang tao na gumawa ng seryosong pagkakamali, subalit kasabay nito'y nililimitahan nito ang mga mahuhusay na programmer.[55] Ipinapahayag naman ni Eric S. Raymond, isang programmer ng Unix at tagapagtaguyod ng open-source software (software na may bukas na code), na hindi ang OOP ang pinakamahusay na paraan ng pagsulat ng mga programa.[35]

Ayon kay Richard Feldman, bagaman nakatulong ang mga katangian ng OOP upang manatiling organisado ang ilang wika, nagmumula ang kanilang kasikatan sa iba pang mga dahilan.[56] Iginiit ni Lawrence Krubner na hindi nagbibigay ang OOP ng natatanging bentahe kumpara sa iba pang mga estilo, tulad ng functional programming, at maaari pa nitong gawing mas komplikado ang pagsulat ng code.[57] Sinabi naman ni Luca Cardelli na mas mabagal ang OOP at mas matagal i-compile kaysa sa procedural programming.[58]

Mga sanggunian

[baguhin | baguhin ang wikitext]
  1. 1 2 3 Kay, Dr. Alan (23 Hulyo 2003). "Dr. Alan Kay on the Meaning of "Object-Oriented Programming"" (sa wikang Ingles). Inarkibo mula sa orihinal noong 4 Mar 2025. Nakuha noong 11 Pebrero 2010.
  2. ↑ Kindler, E.; Krivy, I. (2011). "Object-Oriented Simulation of systems with sophisticated control". International Journal of General Systems (sa wikang Ingles). 40 (3): 313–343. doi:10.1080/03081079.2010.539975.
  3. ↑ Lewis, John; Loftus, William (2008). "1.6: Object-Oriented Programming". Java Software Solutions. Foundations of Programming Design (sa wikang Ingles) (ika-6 (na) labas). Pearson Education Inc. ISBN 978-0-321-53205-3.
  4. ↑ Bloch 2018, pp. xi–xii, Foreword (Paunang salita).
  5. ↑ McCarthy, J.; Brayton, R.; Edwards, D.; Fox, P.; Hodes, L.; Luckham, D.; Maling, K.; Park, D.; Russell, S. (Marso 1969). "LISP I Programmers Manual" (PDF). Computation Center and Research Laboratory of Electronics (sa wikang Ingles). Boston, Massachusetts: Artificial Intelligence Group, M.I.T. Computation Center and Research Laboratory: 88f. Inarkibo mula sa orihinal (PDF) noong 17 Hulyo 2010. In the local M.I.T. patois, association lists [of atomic symbols] are also referred to as "property lists", and atomic symbols are sometimes called "objects".
  6. ↑ McCarthy, John; Abrahams, Paul W.; Edwards, Daniel J.; Hart, Swapnil D.; Levin, Michael I. (1962). LISP 1.5 Programmer's Manual (sa wikang Ingles). MIT Press. p. 105. ISBN 978-0-262-13011-0. Object – a synonym for atomic symbol
  7. ↑ Ivan E. Sutherland (Mayo 1963). Sketchpad: a man-machine graphical communication system. AFIPS '63 (Spring): Proceedings of the May 21–23, 1963 Spring Joint Computer Conference (sa wikang Ingles). AFIPS Press. pp. 329–346. doi:10.1145/1461551.1461591.
  8. 1 2 Nygaard, Kristen; Dahl, Ole-Johan (Agosto 1, 1978). "The development of the SIMULA languages". ACM SIGPLAN Notices (sa wikang Ingles). 13 (8): 245–272. doi:10.1145/960118.808391.
  9. ↑ Ross, Doug. "The first software engineering language". LCS/AI Lab Timeline (sa wikang Ingles). MIT Computer Science and Artificial Intelligence Laboratory. Nakuha noong 13 Mayo 2010.{{cite web}}: CS1 maint: url-status (link)
  10. 1 2 Holmevik, Jan Rune (Tagniyebe 1994). "Compiling Simula: A historical study of technological genesis" (PDF). IEEE Annals of the History of Computing (sa wikang Ingles). 16 (4): 25–37. doi:10.1109/85.329756. S2CID 18148999. Inarkibo mula sa orihinal (PDF) noong 30 Agosto 2017. Nakuha noong 3 Marso 2018.
  11. ↑ Madsen, Ole Lehrman. "Kristen Nygaard". A.M. Turing Award Laureates (sa wikang Ingles). Nakuha noong 4 Pebrero 2025.
  12. ↑ Butcher, Paul (30 Hunyo 2014). Seven Concurrency Models in Seven Weeks: When Threads Unravel (sa wikang Ingles). Pragmatic Bookshelf. p. 204. ISBN 978-1-68050-466-8.
  13. ↑ Butcher, Paul (30 Hunyo 2014). Seven Concurrency Models in Seven Weeks: When Threads Unravel (sa wikang Ingles). Pragmatic Bookshelf. p. 204. ISBN 978-1-68050-466-8.
  14. 1 2 Bertrand Meyer (2009). Touch of Class: Learning to Program Well with Objects and Contracts (sa wikang Ingles). Springer Science & Business Media. p. 329. Bibcode:2009tclp.book.....M. ISBN 978-3-540-92144-8.
  15. ↑ Borning, Alan Hamilton (1979). Thinglab: a constraint-oriented simulation laboratory (PDF) (Ulat) (sa wikang Ingles). Stanford University.
  16. ↑ Moon, David A. (Hunyo 1986). "Object-Oriented Programming with Flavors" (PDF). Conference proceedings on Object-oriented Programming Systems Languages and Applications. OOPSLA '86 (sa wikang Ingles). pp. 1–8. doi:10.1145/28697.28698. ISBN 978-0-89791-204-4. S2CID 17150741. Nakuha noong 2022-03-17.
  17. ↑ Hsu, Hansen (17 Disyembre 2020). "Introducing the Smalltalk Zoo". CHM (sa wikang Ingles). Nakuha noong 27 Mayo 2021.{{cite news}}: CS1 maint: url-status (link)
  18. ↑ Bobrow, D. G.; Stefik, M. J (1982). LOOPS: data and object oriented Programming for Interlisp (PDF). European AI Conference (sa wikang Ingles).
  19. ↑ Meyer 1997.
  20. ↑ 1995 (Hunyo) Visual FoxPro 3.0, FoxPro evolves from a procedural language to an object-oriented language. Visual FoxPro 3.0 introduces a database container, seamless client/server capabilities, support for ActiveX technologies, and OLE Automation and null support. Summary of Fox releases (sa Ingles)
  21. ↑ 1995 Reviewers Guide to Visual FoxPro 3.0: DFpug.de (sa Ingles)
  22. ↑ Khurana, Rohit (1 Nobyembre 2009). Object Oriented Programming with C++, 1E (sa wikang Ingles). Vikas Publishing House Pvt Limited. ISBN 978-81-259-2532-3.
  23. ↑ Deborah J. Armstrong. The Quarks of Object-Oriented Development. A survey of nearly 40 years of computing literature identified several fundamental concepts found in the large majority of definitions of OOP, in descending order of popularity: Inheritance, Object, Class, Encapsulation, Method, Message Passing, Polymorphism, and Abstraction. (sa Ingles)
  24. ↑ John C. Mitchell, Concepts in programming languages, Cambridge University Press, 2003, ISBN 0-521-78098-5, p.278. Lists: Dynamic dispatch, abstraction, subtype polymorphism, and inheritance. (sa Ingles)
  25. ↑ Michael Lee Scott, Programming language pragmatics, Edition 2, Morgan Kaufmann, 2006, ISBN 0-12-633951-1, p. 470. Lists encapsulation, inheritance, and dynamic dispatch. (sa Ingles)
  26. ↑ Pierce, Benjamin (2002). Types and Programming Languages (sa wikang Ingles). MIT Press. ISBN 978-0-262-16209-8., seksyon 18.1 "What is Object-Oriented Programming?" Lists: Dynamic dispatch, encapsulation or multi-methods (multiple dispatch), subtype polymorphism, inheritance or delegation, open recursion ("this"/"self") (sa Ingles)
  27. ↑ C. J. Date, Introduction to Database Systems, ika-6-ed., Pahina 650 (sa Ingles)
  28. ↑ McDonough, James E. (2017). "Encapsulation". Object-Oriented Design with ABAP: A Practical Approach (sa wikang Ingles). Apress. doi:10.1007/978-1-4842-2838-8. ISBN 978-1-4842-2837-1 – sa pamamagitan ni/ng O'Reilly.
  29. ↑ Bloch 2018, pp. 73–77, Chapter §4 Item15 Minimize the accessibility of classes and members.
  30. ↑ "What is Object Oriented Programming (OOP) In Simple Words? – Software Geek Bytes" (sa wikang Ingles). 2023-01-05. Inarkibo mula sa orihinal noong 17 Enero 2023. Nakuha noong 2023-01-17.
  31. ↑ Cardelli, Luca; Wegner, Peter (1985-12-10). "On understanding types, data abstraction, and polymorphism". ACM Computing Surveys (sa wikang Ingles). 17 (4): 471–523. doi:10.1145/6041.6042. ISSN 0360-0300.
  32. ↑ Jacobsen, Ivar; Magnus Christerson; Patrik Jonsson; Gunnar Overgaard (1992). Object Oriented Software Engineering (sa wikang Ingles). Addison-Wesley ACM Press. pp. 43–69. ISBN 978-0-201-54435-0.
  33. 1 2 Cardelli, Luca (1996). "Bad Engineering Properties of Object-Oriented Languages". ACM Comput. Surv. (sa wikang Ingles). 28 (4es): 150–es. doi:10.1145/242224.242415. ISSN 0360-0300. S2CID 12105785. Nakuha noong 21 Abril 2010.
  34. 1 2 Armstrong, Joe. Seibel, Peter (pat.). Coders at Work: Reflections on the Craft of Programming (sa wikang Ingles). Codersatwork.com. Inarkibo mula sa orihinal noong 5 Marso 2010. Nakuha noong 13 Nobyembre 2009.
  35. 1 2 Raymond, Eric S. (2003). "The Art of Unix Programming: Unix and Object-Oriented Languages" (sa wikang Ingles). Nakuha noong 6 Agosto 2014.
  36. ↑ Brodie, Leo (1984). Thinking Forth (PDF) (sa wikang Ingles). pp. 92–93. Nakuha noong 4 Mayo 2018.
  37. ↑ Hunt, Andrew. "Don't Repeat Yourself". Category Extreme Programming (sa wikang Ingles). Nakuha noong 4 Mayo 2018.
  38. ↑ Bloch 2018, p. 19, Chapter §2 Item 4 Enforce noninstantiability with a private constructor.
  39. ↑ "Is Go an object-oriented language?" (sa wikang Ingles). Nakuha noong Abril 13, 2019. Although Go has types and methods and allows an object-oriented style of programming, there is no type hierarchy.{{cite web}}: CS1 maint: url-status (link)
  40. ↑ Stroustrup, Bjarne (2015). Object-Oriented Programming without Inheritance (Invited Talk). 29th European Conference on Object-Oriented Programming (ECOOP 2015) (sa wikang Ingles). 1:34. doi:10.4230/LIPIcs.ECOOP.2015.1.
  41. ↑ Pike, Rob (14 Nobyembre 2012). "A few years ago I saw this page" (sa wikang Ingles). Inarkibo mula sa orihinal noong 14 Agosto 2018. Nakuha noong 1 Oktubre 2016.
  42. ↑ Naik, Mayur; Kumar, Rajeev (Marso 2000). "Efficient message dispatch in object-oriented systems". ACM SIGPLAN Notices (sa wikang Ingles). 35 (3): 49–58. doi:10.1145/351159.351174.
  43. ↑ Stroustrup, Bjarne (Pebrero 19, 2007). "Bjarne Stroustrup's C++ Glossary" (sa wikang Ingles). Nakuha noong Hunyo 9, 2011. polymorphism – providing a single interface to entities of different types.{{cite web}}: CS1 maint: url-status (link)
  44. ↑ Brucker, Achim D.; Wolff, Burkhart (2008). "Extensible Universes for Object-Oriented Data Models". ECOOP 2008 – Object-Oriented Programming. Lecture Notes in Computer Science (sa wikang Ingles). Bol. 5142. pp. 438–462. doi:10.1007/978-3-540-70592-5_19. ISBN 978-3-540-70591-8. object-oriented programming is a widely accepted programming paradigm
  45. ↑ Cassel, David (21 Agosto 2019). "Why Are So Many Developers Hating on Object-Oriented Programming?". The New Stack (sa wikang Ingles).
  46. ↑ Potok, Thomas; Vouk, Mladen; Rindos, Andy (1999). "Productivity Analysis of Object-Oriented Software Developed in a Commercial Environment" (PDF). Software: Practice and Experience (sa wikang Ingles). 29 (10): 833–847. doi:10.1002/(SICI)1097-024X(199908)29:10<833::AID-SPE258>3.0.CO;2-P. S2CID 57865731. Nakuha noong 21 Abril 2010.
  47. 1 2 Stepanov, Alexander (2001–2008). "STLport: An Interview with A. Stepanov" (sa wikang Ingles). Nakuha noong 21 Abril 2010.
  48. 1 2 Hickey, Rich (Nobyembre 2009). Are We There Yet? (keynote). JVM Languages Summit (sa wikang Ingles).
  49. ↑ Pike, Rob (2 Marso 2004). "[9fans] Re: Threads: Sewing badges of honor onto a Kernel". comp.os.plan9 (Mailing list) (sa wikang Ingles). Nakuha noong 17 Nobyembre 2016.
  50. ↑ Ambler, Scott (1 Enero 1998). "A Realistic Look at Object-Oriented Reuse" (sa wikang Ingles). drdobbs.com. Nakuha noong 5 Agosto 2025.
  51. ↑ Shelly, Asaf (22 Agosto 2008). "Flaws of Object Oriented Modeling" (sa wikang Ingles). Intel Software Network. Nakuha noong 4 Hulyo 2010.
  52. ↑ James, Justin (1 Oktubre 2007). "Multithreading is a verb not a noun" (sa wikang Ingles). techrepublic.com. Inarkibo mula sa orihinal noong 10 Oktubre 2007. Nakuha noong 4 Hulyo 2010.
  53. ↑ Shelly, Asaf (22 Agosto 2008). "HOW TO: Multicore Programming (Multiprocessing) Visual C++ Class Design Guidelines, Member Functions" (sa wikang Ingles). support.microsoft.com. Nakuha noong 4 Hulyo 2010.
  54. ↑ Robert Harper (17 Abril 2011). "Some thoughts on teaching FP" (sa wikang Ingles). Existential Type Blog. Nakuha noong 5 Disyembre 2011.
  55. ↑ Graham, Paul. "Why ARC isn't especially Object-Oriented" (sa wikang Ingles). PaulGraham.com. Nakuha noong 13 Nobyembre 2009.
  56. ↑ Feldman, Richard (30 Setyembre 2019). "Why Isn't Functional Programming the Norm?". YouTube (sa wikang Ingles).
  57. ↑ Krubner, Lawrence. "Object Oriented Programming is an expensive disaster which must end" (sa wikang Ingles). smashcompany.com. Inarkibo mula sa orihinal noong 14 Oktubre 2014. Nakuha noong 14 Oktubre 2014.
  58. ↑ Cardelli, Luca (1996). "Bad Engineering Properties of Object-Oriented Languages". ACM Comput. Surv. (sa wikang Ingles). 28 (4es): 150–es. doi:10.1145/242224.242415. ISSN 0360-0300. S2CID 12105785. Nakuha noong 21 Abril 2010.

Talababa

[baguhin | baguhin ang wikitext]
[baguhin | baguhin ang wikitext]
Nagmula sa "https://tl.wikipedia.org/w/index.php?title=Object-oriented_programming&oldid=2192459"