การเขียนโปรแกรมเชิงวัตถุ ( OOP ) เป็นกระบวนทัศน์การเขียนโปรแกรมที่อิงตามวัตถุ^{[ 1 ]} – เอนทิ ตีซอฟต์แวร์ที่ห่อหุ้มข้อมูลและฟังก์ชันโปรแกรมคอมพิวเตอร์ OOP ประกอบด้วยวัตถุที่โต้ตอบกัน^{[ 2 ] [ 3 ]}ภาษาOOP คือ ภาษาที่มีคุณสมบัติการเขียนโปรแกรมเชิงวัตถุ แต่เนื่องจากชุดคุณสมบัติที่สนับสนุน OOP นั้นเป็นที่ถกเถียงกัน การจัดประเภทภาษาว่าเป็น OOP และระดับที่ภาษานั้นสนับสนุน OOP จึงเป็นเรื่องที่ถกเถียงกันได้ เนื่องจากกระบวนทัศน์ไม่ได้แยกออกจากกันโดยสิ้นเชิง ภาษาจึงสามารถเป็นได้หลายกระบวนทัศน์ (เช่น จัดอยู่ในประเภทมากกว่าแค่ OOP)

ภาษาที่โดดเด่นซึ่งรองรับ OOP ได้แก่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และVisual Basic (.NET )

แนวคิดเรื่อง "วัตถุ" ในการเขียนโปรแกรมเริ่มต้นจาก กลุ่ม ปัญญาประดิษฐ์ที่สถาบันเทคโนโลยีแมสซาชูเซตส์ (MIT) ในช่วงปลายทศวรรษ 1950 และต้นทศวรรษ 1960 โดย "วัตถุ" ในที่นี้หมายถึง อะตอม ของ LISPที่มีคุณสมบัติ (แอตทริบิวต์) ที่ระบุไว้^{[ 5 ] [ 6 ]} ตัวอย่างแรกๆ อีกตัวอย่างหนึ่งคือSketchpadที่สร้างโดยIvan Sutherlandที่ MIT ในปี 1960–1961 ในอภิธานศัพท์ของรายงานทางเทคนิคของเขา Sutherland ได้กำหนดคำศัพท์ต่างๆ เช่น "วัตถุ" และ "อินสแตนซ์" (โดยแนวคิดของคลาสถูกครอบคลุมโดย "มาสเตอร์" หรือ "คำจำกัดความ") แม้ว่าจะเฉพาะเจาะจงกับการโต้ตอบแบบกราฟิกก็ตาม^{[ 7 ]} ต่อมาในปี 1968 AED-0 ซึ่งเป็นเวอร์ชันของภาษาการเขียนโปรแกรม ALGOLของ MIT ได้เชื่อมต่อโครงสร้างข้อมูล ("plexes") และขั้นตอนต่างๆ ซึ่งเป็นต้นแบบของสิ่งที่ต่อมาเรียกว่า "ข้อความ" "เมธอด" และ "ฟังก์ชันสมาชิก" ^{[ 8 ] [ 9 ]} หัวข้อต่างๆ เช่นการนามธรรมของข้อมูลและการเขียนโปรแกรมแบบโมดูลาร์เป็นประเด็นสนทนาทั่วไปในช่วงเวลานี้

ในขณะเดียวกัน ในประเทศนอร์เวย์Simulaได้รับการพัฒนาในช่วงปี 1961–1967 ^{[ 8 ]} Simula ได้นำเสนอแนวคิดเชิงวัตถุที่สำคัญ เช่นคลาสการสืบทอด และการผูกแบบไดนามิก [ ^{10 ] Simula} ถูกใช้โดยนักวิจัยที่เกี่ยวข้องกับการสร้างแบบจำลองทางกายภาพ เป็นหลัก เช่น การเคลื่อนที่ของเรือและสิ่งของภายในเรือผ่านท่าเรือขนส่งสินค้า^{[ 10 ]}โดยทั่วไปแล้ว Simula ได้รับการยอมรับว่าเป็นภาษาแรกที่มีคุณสมบัติหลักและกรอบการทำงานของภาษาเชิงวัตถุ^{[ 11 ]}

ด้วยอิทธิพลจากทั้ง MIT และ Simula อลัน เคย์เริ่มพัฒนาแนวคิดของตนเองในเดือนพฤศจิกายน พ.ศ. 2509 เขาได้สร้างSmalltalkซึ่งเป็นภาษา OOP ที่ทรงอิทธิพลขึ้นมา ในปี พ.ศ. 2500 เคย์ได้ใช้คำว่า "การเขียนโปรแกรมเชิงวัตถุ" ในการสนทนาแล้ว^{[ 1 ]}แม้ว่าบางครั้งจะถูกเรียกว่าเป็น "บิดา" ของ OOP ^{[ 12 ]}เคย์กล่าวว่าแนวคิดของเขานั้นแตกต่างจากความเข้าใจทั่วไปของ OOP และได้บอกเป็นนัยว่าสถาบันวิทยาศาสตร์คอมพิวเตอร์ไม่ได้นำแนวคิดของเขาไปใช้^{[ 1 ]} บันทึกของ MIT ในปี พ.ศ. 2519 ซึ่งเขียนร่วมโดยบาร์บารา ลิสคอ ฟ ระบุว่าSimula 67 , CLUและAlphardเป็นภาษาเชิงวัตถุ แต่ไม่ได้กล่าวถึง Smalltalk ^{[ 13 ]}

ในช่วงทศวรรษ 1970 ภาษาโปรแกรม Smalltalkเวอร์ชันแรกได้รับการพัฒนาขึ้นที่Xerox PARCโดยAlan Kay , Dan IngallsและAdele Goldberg Smalltalk-72 โดดเด่นในด้านการใช้วัตถุในระดับภาษาและสภาพแวดล้อมการพัฒนาแบบกราฟิก^{[ 14 ]} Smalltalk เป็นระบบไดนามิกอย่างสมบูรณ์ ทำให้ผู้ใช้สามารถสร้างและแก้ไขคลาสได้ในขณะที่ทำงาน^{[ 15 ]}ทฤษฎี OOP ส่วนใหญ่ได้รับการพัฒนาในบริบทของ Smalltalk ตัวอย่างเช่น การสืบทอดแบบหลายทาง^{[ 16 ]}

ในช่วงปลายทศวรรษ 1970 และ 1980 OOP ได้รับความนิยมอย่างมากภาษา Lisp เชิงวัตถุFlavors ได้รับการพัฒนาขึ้นตั้งแต่ปี 1979 โดยนำเสนอ การสืบทอดแบบหลายทางและmixins ^{[ 17 ]}ในเดือนสิงหาคม 1981 นิตยสาร Byteได้เน้นย้ำถึง Smalltalk และ OOP โดยนำเสนอแนวคิดเหล่านี้ให้กับผู้ชมในวงกว้าง[ ^{18 ] LOOPS}ซึ่งเป็นระบบวัตถุสำหรับInterlisp -D ได้รับอิทธิพลจาก Smalltalk และ Flavors และมีการตีพิมพ์บทความเกี่ยวกับเรื่องนี้ในปี 1982 ^{[ 19 ]}ในปี 1986 การประชุมครั้งแรกเกี่ยวกับการเขียนโปรแกรมเชิงวัตถุ ระบบ ภาษา และแอปพลิเคชัน ( OOPSLA ) มีผู้เข้าร่วม 1,000 คน การประชุมครั้งนี้ถือเป็นจุดเริ่มต้นของความพยายามในการรวมระบบวัตถุของ Lisp ซึ่งในที่สุดก็ส่งผลให้เกิดCommon Lisp Object Systemในช่วงทศวรรษ 1980 มีความพยายามไม่กี่ครั้งในการออกแบบสถาปัตยกรรมโปรเซสเซอร์ที่รวมถึง การสนับสนุน ฮาร์ดแวร์สำหรับวัตถุในหน่วยความจำแต่ความพยายามเหล่านี้ไม่ประสบความสำเร็จ ตัวอย่าง ได้แก่Intel iAPX 432และ Linn Smart Rekursiv

ในช่วงกลางทศวรรษ 1980 ภาษาเชิงวัตถุใหม่ๆ เช่นObjective-C , C++และภาษา Eiffelได้ถือกำเนิดขึ้น Objective-C ได้รับการพัฒนาโดยBrad Coxซึ่งเคยใช้ Smalltalk ที่ITT Inc. Bjarne Stroustrupสร้าง C++ ขึ้นจากประสบการณ์การใช้ Simula สำหรับวิทยานิพนธ์ปริญญาเอกของเขา^{[ 14 ]} Bertrand Meyerออกแบบภาษา Eiffel เป็นครั้งแรกในปี 1985 โดยเน้นที่คุณภาพซอฟต์แวร์โดยใช้แนวทางการออกแบบตามสัญญา^{[ 20 ]}

ในช่วงทศวรรษ 1990 OOP กลายเป็นวิธีการเขียนโปรแกรมหลัก โดยเฉพาะอย่างยิ่งเมื่อมีภาษาโปรแกรมจำนวนมากขึ้นที่รองรับ OOP ซึ่งรวมถึงVisual FoxPro 3.0 ^{[ 21 ] [ 22 ]} C++ [ ^{23 ] และ} Delphi OOPได้รับความนิยมมากยิ่งขึ้นด้วยการเติบโตของส่วนต่อประสานผู้ใช้แบบกราฟิกซึ่งใช้วัตถุสำหรับปุ่ม เมนู และองค์ประกอบอื่นๆ ตัวอย่างที่รู้จักกันดีคือ เฟรมเวิร์ก Cocoa ของ Apple ซึ่งใช้บนmacOSและเขียนด้วยObjective-Cชุดเครื่องมือ OOP ยังช่วยเพิ่มความนิยมของ การ เขียน โปรแกรมแบบขับเคลื่อนด้วยเหตุการณ์ อีกด้วย

ที่ETH Zürichนิคลาอุส เวิร์ธและเพื่อนร่วมงานของเขาได้สร้างแนวทางใหม่ๆ ในการเขียนโปรแกรมเชิงวัตถุ (OOP) Modula-2 (1978) และOberon (1987) นำเสนอแนวทางที่โดดเด่นในการเขียนโปรแกรมเชิงวัตถุ คลาส และการตรวจสอบประเภทข้ามขอบเขตของโมดูล การสืบทอดไม่ชัดเจนในงานออกแบบของเวิร์ธ เนื่องจากระบบการตั้งชื่อของเขามองไปในทิศทางตรงกันข้าม: เรียกว่าการขยายประเภท (type extension) และมุมมองคือจากผู้ปกครองลงไปยังผู้สืบทอด

ภาษาโปรแกรมหลายภาษาที่พัฒนาขึ้นก่อนที่ OOP จะได้ รับ ความนิยม ได้ถูกเพิ่มเติมคุณสมบัติเชิงวัตถุเข้าไป เช่นAda , BASIC , Fortran , PascalและCOBOL

คุณสมบัติ OOP ที่มีอยู่ในภาษาต่างๆ นั้นแตกต่างกันไป ด้านล่างนี้คือคุณสมบัติทั่วไปบางประการของภาษา OOP ^{[ 24 ] [ 25 ] [ 26 ] [ 27 ]}การเปรียบเทียบ OOP กับรูปแบบอื่นๆ เช่นการเขียนโปรแกรมเชิงสัมพันธ์นั้นทำได้ยาก เนื่องจากไม่มีคำจำกัดความที่ชัดเจนและเป็นที่ยอมรับของ OOP ^{[ 28 ]}

การซ่อน และการห่อหุ้มข้อมูลสามารถหมายถึงแนวคิดที่เกี่ยวข้องหลายประการ:

• ความเชื่อมโยง คือการจัด กลุ่มฟิลด์และเมธอดที่เกี่ยวข้องเข้าด้วยกัน ฟิลด์ (หรือแอตทริบิวต์หรือคุณสมบัติ) จะเก็บข้อมูล (หรือสถานะ) ในรูปของตัวแปร ส่วนเมธอด (หรือฟังก์ชันหรือการกระทำ) จะกำหนดพฤติกรรมผ่านรหัสตรรกะ
• การแยกส่วน (Decoupling)คือการจัดระเบียบโค้ดเพื่อให้ฟังก์ชันที่เกี่ยวข้องใช้ข้อมูลเพียงบางส่วนเท่านั้น การแยกส่วนทำให้การเปลี่ยนแปลงวิธีการทำงานภายในของวัตถุทำได้ง่ายขึ้นโดยไม่ส่งผลกระทบต่อส่วนอื่น ๆ ของโค้ดเบสเช่น ในการปรับโครงสร้างโค้ด^{[ 29 ]}วัตถุทำหน้าที่เป็นขอบเขตระหว่างการทำงานภายในและการใช้งานโค้ดภายนอก
• การซ่อนข้อมูลคือการเก็บรายละเอียดภายในของวัตถุไว้ไม่ให้โค้ดภายนอกเห็น โค้ดที่ใช้งานจะสามารถโต้ตอบกับวัตถุได้ผ่านทางสมาชิกสาธารณะเท่านั้น เนื่องจากภาษาโปรแกรมมีตัวแก้ไขการเข้าถึงที่ควบคุมการมองเห็นได้

ภาษาโปรแกรมบางภาษา เช่น Java ให้การซ่อนข้อมูลผ่านคำหลักการมองเห็น ( privateและpublic) ^{[ 30 ]}บางภาษา เช่น Python ไม่มีคุณสมบัติการมองเห็น แต่ผู้พัฒนาอาจปฏิบัติตามธรรมเนียม เช่น การเริ่มต้นชื่อสมาชิกส่วนตัวด้วยเครื่องหมายขีดล่าง นอกจากนี้ยังมีระดับการเข้าถึงระดับกลาง เช่นprotectedคำหลัก `public` ของ Java (ซึ่งอนุญาตให้เข้าถึงจากคลาสเดียวกันและคลาสย่อย แต่ไม่ใช่วัตถุของคลาสอื่น) และinternalคำหลัก `public` ใน C#, Swift และ Kotlin ซึ่งจำกัดการเข้าถึงไฟล์ภายในโมดูลเดียวกัน^{[ 31 ]}

ผู้สนับสนุนการซ่อนข้อมูลและการแยกข้อมูลกล่าวว่ามันทำให้โค้ดนำกลับมาใช้ใหม่ได้ง่ายขึ้นและแสดงถึงสถานการณ์ในโลกแห่งความเป็นจริงได้อย่างเป็นธรรมชาติ^{[ 32 ] [ 33 ]}อย่างไรก็ตาม คนอื่นๆ โต้แย้งว่า OOP ไม่ได้ช่วยเพิ่มความสามารถในการอ่านหรือความเป็นโมดูลาร์^{[ 34 ] [ 35 ]} Eric S. Raymondได้เขียนไว้ว่าภาษา OOP มักจะส่งเสริมโปรแกรมที่มีเลเยอร์หนาซึ่งทำลายความโปร่งใส^{[ 36 ]} Raymond เปรียบเทียบสิ่งนี้กับแนวทางที่ใช้ในUnixและภาษาC ซึ่งไม่เป็นที่ยอมรับ ^{[ 36 ]}

SOLIDประกอบด้วยหลักการเปิด/ปิดซึ่งระบุว่าคลาสและฟังก์ชันควร "เปิดสำหรับการขยาย แต่ปิดสำหรับการแก้ไข" Luca Cardelliกล่าวว่าภาษา OOP มี "คุณสมบัติโมดูลาร์ที่แย่มากเมื่อเทียบกับการขยายและการแก้ไขคลาส" และมีแนวโน้มที่จะซับซ้อนมาก^{[ 34 ]}ประเด็นหลังนี้ได้รับการย้ำอีกครั้งโดยJoe Armstrongผู้คิดค้นหลักของErlangซึ่งมีคำกล่าวว่า: ^{[ 35 ]}

ปัญหาของภาษาโปรแกรมเชิงวัตถุคือ มันมีสภาพแวดล้อมแฝงอยู่มากมายที่มันพกพาไปด้วย คุณต้องการกล้วย แต่สิ่งที่คุณได้คือลิงกอริลลาถือกล้วยและป่าทั้งป่า

Leo Brodie กล่าวว่าการซ่อนข้อมูลอาจนำไปสู่โค้ดที่ซ้ำซ้อน [ ^{37 ]}ซึ่งขัดกับ กฎ ^"อย่าทำซ้ำตัวเอง"ในการพัฒนาซอฟต์แวร์^{[ 38 ]}

การสืบทอดสามารถทำได้ผ่านทางคลาสหรือโปรโตไทป์ซึ่งมีความแตกต่างกัน แต่ใช้คำที่คล้ายคลึงกัน เช่น อ็อบเจ็กต์และอินสแตนซ์

ในการเขียนโปรแกรมแบบคลาสซึ่งเป็นรูปแบบการเขียนโปรแกรมเชิงวัตถุ (OOP) ที่พบได้บ่อยที่สุด อ็อบเจ็กต์คืออินสแตนซ์ของคลาส คลาสจะกำหนดข้อมูล (ตัวแปร) และเมธอด (ตรรกะ) อ็อบเจ็กต์ถูกสร้างขึ้นผ่านคอนสตรัคเตอร์ทุกอินสแตนซ์ของคลาสจะมีชุดตัวแปรและเมธอดเหมือนกัน องค์ประกอบอาจรวมถึง:

• ตัวแปรคลาส – เป็นของคลาสเอง วัตถุทั้งหมดของคลาสจะใช้สำเนาเดียวกัน
• ตัวแปรอินสแตนซ์ – เป็นของวัตถุแต่ละชิ้น วัตถุแต่ละชิ้นจะมีตัวแปรประเภทนี้เป็นของตัวเอง
• ตัวแปรสมาชิก – หมายถึงทั้งตัวแปรคลาสและตัวแปรอินสแตนซ์ของคลาส
• เมธอดของคลาส – สามารถใช้ได้เฉพาะตัวแปรของคลาสเท่านั้น
• เมธอดอินสแตนซ์ – เป็นของอ็อบเจ็กต์ สามารถใช้ได้ทั้งตัวแปรอินสแตนซ์และตัวแปรคลาส

คลาสอาจสืบทอดคุณสมบัติจากคลาสอื่น ทำให้เกิดลำดับชั้นของคลาส เช่น คลาสย่อยสืบทอดจากคลาสแม่ ตัวอย่างเช่นEmployeeคลาสหนึ่งอาจสืบทอดจากPersonคลาสที่มอบตัวแปรให้กับอ็อบเจ็กต์ Employee Personคลาสย่อยอาจเพิ่มตัวแปรและเมธอดที่ไม่ส่งผลกระทบต่อคลาสแม่ ภาษาโปรแกรมส่วนใหญ่ยังอนุญาตให้คลาสย่อยเขียนทับเมธอดของคลาสแม่ได้ บางภาษาสนับสนุนการสืบทอดแบบหลายทาง (multiple inheritance ) ซึ่งคลาสหนึ่งสามารถสืบทอดจากคลาสมากกว่าหนึ่งคลาสได้ และภาษาอื่นๆ ก็สนับสนุนมิกซ์อิน (mixin)หรือ เทรต ( trait ) ในลักษณะเดียวกัน ตัวอย่างเช่น มิกซ์อินที่ชื่อ UnicodeConversionMixin อาจเพิ่มเมธอด unicode_to_ascii() ให้กับทั้งคลาส FileReader และ WebPageScraper

คลาสแบบนามธรรมไม่สามารถสร้างอ็อบเจ็กต์โดยตรงได้ มันถูกใช้เป็นเพียงคลาสแม่เท่านั้น

คลาสอื่นๆ เป็นคลาสยูทิลิตี้ซึ่งมีเฉพาะตัวแปรคลาสและเมธอดเท่านั้น และไม่ได้มีไว้สำหรับการสร้างอินสแตนซ์หรือคลาสย่อย^{[ 39 ]}

แทนที่จะใช้แนวคิดคลาส ในการเขียนโปรแกรมแบบใช้ต้นแบบวัตถุจะเชื่อมโยงกับวัตถุอื่นที่เรียกว่าต้นแบบหรือผู้ปกครองใน Self วัตถุอาจมีผู้ปกครองหลายคนหรือไม่มีเลยก็ได้^{[ 40 ]}แต่ในภาษาการเขียนโปรแกรมแบบใช้ต้นแบบที่เป็นที่นิยมมากที่สุดอย่างJavaScriptวัตถุจะมีลิงก์ต้นแบบเพียงหนึ่งเดียวเท่านั้น จนถึงวัตถุพื้นฐานที่มีต้นแบบเป็นค่าว่าง

ต้นแบบทำหน้าที่เป็นแบบจำลองสำหรับวัตถุใหม่ ตัวอย่างเช่น หากคุณมีวัตถุfruitคุณสามารถสร้างวัตถุappleและ สอง orangeตัวที่มีคุณสมบัติร่วมกันกับfruitต้นแบบได้ ภาษาที่ใช้ต้นแบบยังอนุญาตให้วัตถุมีคุณสมบัติเฉพาะตัวได้ด้วย ดังนั้นappleวัตถุ อาจมีแอตทริบิวต์sugar_contentในขณะที่วัตถุ orangeหรือ ไม่มีfruit

ในภาษา OOP ทั้งหมด ผ่านการประกอบวัตถุวัตถุหนึ่งสามารถบรรจุวัตถุอื่นได้ ตัวอย่างเช่นEmployeeวัตถุหนึ่งอาจบรรจุAddressวัตถุอีกวัตถุหนึ่ง พร้อมกับข้อมูลอื่นๆ เช่นnameและpositionการประกอบเป็นความสัมพันธ์แบบ "มี" เช่น "พนักงานมีที่อยู่" บางภาษา เช่นGoไม่รองรับการสืบทอด^{[ 41 ]}แต่จะสนับสนุน " การประกอบมากกว่าการสืบทอด " โดยที่วัตถุถูกสร้างขึ้นโดยใช้ส่วนย่อยๆ แทนที่จะเป็นความสัมพันธ์แบบพ่อ-ลูก ตัวอย่างเช่น แทนที่จะสืบทอดจากคลาส Person คลาส Employee อาจบรรจุวัตถุ Person ไว้ภายใน วิธีนี้ทำให้คลาส Employee สามารถควบคุมได้ว่าจะเปิดเผย Person ให้กับส่วนอื่นๆ ของโปรแกรมมากน้อยเพียงใดการมอบหมายเป็นคุณลักษณะของภาษาอีกอย่างหนึ่งที่สามารถใช้เป็นทางเลือกแทนการสืบทอดได้

โปรแกรมเมอร์มีความคิดเห็นที่แตกต่างกันเกี่ยวกับการสืบทอด Bjarne Stroustrup ผู้เขียน C++ กล่าวว่าสามารถทำ OOP ได้โดยไม่ต้องใช้การสืบทอด^{[ 42 ]} Rob Pikeได้วิจารณ์การสืบทอดว่าสร้างลำดับชั้นที่ซับซ้อนแทนที่จะสร้างวิธีแก้ปัญหาที่ง่ายกว่า^{[ 43 ]}

หลายคนมักคิดว่าหากคลาสหนึ่งสืบทอดมาจากอีกคลาสหนึ่ง นั่นหมายความว่าคลาสย่อยนั้น " เป็น " เวอร์ชันที่เฉพาะเจาะจงกว่าของคลาสเดิมสมมติฐาน นี้ตั้งอยู่บนพื้นฐาน ที่ว่า วัตถุจากคลาสย่อยสามารถแทนที่วัตถุจากคลาสเดิมได้เสมอโดยไม่มีปัญหา แนวคิดนี้เรียกว่าการกำหนดชนิดย่อยเชิงพฤติกรรม (behavioral subtyping ) หรือที่เรียกกันว่าหลักการแทนที่ของลิสคอฟ (Liskov substitution principle )

อย่างไรก็ตาม สิ่งนี้มักไม่เป็นความจริง โดยเฉพาะอย่างยิ่งในภาษาโปรแกรมที่อนุญาตให้ มี วัตถุที่เปลี่ยนแปลงได้ ซึ่งเป็นวัตถุที่เปลี่ยนแปลงไปหลังจากถูกสร้างขึ้นแล้ว ในความเป็นจริง การพหุ รูปย่อย (subtype polymorphism)ที่บังคับใช้โดยตัวตรวจสอบประเภทในภาษา OOP ไม่สามารถรับประกันการพหุรูปย่อยเชิงพฤติกรรมได้ในบริบทส่วนใหญ่หรือทั้งหมด ตัวอย่างเช่นปัญหาของวงกลมและวงรีนั้นจัดการได้ยากมากโดยใช้แนวคิดการสืบทอดของ OOP การพหุรูปย่อยเชิงพฤติกรรมนั้นไม่สามารถตัดสินได้โดยทั่วไป ดังนั้นจึงไม่สามารถนำไปใช้โดยคอมไพเลอร์ได้ง่ายๆ ด้วยเหตุนี้ โปรแกรมเมอร์จึงต้องออกแบบลำดับชั้นของคลาสอย่างระมัดระวังเพื่อหลีกเลี่ยงข้อผิดพลาดที่ภาษาโปรแกรมเองไม่สามารถตรวจจับได้

อาจมีการเรียกใช้เมธอดผ่านการเรียกใช้แบบไดนามิกโดยที่เมธอดจะถูกเลือกในเวลารันไทม์แทนที่จะเป็นเวลาคอมไพล์ หากการเลือกเมธอดขึ้นอยู่กับวัตถุมากกว่าหนึ่งประเภท (เช่น วัตถุอื่นที่ส่งผ่านเป็นพารามิเตอร์) จะเรียกว่าการเรียกใช้แบบหลายรายการในบริบทนี้ การเรียกใช้เมธอดยังเรียกว่าการส่งข้อความซึ่งหมายความว่าชื่อเมธอดและอินพุตของเมธอดนั้นเปรียบเสมือนข้อความที่ส่งไปยังวัตถุเพื่อให้ดำเนินการ^{[ 44 ]}

การเรียกใช้เมธอดแบบไดนามิกทำงานร่วมกับการสืบทอด: หากอ็อบเจ็กต์ไม่มีเมธอดที่ร้องขอ มันจะค้นหาในคลาสแม่ ( การมอบหมาย ) และดำเนินการต่อไปตามลำดับชั้นเพื่อค้นหาเมธอดที่ตรงกัน

Polymorphismใน OOP หมายถึงsubtypingหรือ subtype polymorphism ซึ่งฟังก์ชันสามารถทำงานกับอินเทอร์เฟซ เฉพาะ และจัดการเอนทิตีของคลาสต่างๆ ในลักษณะเดียวกันได้^{[ 45 ]}

ตัวอย่างเช่น ลองนึกภาพโปรแกรมที่มีรูปทรงสองรูป คือ วงกลมและสี่เหลี่ยม ทั้งสองมาจากคลาสเดียวกันที่ชื่อว่า "Shape" แต่ละรูปทรงมีวิธีการวาดของตัวเอง ด้วยโพลีมอร์ฟิซึมแบบซับไทป์ โปรแกรมไม่จำเป็นต้องรู้ชนิดของแต่ละรูปทรง และสามารถเรียกใช้เมธอด "Draw" สำหรับแต่ละรูปทรงได้เลย ระบบรันไทม์ของภาษาโปรแกรมจะตรวจสอบให้แน่ใจว่าได้เรียกใช้เมธอด "Draw" เวอร์ชันที่ถูกต้องสำหรับแต่ละรูปทรง เนื่องจากรายละเอียดของแต่ละรูปทรงได้รับการจัดการภายในคลาสของตัวเอง ทำให้โค้ดง่ายขึ้นและเป็นระเบียบมากขึ้น ส่งผลให้เกิดการแยกส่วนการทำงานอย่าง ชัดเจน

เมธอดของอ็อบเจ็กต์สามารถเข้าถึงข้อมูลของอ็อบเจ็กต์ได้ ภาษาโปรแกรมหลายภาษาใช้คำพิเศษ เช่นthisหรือselfเพื่ออ้างถึงอ็อบเจ็กต์ปัจจุบัน ในภาษาที่รองรับการเรียกซ้ำแบบเปิดเมธอดในอ็อบเจ็กต์สามารถเรียกเมธอดอื่นในอ็อบเจ็กต์เดียวกัน รวมถึงตัวมันเองได้ โดยใช้คำพิเศษนี้ ซึ่งทำให้เมธอดในคลาสหนึ่งสามารถเรียกเมธอดอื่นที่กำหนดไว้ในภายหลังในคลาสย่อยได้ คุณสมบัตินี้เรียกว่าการผูกมัดแบบล่าช้า (late binding )

รูปแบบการออกแบบ (Design patterns)คือวิธีการแก้ปัญหาทั่วไปในการออกแบบซอฟต์แวร์ รูปแบบการออกแบบบางอย่างมีประโยชน์อย่างยิ่งสำหรับ OOP และโดยทั่วไปแล้วรูปแบบการออกแบบมักถูกนำเสนอในบริบทของ OOP

บางครั้ง วัตถุต่างๆ แสดงถึงสิ่งต่างๆ และกระบวนการในโลกแห่งความเป็นจริงในรูปแบบดิจิทัล^{[ 46 ]}ตัวอย่างเช่น โปรแกรมกราฟิกอาจมีวัตถุต่างๆ เช่นcircle, square, และmenuระบบช้อปปิ้งออนไลน์อาจมีวัตถุต่างๆ เช่นshopping cart, customer, และNiklaus Wirthproduct กล่าวว่า "กระบวนทัศน์นี้ [OOP] สะท้อนโครงสร้างของระบบในโลกแห่งความเป็นจริงอย่างใกล้ชิด และด้วยเหตุ นี้จึงเหมาะอย่างยิ่งสำหรับการสร้างแบบจำลองระบบที่ซับซ้อนซึ่งมีพฤติกรรมที่ซับซ้อน" ^{[ 47 ]}

อย่างไรก็ตาม บ่อยครั้งที่วัตถุแสดงถึงสิ่งที่เป็นนามธรรม เช่น ไฟล์ที่เปิดอยู่หรือตัวแปลงหน่วย ไม่ใช่ทุกคนที่เห็นด้วยว่า OOP ทำให้การคัดลอกโลกแห่งความเป็นจริงได้อย่างแม่นยำเป็นเรื่องง่าย หรือแม้แต่การทำเช่นนั้นเป็นสิ่งจำเป็นบ็อบ มาร์ตินแนะนำว่าเนื่องจากคลาสเป็นซอฟต์แวร์ ความสัมพันธ์ของคลาสจึงไม่ตรงกับความสัมพันธ์ในโลกแห่งความเป็นจริงที่คลาสเป็นตัวแทน^{[ 48 ]}เบอร์ทรานด์ เมเยอร์โต้แย้งว่าโปรแกรมไม่ใช่แบบจำลองของโลก แต่เป็นแบบจำลองของบางส่วนของโลก “ความเป็นจริงเป็นญาติห่างๆ กัน” ^{[ 49 ]}สตีฟ เยกเกตั้งข้อสังเกตว่าภาษาธรรมชาติขาดแนวทาง OOP ในการตั้งชื่อสิ่งของ (วัตถุ) ก่อนการกระทำ (เมธอด) ซึ่งแตกต่างจาก การเขียน โปรแกรมเชิงฟังก์ชันที่ทำในทางตรงกันข้าม^{[ 50 ]}สิ่งนี้อาจทำให้โซลูชัน OOP ซับซ้อนกว่าโซลูชันที่เขียนผ่านการเขียนโปรแกรมเชิง ขั้นตอน ^{[ 51 ]}

ต่อไปนี้เป็นรูปแบบการออกแบบซอฟต์แวร์ ที่โดดเด่น สำหรับวัตถุ OOP ^{[ 52 ]}

• อ็อบเจ็กต์ฟังก์ชัน : คลาสที่มีเมธอด main หนึ่งเมธอด ซึ่งทำหน้าที่เหมือนฟังก์ชันนิรนาม (ใน C++ ใช้ตัวดำเนินการฟังก์ชันoperator())
• อ็อบเจ็กต์ที่ไม่เปลี่ยนแปลงสถานะ : สถานะจะไม่เปลี่ยนแปลงหลังจากสร้างขึ้น
• อ็อบเจ็กต์ระดับเฟิร์สคลาส : สามารถใช้งานได้โดยไม่มีข้อจำกัด
• วัตถุคอนเทนเนอร์ : บรรจุวัตถุอื่นๆ ไว้ภายใน
• โรงงานสร้างวัตถุ : สร้างวัตถุอื่นๆ
• เมตาออบเจ็กต์ : ใช้สำหรับสร้างออบเจ็กต์อื่นๆ (คล้ายกับคลาสแต่เป็นออบเจ็กต์)
• วัตถุต้นแบบ (Prototype object) : เมตาออบเจ็กต์เฉพาะที่สร้างวัตถุใหม่โดยการคัดลอกตัวเอง
• อ็อบเจ็กต์ซิงเกิลตัน : อินสแตนซ์เดียวของคลาสของมันตลอดอายุการใช้งานของโปรแกรม
• อ็อบเจ็กต์ตัวกรอง : รับกระแสข้อมูลเป็นอินพุตและแปลงข้อมูลนั้นให้เป็นเอาต์พุตของอ็อบเจ็กต์

รูปแบบที่ไม่พึงประสงค์ที่พบได้บ่อยคือวัตถุที่เปรียบเสมือนพระเจ้าซึ่งเป็นวัตถุที่รู้หรือทำมากเกินไป

"Design Patterns: Elements of Reusable Object-Oriented Software"เป็นหนังสือชื่อดังที่ตีพิมพ์ในปี 1994 โดยผู้เขียนสี่คน ได้แก่ Erich Gamma , Richard Helm , Ralph Johnsonและ John Vlissidesผู้คนมักเรียกพวกเขาว่า "แก๊งสี่คน" หนังสือเล่มนี้กล่าวถึงจุดแข็งและจุดอ่อนของ OOP และอธิบายวิธีการแก้ปัญหาการเขียนโปรแกรมทั่วไป 23 วิธี

โซลูชันเหล่านี้ ซึ่งเรียกว่า "รูปแบบการออกแบบ" สามารถแบ่งออกเป็นสามประเภท:

• รูปแบบการสร้าง (5):รูปแบบโรงงาน ,รูปแบบโรงงานนามธรรม ,รูปแบบซิงเกิลตัน ,รูปแบบตัวสร้าง ,รูปแบบต้นแบบ
• รูปแบบโครงสร้าง (7):รูปแบบอะแดปเตอร์ ,รูปแบบสะพาน ,รูปแบบคอมโพสิต ,รูปแบบตกแต่ง ,รูปแบบฟาซาด ,รูปแบบน้ำหนักเบา ,รูปแบบพร็อกซี
• รูปแบบพฤติกรรม (11): รูป แบบห่วงโซ่ความรับผิดชอบ ,รูปแบบคำสั่ง ,รูปแบบตัวตีความ ,รูป แบบตัววนซ้ำ ,, รูปแบบความทรง จำ, รูปแบบผู้สังเกตการณ์ ,, รูป แบบกลยุทธ์, รูปแบบวิธีการแม่แบบ ,รูปแบบผู้เยี่ยมชม

ทั้งการเขียนโปรแกรมเชิงวัตถุ (OOP) และระบบจัดการฐานข้อมูลเชิงสัมพันธ์ (RDBMS) ถูกนำมาใช้กันอย่างแพร่หลายในซอฟต์แวร์ในปัจจุบัน อย่างไรก็ตามฐานข้อมูลเชิงสัมพันธ์ไม่ได้จัดเก็บวัตถุโดยตรง ซึ่งก่อให้เกิดความท้าทายเมื่อนำมาใช้ร่วมกัน ปัญหานี้เรียกว่าความไม่ลงตัวระหว่างวัตถุและฐานข้อมูลเชิงสัมพันธ์ (Object-Relational Impedance Mismatch )

เพื่อแก้ปัญหานี้ นักพัฒนาใช้วิธีการต่างๆ แต่ไม่มีวิธีใดสมบูรณ์แบบ^{[ 53 ]}หนึ่งในวิธีแก้ปัญหาที่พบบ่อยที่สุดคือการแมปอ็อบเจ็กต์เชิงสัมพันธ์ (ORM) ซึ่งช่วยเชื่อมต่อโปรแกรมเชิงวัตถุกับฐานข้อมูลเชิงสัมพันธ์ ตัวอย่างของเครื่องมือ ORM ได้แก่Visual FoxPro , Java Data ObjectsและRuby on Rails ActiveRecord

ฐานข้อมูลบางประเภทที่เรียกว่าฐานข้อมูลเชิงวัตถุถูกออกแบบมาให้ทำงานร่วมกับ OOP (Object-Oriented Programming) อย่างไรก็ตาม ฐานข้อมูลประเภทนี้ไม่ได้รับความนิยมหรือประสบความสำเร็จเท่ากับฐานข้อมูลเชิงสัมพันธ์

Date และ Darwen ได้เสนอพื้นฐานทางทฤษฎีที่ใช้ OOP เป็นระบบประเภท ที่ปรับแต่งได้ เพื่อรองรับ RDBMS แต่ห้ามวัตถุที่มีตัวชี้ไปยังวัตถุอื่น^{[ 54 ]}

ในการออกแบบที่ขับเคลื่อนด้วยความรับผิดชอบคลาสจะถูกสร้างขึ้นโดยคำนึงถึงสิ่งที่ต้องทำและข้อมูลที่แบ่งปันในรูปแบบของสัญญา ซึ่งแตกต่างจากการออกแบบที่ขับเคลื่อนด้วยข้อมูลที่คลาสถูกสร้างขึ้นโดยอิงจากข้อมูลที่ต้องจัดเก็บ ตามที่ Wirfs-Brock และ Wilkerson ผู้ริเริ่มการออกแบบที่ขับเคลื่อนด้วยความรับผิดชอบกล่าวไว้ การออกแบบที่ขับเคลื่อนด้วยความรับผิดชอบเป็นแนวทางที่ดีกว่า^{[ 55 ]}

SOLIDคือชุดกฎห้าข้อสำหรับการออกแบบซอฟต์แวร์ที่ดี ซึ่งคิดค้นโดยไมเคิล เฟเธอร์ส:

• หลักการความรับผิดชอบเดียว : ชั้นเรียนควรมีเหตุผลเดียวในการเปลี่ยนแปลงเท่านั้น
• หลักการเปิด/ปิด : ส่วนประกอบของซอฟต์แวร์ควรเปิดกว้างสำหรับการขยาย แต่ปิดกว้างสำหรับการแก้ไข
• หลักการทดแทนของลิสคอฟ : ​​ฟังก์ชันที่ใช้ตัวชี้หรือการอ้างอิงไปยังคลาสพื้นฐานจะต้องสามารถใช้วัตถุของคลาสที่สืบทอดมาได้โดยไม่ต้องรู้ว่าคลาสเหล่านั้นคืออะไร
• หลักการแบ่งแยกอินเทอร์เฟซ : ลูกค้าไม่ควรถูกบังคับให้พึ่งพาอินเทอร์เฟซที่พวกเขาไม่ได้ใช้งาน
• หลักการผกผันการพึ่งพา : พึ่งพานามธรรม ไม่ใช่รูปธรรม

GRASP (General Responsibility Assignment Software Patterns) เป็นชุดกฎการออกแบบซอฟต์แวร์อีกชุดหนึ่งที่สร้างโดยCraig Larmanซึ่งช่วยให้นักพัฒนาสามารถกำหนดความรับผิดชอบให้กับส่วนต่างๆ ของโปรแกรมได้: ^{[ 56 ]}

• หลักการสร้าง (Creator Principle): อนุญาตให้คลาสสร้างอ็อบเจ็กต์ที่ตนเองใช้งานอย่างใกล้ชิดได้
• หลักการผู้เชี่ยวชาญด้านข้อมูล: มอบหมายงานให้กับแต่ละชั้นเรียนโดยใช้ข้อมูลที่จำเป็น
• หลักการเชื่อมโยงต่ำ (Low Coupling Principle): ลดการพึ่งพาของคลาสเพื่อเพิ่มความยืดหยุ่นและบำรุงรักษาได้ง่ายขึ้น
• หลักการความสอดคล้องสูง: การออกแบบชั้นเรียนโดยให้มีหน้าที่รับผิดชอบหลักเพียงอย่างเดียว
• หลักการควบคุม: กำหนดการทำงานของระบบให้กับคลาสต่างๆ ที่แยกจากกัน เพื่อจัดการการไหลและการโต้ตอบ
• โพลีมอร์ฟิซึม: ช่วยให้สามารถใช้งานคลาสต่างๆ ผ่านอินเทอร์เฟซทั่วไป ซึ่งส่งเสริมความยืดหยุ่นและการนำกลับมาใช้ใหม่ได้
• หลักการสร้างงานแบบบริสุทธิ์: สร้างคลาสตัวช่วยเพื่อปรับปรุงการออกแบบ เพิ่มความสอดคล้อง และลดการเชื่อมโยงกัน

นักวิจัยได้พยายามกำหนดความหมายของ OOP อย่างเป็นทางการ การสืบทอดทำให้เกิดความยากลำบาก โดยเฉพาะอย่างยิ่งกับการโต้ตอบระหว่างการเรียกซ้ำแบบเปิดและสถานะที่ถูกห่อหุ้ม นักวิจัยได้ใช้ประเภทการเรียกซ้ำและประเภทข้อมูลโคพีชคณิตเพื่อรวมคุณสมบัติที่สำคัญของ OOP ^{[ 57 ]} Abadi และ Cardelli ได้กำหนดส่วนขยายหลายอย่างของSystem F _<:ที่จัดการกับวัตถุที่เปลี่ยนแปลงได้ ซึ่งอนุญาตให้ทั้งโพลีมอร์ฟิซึมของชนิดย่อยและโพลีมอร์ฟิซึมแบบพารามิเตอร์ (เจเนริก) และสามารถสร้างแบบจำลองแนวคิดและโครงสร้าง OOP หลายอย่างได้อย่างเป็นทางการ^{[ 58 ]}แม้ว่าจะไม่ใช่เรื่องง่าย แต่การวิเคราะห์แบบคงที่ของภาษาการเขียนโปรแกรมเชิงวัตถุ เช่น Java เป็นสาขาที่เติบโตเต็มที่แล้ว^{[ 59 ]}พร้อมด้วยเครื่องมือเชิงพาณิชย์หลายอย่าง^{[ 60 ]}

ภาษาโปรแกรมยอดนิยมหลายภาษา เช่น C++, Java และ Python ใช้ OOP ในอดีต OOP ได้รับการยอมรับอย่างกว้างขวาง^{[ 61 ]}แต่เมื่อเร็ว ๆ นี้ โปรแกรมเมอร์บางคนวิพากษ์วิจารณ์และนิยมการเขียนโปรแกรมเชิงฟังก์ชันแทน^{[ 62 ]}การศึกษาโดย Potok et al. พบว่าไม่มีความแตกต่างที่สำคัญในด้านประสิทธิภาพการทำงานระหว่าง OOP และการเขียนโปรแกรมเชิงขั้นตอน^{[ 63 ]}

บางคนเชื่อว่า OOP ให้ความสำคัญกับการใช้วัตถุมากเกินไป แทนที่จะให้ความสำคัญกับอัลกอริทึมและโครงสร้างข้อมูล^{[ 64 ] [ 65 ]}ตัวอย่างเช่น โปรแกรมเมอร์Rob Pikeชี้ให้เห็นว่า OOP อาจทำให้โปรแกรมเมอร์คิดถึงลำดับชั้นของประเภทมากกว่าการประกอบ^{[ 66 ]}เขาเรียก OOP ว่า " เลขโรมันของการคำนวณ" ^{[ 67 ]} Rich Hickeyผู้สร้างClojureอธิบายว่า OOP นั้นเรียบง่ายเกินไป โดยเฉพาะอย่างยิ่งเมื่อพูดถึงการแสดงสิ่งต่างๆ ในโลกแห่งความเป็นจริงที่เปลี่ยนแปลงไปตามเวลา^{[ 65 ]} Alexander Stepanovกล่าวว่า OOP พยายามที่จะจัดทุกอย่างให้อยู่ในประเภทเดียว ซึ่งอาจเป็นข้อจำกัด เขาโต้แย้งว่าบางครั้งเราต้องการพีชคณิตหลายประเภท: ตระกูลของอินเทอร์เฟซที่ครอบคลุมหลายประเภท เช่น ในการเขียนโปรแกรมแบบเจเนริก Stepanov ยังกล่าวอีกว่าการเรียกทุกอย่างว่า "วัตถุ" ไม่ได้ช่วยให้เข้าใจมากขึ้น^{[ 64 ]}

OOP ถูกสร้างขึ้นเพื่อให้โค้ดสามารถนำกลับมาใช้ใหม่และบำรุงรักษาได้ ง่ายขึ้น ^{[ 68 ]}อย่างไรก็ตาม มันไม่ได้ถูกออกแบบมาเพื่อแสดงลำดับการทำงานของคำสั่งในโปรแกรมอย่างชัดเจน หน้าที่นั้นตกอยู่กับคอมไพเลอร์ เมื่อคอมพิวเตอร์เริ่มใช้การประมวลผลแบบขนานและเธรด หลายตัว มากขึ้น การทำความเข้าใจและควบคุมการไหลของคำสั่งจึงมีความสำคัญมากขึ้น ซึ่งทำได้ยากด้วย OOP ^{[ 69 ] [ 70 ] [ 71 ] [ 72 ]}

Paul Grahamเชื่อว่าบริษัทขนาดใหญ่ชอบ OOP เพราะมันช่วยจัดการทีมโปรแกรมเมอร์ทั่วไปขนาดใหญ่ เขาให้เหตุผลว่า OOP เพิ่มโครงสร้าง ทำให้ยากที่คนคนเดียวจะทำผิดพลาดร้ายแรง แต่ในขณะเดียวกันก็จำกัดโปรแกรมเมอร์ที่ฉลาด^{[ 73 ]} Eric S. Raymondโปรแกรมเมอร์Unixและ ผู้สนับสนุน ซอฟต์แวร์โอเพนซอร์สโต้แย้งว่า OOP ไม่ใช่วิธีที่ดีที่สุดในการเขียนโปรแกรม^{[ 36 ]}

Richard Feldman กล่าวว่า แม้ว่าคุณสมบัติของ OOP จะช่วยให้บางภาษามีความเป็นระเบียบ แต่ความนิยมของภาษาเหล่านั้นมาจากเหตุผลอื่น^{[ 74 ]} Lawrence Krubner โต้แย้งว่า OOP ไม่ได้ให้ข้อได้เปรียบพิเศษเมื่อเทียบกับรูปแบบอื่นๆ เช่น การเขียนโปรแกรมเชิงฟังก์ชัน และอาจทำให้การเขียนโค้ดซับซ้อนขึ้น^{[ 75 ]} Luca Cardelliกล่าวว่า OOP ช้ากว่าและใช้เวลานานกว่าในการคอมไพล์เมื่อเทียบกับการเขียนโปรแกรมเชิงขั้นตอน^{[ 34 ]}

• เคดส์
• สถาปัตยกรรมตัวกลางการร้องขอวัตถุทั่วไป (CORBA)
• การเปรียบเทียบภาษาโปรแกรม (การเขียนโปรแกรมเชิงวัตถุ)
• วิศวกรรมซอฟต์แวร์แบบใช้ส่วนประกอบ
• วัตถุกระจาย
• โมเดลออบเจ็กต์ส่วนประกอบแบบกระจาย
• ภาษาอธิบายอินเทอร์เฟซ
• IDEF4
• เจรู
• รายชื่อภาษาการเขียนโปรแกรมเชิงวัตถุ
• การเชื่อมโยงวัตถุ
• การวิเคราะห์และการออกแบบเชิงวัตถุ
• การสร้างแบบจำลองเชิงวัตถุ
• ออนโทโลยีเชิงวัตถุ
• ยูเอ็มแอล

• อาบาดี, มาร์ติน ; ลูก้า คาร์เดลลี (1998) ทฤษฎีวัตถุ . สปริงเกอร์ แวร์แล็ก . ไอเอสบีเอ็น 978-0-387-94775-4.
• Abelson, Harold ; Gerald Jay Sussman (1997). โครงสร้างและการตีความโปรแกรมคอมพิวเตอร์ . สำนักพิมพ์ MIT . ISBN 978-0-262-01153-2เก็บถาวรจากต้นฉบับเมื่อวันที่ 26 ธันวาคม 2017 เรียกดูเมื่อวันที่ 22 มกราคม 2006
• Armstrong, Deborah J. (กุมภาพันธ์ 2549). "ควาร์กของการพัฒนาเชิงวัตถุ". Communications of the ACM . 49 (2): 123– 128. doi : 10.1145/1113034.1113040 . ISSN  0001-0782 . S2CID  11485502 .
• บล็อก, โจชัว (2018). "Effective Java: Programming Language Guide" (ฉบับที่สาม). แอดดิสัน-เวสลีย์. ISBN 978-0134685991.
• บูช, แกรดี้ (1997). การวิเคราะห์และการออกแบบเชิงวัตถุพร้อมการประยุกต์ใช้ . แอดดิสัน-เวสลีย์ . ISBN 978-0-8053-5340-2.
• อีลส์, ปีเตอร์; โอลิเวอร์ ซิมส์ (1998). การสร้างวัตถุทางธุรกิจ . จอห์น ไวลีย์ แอนด์ ซันส์ . ISBN 978-0-471-19176-6.
• แกมมา, เอริช ; ริชาร์ด เฮล์ม ; ราล์ฟ จอห์นสัน ; จอห์น วลิสไซด์ส (1995). รูปแบบการออกแบบ: องค์ประกอบของซอฟต์แวร์เชิงวัตถุที่นำกลับมาใช้ใหม่ได้ . แอดดิสัน-เวสลีย์. รหัสบรรณานุกรม : 1995dper.book.....G . ISBN 978-0-201-63361-0.
• Harmon, Paul ; William Morrissey (1996). The Object Technology Casebook – Lessons from Award-Winning Business Applications . John Wiley & Sons. ISBN 978-0-471-14717-6.
• Jacobson, Ivar (1992). วิศวกรรมซอฟต์แวร์เชิงวัตถุ: แนวทางที่ขับเคลื่อนด้วยกรณีการใช้งาน . Addison-Wesley. รหัสบรรณานุกรม : 1992oose.book.....J . ISBN 978-0-201-54435-0.
• เคย์, อลัน . ประวัติศาสตร์ยุคแรกของ Smalltalk . เก็บถาวรจากต้นฉบับเมื่อวันที่ 4 เมษายน 2548. สืบค้นเมื่อ18 เมษายน 2548 .
• Meyer, Bertrand (1997). การสร้างซอฟต์แวร์เชิงวัตถุ . Prentice Hall . ISBN 978-0-13-629155-8.
• Pecinovsky, Rudolf (2013). OOP – เรียนรู้การคิดและการเขียนโปรแกรมเชิงวัตถุ . สำนักพิมพ์ Bruckner. ISBN 978-80-904661-8-0.
• Rumbaugh, James ; Blaha, Michael; Premerlani, William; Eddy, Frederick; Lorensen, William (1991). การสร้างแบบจำลองและการออกแบบเชิงวัตถุ . Prentice Hall. ISBN 978-0-13-629841-0.
• Schach, Stephen (2006). วิศวกรรมซอฟต์แวร์เชิงวัตถุและแบบดั้งเดิม ฉบับที่เจ็ด . McGraw-Hill . ISBN 978-0-07-319126-3.
• ชไรเนอร์, แอ็กเซล-โทเบียส (1993) การเขียนโปรแกรมเชิงวัตถุด้วย ANSI- C ฮันเซอร์. hdl : 1850/8544 . ไอเอสบีเอ็น 978-3-446-17426-9.
• เทย์เลอร์, เดวิด เอ. (1992). ระบบสารสนเทศเชิงวัตถุ – การวางแผนและการนำไปใช้ . จอห์น ไวลีย์ แอนด์ ซันส์. ISBN 978-0-471-54364-0.
• ไวส์เฟลด์, แมตต์ (2009). กระบวนการคิดเชิงวัตถุ ฉบับที่สาม . แอดดิสัน-เวสลีย์ . ISBN 978-0-672-33016-2.
• เวสต์, เดวิด (2004). การคิดเชิงวัตถุ (คู่มืออ้างอิงสำหรับนักพัฒนา) . สำนักพิมพ์ไมโครซอฟต์ . ISBN 978-0-7356-1965-4.

Wikiquote มีคำคมที่เกี่ยวข้องกับ การ เขียนโปรแกรมเชิงวัตถุ

Wikiversity มีแหล่งข้อมูลการเรียนรู้เกี่ยวกับการเขียนโปรแกรมเชิงวัตถุอยู่ที่นี่

หัวข้อ: การเขียนโปรแกรมเชิงวัตถุ

เว็บไซต์ Wikibooks มีหนังสือเกี่ยวกับหัวข้อ: การเขียนโปรแกรมเชิงวัตถุ (Object Oriented Programming)

• บทนำสู่แนวคิดการเขียนโปรแกรมเชิงวัตถุ (OOP) และอื่นๆโดย LWC Nirosh
• การอภิปรายเกี่ยวกับข้อเสียของ OOP
• แนวคิดการเขียนโปรแกรมเชิงวัตถุ (บทเรียน Java)