OOP คืออะไร?

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

ฉันได้เขียนโค้ดจำนวนมากสำหรับแอปพลิเคชันที่หลากหลาย แม้ว่าจะมีสถานที่ที่การพิมพ์ย่อยที่ทดแทนกันได้จริงมีบทบาทสำคัญในแอปพลิเคชัน แต่สิ่งเหล่านี้ก็ค่อนข้างโดดเด่น โดยทั่วไปแล้วแม้ว่าจะมีการให้บริการริมฝีปากเพื่อพูดถึงการ "ใช้ซ้ำ" แต่ความจริงก็คือเว้นแต่โค้ดส่วนหนึ่งจะทำในสิ่งที่คุณต้องการได้อย่างตรงจุดแต่ก็มี "การใช้ซ้ำ" ที่คุ้มค่าน้อยมาก เป็นเรื่องยากมากที่จะออกแบบชั้นเรียนให้สามารถขยายได้อย่างถูกต้องและโดยปกติแล้วค่าใช้จ่ายในการขยายจึงสูงมากจน "ใช้ซ้ำ" เพียงอย่างเดียวจึงไม่คุ้มค่า

ในหลาย ๆ เรื่องสิ่งนี้ไม่ได้ทำให้ฉันประหลาดใจ โลกแห่งความเป็นจริงไม่ใช่ "OO" และความคิดนี้มีนัยใน OO - ที่เราสามารถจำลองสิ่งต่าง ๆ ด้วยอนุกรมวิธานของคลาส - ดูเหมือนว่าฉันจะมีข้อบกพร่องโดยพื้นฐานมาก (ฉันสามารถนั่งบนโต๊ะตอต้นไม้ฝากระโปรงรถ ตักของใครบางคน - แต่ไม่ใช่หนึ่งในนั้นคือเก้าอี้) แม้ว่าเราจะย้ายไปยังโดเมนที่เป็นนามธรรมมากขึ้น แต่การสร้างแบบจำลอง OO ก็มักจะยากไม่ตรงประเด็นและไม่เป็นประโยชน์ในที่สุด (ลองดูตัวอย่างวงกลม / จุดไข่ปลาหรือสี่เหลี่ยม / สี่เหลี่ยมผืนผ้า)

แล้วฉันพลาดอะไรไปที่นี่? มูลค่าของ OOP อยู่ที่ไหนและทำไมเวลาและเงินทั้งหมดถึงล้มเหลวในการทำให้ซอฟต์แวร์ดีขึ้น?

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

การแสดงเชิงวัตถุดูเหมือนจะไม่สามารถใช้งานได้ในระดับสากลหรือใช้งานได้น้อยลง

ไม่เพียงพอที่จะใช้วิธีการ OO เพียงอย่างเดียวและต้องการให้นักพัฒนาใช้วิธีการดังกล่าวเนื่องจากอาจส่งผลเสียต่อประสิทธิภาพการทำงานของนักพัฒนาและคุณภาพของระบบที่พัฒนาขึ้น

ซึ่งมาจาก "On the Usability of OO Representations" จาก Communications of the ACM ต.ค. 2543 บทความส่วนใหญ่เปรียบเทียบ OO กับแนวทางที่มุ่งเน้นกระบวนการ มีการศึกษามากมายว่าคนที่ทำงานด้วยวิธี OO "คิด" (Int. J. of Human-Computer Studies 2001, issue 54, or Human-Computer Interaction 1995, vol. 10 มีเนื้อหาเกี่ยวกับการศึกษา OO ทั้งหมด) และจากสิ่งที่ฉันอ่านไม่มีอะไรที่บ่งบอกถึงความเป็นธรรมชาติบางอย่างกับแนวทาง OO ที่ทำให้มันเหมาะสมกว่าวิธีการดำเนินการแบบเดิม ๆ

โลกแห่งความเป็นจริงไม่ใช่ "OO" และความคิดนี้มีนัยใน OO ซึ่งเราสามารถจำลองสิ่งต่าง ๆ ด้วยอนุกรมวิธานแบบคลาสได้สำหรับฉันดูเหมือนจะมีข้อบกพร่องโดยพื้นฐาน

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

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

OOP ไม่ได้เกี่ยวกับการสร้างคลาสที่ใช้ซ้ำได้ แต่เป็นการสร้างคลาสที่ใช้งานได้

บ่อยครั้งที่คลาสนี้ใช้สำหรับน้ำตาลที่เป็นประโยคเท่านั้น มันทำให้ฟังก์ชันสำหรับประเภทเรกคอร์ดเป็นเนมสเปซเล็ก ๆ ของตัวเอง

ใช่ฉันพบว่าสิ่งนี้แพร่หลายเกินไปเช่นกัน นี่ไม่ใช่การเขียนโปรแกรมเชิงวัตถุ เป็นการเขียนโปรแกรมตามวัตถุและการเขียนโปรแกรมโดยใช้ข้อมูลเป็นศูนย์กลาง ใน 10 ปีของการทำงานกับ OO Languages ​​ฉันเห็นคนส่วนใหญ่ทำ Object Based Programming OBP แบ่ง IMHO ออกอย่างรวดเร็วเนื่องจากคุณได้รับสิ่งที่เลวร้ายที่สุดจากทั้งสองคำ: 1) การเขียนโปรแกรมขั้นตอนโดยไม่ยึดติดกับวิธีการเขียนโปรแกรมแบบมีโครงสร้างที่พิสูจน์แล้วและ 2) OOP โดยไม่ยึดติดกับวิธีการ OOP ที่พิสูจน์แล้ว

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

นักพัฒนาส่วนใหญ่ที่ทำงานในภาษา OOP กำลังใช้ตัวอย่างของ OOP ที่ทำถูกต้องในกรอบและประเภทที่พวกเขาใช้วันต่อวัน แต่พวกเขาไม่รู้ นี่คือตัวอย่างง่ายๆบางส่วน: ADO.NET, Hibernate / NHibernate, Logging Frameworks, ประเภทคอลเลกชันภาษาต่างๆ, ASP.NET stack, The JSP stack เป็นต้นสิ่งเหล่านี้ล้วนต้องพึ่งพา OOP อย่างมากใน codebases

การใช้ซ้ำไม่ควรเป็นเป้าหมายของ OOP - หรือกระบวนทัศน์อื่น ๆ สำหรับเรื่องนั้น

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

ความคิดของ OO เป็นวิธีใหม่ในการนำกลับมาใช้ใหม่ผ่านการสืบทอดนั้นมีข้อบกพร่องโดยพื้นฐาน ดังที่คุณทราบว่ามีการละเมิด LSP มาก แต่ OO ถูกคิดอย่างเหมาะสมว่าเป็นวิธีการจัดการความซับซ้อนของโดเมนปัญหา เป้าหมายคือการบำรุงรักษาระบบเมื่อเวลาผ่านไป เครื่องมือหลักในการบรรลุเป้าหมายนี้คือการแยกส่วนติดต่อสาธารณะออกจากการใช้งานส่วนตัว สิ่งนี้ทำให้เรามีกฎเช่น "สิ่งนี้ควรแก้ไขโดยใช้ ... " ที่บังคับใช้โดยคอมไพเลอร์แทนที่จะตรวจสอบโค้ด

เมื่อใช้สิ่งนี้ฉันแน่ใจว่าคุณจะเห็นด้วยช่วยให้เราสร้างและดูแลระบบที่ซับซ้อนอย่างมาก มีคุณค่ามากมายในนั้นและไม่ใช่เรื่องง่ายที่จะทำในกระบวนทัศน์อื่น ๆ

หมิ่นศาสนา แต่ฉันจะบอกว่าคุณกำลังวาดภาพที่น่ากลัวเกินไปของสถานะ OOP สมัยใหม่ ฉันจะยืนยันว่ามันเป็นจริงได้ลดค่าใช้จ่ายทำโครงการซอฟต์แวร์ขนาดใหญ่ที่สามารถจัดการและอื่น ๆ นั่นไม่ได้หมายความว่าจะแก้ปัญหาพื้นฐานของความยุ่งเหยิงของซอฟต์แวร์และไม่ได้หมายความว่านักพัฒนาทั่วไปเป็นผู้เชี่ยวชาญ OOP แต่การโมดูลาร์ของฟังก์ชันเป็นส่วนประกอบของวัตถุได้ลดจำนวนสปาเก็ตตี้โค้ดลงในโลกอย่างแน่นอน

ฉันนึกถึงห้องสมุดหลายสิบแห่งที่สามารถนำกลับมาใช้ใหม่ได้อย่างสวยงามและช่วยประหยัดเวลาและเงินที่ไม่สามารถคำนวณได้

แต่ในกรณีที่ OOP เสียเวลาฉันจะบอกว่าเป็นเพราะขาดการฝึกอบรมโปรแกรมเมอร์ประกอบกับช่วงการเรียนรู้ที่สูงชันของการเรียนรู้การทำแผนที่ OOP เฉพาะภาษา บางคน "ได้รับ" OOP และคนอื่น ๆ จะไม่ทำ

ฉันคิดว่าการใช้อ็อบเจ็กต์บริบททึบแสง (HANDLEs ใน Win32, FILE * s ใน C เพื่อตั้งชื่อสองตัวอย่างที่รู้จักกันดี - hell, HANDLEs อาศัยอยู่อีกด้านหนึ่งของอุปสรรคโหมดเคอร์เนลและมันไม่ได้รับ มีการห่อหุ้มมากกว่านั้นมาก) พบได้ในรหัสขั้นตอนด้วยเช่นกัน ฉันกำลังดิ้นรนเพื่อดูว่านี่เป็นสิ่งเฉพาะสำหรับ OOP อย่างไร

HANDLEs (และ WinAPI ที่เหลือ) คือ OOP! C ไม่รองรับ OOP เป็นอย่างดีดังนั้นจึงไม่มีไวยากรณ์พิเศษ แต่ไม่ได้หมายความว่าจะไม่ใช้แนวคิดเดียวกัน WinAPI อยู่ในทุกความหมายของคำว่ากรอบเชิงวัตถุ

ดูนี่เป็นปัญหาในการอภิปรายทุกครั้งที่เกี่ยวข้องกับ OOP หรือเทคนิคทางเลือก: ไม่มีใครชัดเจนเกี่ยวกับคำจำกัดความทุกคนกำลังพูดถึงสิ่งอื่นดังนั้นจึงไม่มีฉันทามติที่สามารถเข้าถึงได้ ดูเหมือนเสียเวลากับฉัน

มันเป็นกระบวนทัศน์ในการเขียนโปรแกรม .. ออกแบบมาเพื่อให้มนุษย์เราสามารถแบ่งปัญหาออกเป็นชิ้นเล็ก ๆ และใช้การได้ง่ายขึ้น ..

ถ้าคุณไม่พบว่ามันมีประโยชน์ .. อย่าใช้มันอย่าจ่ายเงินเพื่อการฝึกอบรม

ในทางกลับกันฉันพบว่ามันมีประโยชน์ดังนั้นฉันจะ :)

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

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

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

ปัญหาของ OOP คือการขายเกินขนาด

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

จากนั้นผู้ให้คำปรึกษาด้านการจัดการบางประเภทก็จับมันและขายมันในฐานะพระเจ้าของซอฟต์แวร์และนักวิชาการและอุตสาหกรรมที่มีลักษณะคล้าย lemming ก็ร่วงลงไปในภายหลัง

ตอนนี้พวกเขาเหมือนไม้ลอยหลังจากความคิดดีๆอื่น ๆ ถูกขายไปมากเกินไปเช่นการเขียนโปรแกรมเชิงฟังก์ชัน

แล้วฉันจะทำอะไรที่แตกต่างออกไป? มากมายและฉันเขียนหนังสือเกี่ยวกับเรื่องนี้ (พิมพ์หมด - ฉันไม่ได้เงินสักบาท แต่คุณยังสามารถรับสำเนาได้) Amazon

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

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

เป็นการยกระดับแนวคิดของภาษาเฉพาะโดเมน (DSL) เห็นด้วยอย่างชัดเจนกับดราย (อย่าพูดซ้ำตัวเอง) ยกนิ้วให้กับการสร้างรหัส ส่งผลให้ซอฟต์แวร์มีโครงสร้างข้อมูลจำนวนมากน้อยกว่าปกติสำหรับแอปพลิเคชันสมัยใหม่

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

จัดการ (และ WinAPI ที่เหลือ) คือ OOP!

พวกเขาเป็นอย่างไร พวกเขาไม่สามารถสืบทอดได้พวกเขาไม่สามารถทดแทนได้อย่างแน่นอนพวกเขาขาดคลาสที่กำหนดไว้อย่างดี ... ฉันคิดว่าพวกเขาขาด "OOP" ไปไกล

คุณเคยสร้างหน้าต่างโดยใช้ WinAPI หรือไม่? จากนั้นคุณควรรู้ว่าคุณกำหนดคลาส ( RegisterClass) สร้างอินสแตนซ์ของมัน ( CreateWindow) เรียกใช้เมธอดเสมือน ( WndProc) และเมธอดเบสคลาส ( DefWindowProc) เป็นต้น WinAPI ยังใช้ระบบการตั้งชื่อจาก SmallTalk OOP โดยเรียกวิธีการว่า "ข้อความ" (Window Messages)

แฮนเดิลอาจไม่สามารถสืบทอดได้ แต่มีfinalใน Java พวกเขาไม่ได้ขาดระดับที่พวกเขามีตัวยึดสำหรับชั้นเรียน: นั่นคือสิ่งที่คำว่า“จับ” หมายถึง เมื่อดูที่สถาปัตยกรรมเช่น MFC หรือ. NET WinForms จะเห็นได้ชัดทันทีว่ายกเว้นไวยากรณ์ไม่มีอะไรแตกต่างจาก WinAPI มากนัก

ใช่ OOP ไม่สามารถแก้ปัญหาของเราได้ทั้งหมดขออภัยด้วย อย่างไรก็ตามเรากำลังดำเนินการกับ SOA ซึ่งจะแก้ไขปัญหาเหล่านั้นทั้งหมด

OOP ช่วยให้สามารถเขียนโปรแกรมโครงสร้างคอมพิวเตอร์ภายในเช่น "วิดเจ็ต" GUI ได้โดยที่ตัวอย่างเช่น SelectList และ TextBox อาจเป็นประเภทย่อยของ Item ซึ่งมีวิธีการทั่วไปเช่น "move" และ "resize"

ปัญหาคือ 90% ของเราทำงานในโลกของธุรกิจที่เราทำงานกับแนวคิดทางธุรกิจเช่นใบแจ้งหนี้พนักงานงานการสั่งซื้อ สิ่งเหล่านี้ไม่สามารถให้ OOP ยืมตัวเองได้ดีนักเนื่องจาก "วัตถุ" มีความคลุมเครือมากกว่าอาจมีการเปลี่ยนแปลงได้ตามการปรับโครงสร้างทางธุรกิจเป็นต้น

กรณีที่เลวร้ายที่สุดคือการที่ OO ถูกนำไปใช้กับฐานข้อมูลอย่างกระตือรือร้นรวมถึง "การปรับปรุง" OO ที่ร้ายแรงสำหรับฐานข้อมูล SQL ซึ่งถูกละเว้นอย่างถูกต้องยกเว้นโดย noobs ฐานข้อมูลที่คิดว่าพวกเขาจะต้องเป็นวิธีที่ถูกต้องในการทำสิ่งต่างๆเนื่องจากใหม่กว่า

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

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

อย่างไรก็ตามเมื่อมีการออกแบบ OO ที่ดีมันเป็นเพียงความสุขที่แท้จริงในการอ่านโค้ดและการได้เห็นโค้ดนั้นตกอยู่ในส่วนประกอบ / คลาสที่ใช้งานง่าย ฉันรับรู้สถาปัตยกรรมและการออกแบบระบบมาโดยตลอดเช่นการออกแบบแผนกต่างๆและงานของพนักงานใน บริษัท - ทั้งหมดอยู่ที่นั่นเพื่อทำงานบางส่วนให้สำเร็จในรูปแบบที่ยิ่งใหญ่ของสิ่งต่างๆโดยเปล่งพลังที่จำเป็นในการขับเคลื่อนองค์กร / ระบบไปข้างหน้า

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

บางทีฝากระโปรงตักหรือต้นไม้อาจไม่ใช่เก้าอี้ แต่ทั้งหมดนี้สามารถทำได้

ฉันคิดว่าสิ่งเหล่านั้นในโลกแห่งความเป็นจริงคือวัตถุ

คุณทำ?

ใบแจ้งหนี้มีวิธีการใดบ้าง? โอ้เดี๋ยวก่อน มันจ่ายเองไม่ได้ส่งเองเทียบของที่แม่ค้าส่งจริงไม่ได้ มันไม่มีวิธีการใด ๆ เลย มันเฉื่อยและใช้งานไม่ได้โดยสิ้นเชิง เป็นประเภทระเบียน (โครงสร้างถ้าคุณต้องการ) ไม่ใช่วัตถุ

ในทำนองเดียวกันสิ่งอื่น ๆ ที่คุณพูดถึง

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

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

ฉันคิดว่าจุดที่ OO แยกย่อยคือเมื่อผู้คนสร้างมรดกชั้นสูงที่ซ้อนกันอย่างลึกซึ้ง สิ่งนี้สามารถนำไปสู่ความซับซ้อน อย่างไรก็ตามการแยกความคิดสุดท้ายออกเป็นชั้นพื้นฐานจากนั้นการนำกลับมาใช้ใหม่ในชั้นเรียนอื่น ๆ เป็นสิ่งที่สง่างามอย่างยิ่ง IMHO!

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

ตามที่กล่าวไว้ OO เป็นวิธีที่แตกต่างในการจัดเรียงสิ่งต่าง ๆ โดยแนบรหัสขั้นตอนกับข้อมูลแทนที่จะให้รหัสขั้นตอนดำเนินการกับข้อมูล อย่างน้อยก็ควรจะชนะด้วยตัวมันเองเนื่องจากมีบางกรณีที่แนวทาง OO เป็นธรรมชาติมากกว่า ไม่มีอะไรหยุดยั้งไม่ให้ใครเขียนขั้นตอน API ใน C ++ ได้ดังนั้นตัวเลือกในการให้วัตถุแทนทำให้ภาษามีความหลากหลายมากขึ้น

นอกจากนี้ยังมีบางสิ่งที่ OO ทำได้ดีมาก: ช่วยให้รหัสเก่าสามารถเรียกรหัสใหม่ได้โดยอัตโนมัติโดยไม่มีการเปลี่ยนแปลง หากฉันมีรหัสที่จัดการสิ่งต่าง ๆ ตามขั้นตอนและฉันเพิ่มประเภทของสิ่งใหม่ที่คล้ายกัน แต่ไม่เหมือนกับรหัสก่อนหน้าฉันต้องเปลี่ยนรหัสขั้นตอน ในระบบ OO ฉันสืบทอดฟังก์ชันเปลี่ยนแปลงสิ่งที่ฉันชอบและรหัสใหม่จะถูกใช้โดยอัตโนมัติเนื่องจากความหลากหลาย สิ่งนี้จะเพิ่มการเปลี่ยนแปลงในท้องถิ่นและนั่นเป็นสิ่งที่ดี

ข้อเสียคือ OO ที่ดีไม่ได้ฟรีต้องใช้เวลาและความพยายามในการเรียนรู้อย่างถูกต้อง เนื่องจากเป็นคำศัพท์ที่สำคัญจึงมีผู้คนและผลิตภัณฑ์จำนวนมากที่ทำไม่ดีเพียงเพื่อประโยชน์ในการทำ การออกแบบอินเทอร์เฟซคลาสที่ดีไม่ใช่เรื่องง่ายไปกว่า API ขั้นตอนที่ดีและมีข้อผิดพลาดที่ง่ายต่อการสร้างทุกประเภท (เช่นลำดับชั้นระดับลึก)

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

@Sean

อย่างไรก็ตามการแยกความคิดสุดท้ายออกเป็นชั้นพื้นฐานจากนั้นการนำกลับมาใช้ใหม่ในชั้นเรียนอื่น ๆ เป็นสิ่งที่สง่างามอย่างยิ่ง IMHO!

แต่นักพัฒนา "ขั้นตอน" ก็ทำเช่นนั้นมานานหลายทศวรรษแล้ว ไวยากรณ์และคำศัพท์อาจแตกต่างกัน แต่ผลกระทบจะเหมือนกัน OOP มีอะไรมากกว่า "การนำฟังก์ชันทั่วไปมาใช้ซ้ำในคลาสพื้นฐาน" และฉันอาจจะบอกได้ว่านั่นยากที่จะอธิบายว่าเป็น OOP เลยก็ได้ การเรียกใช้ฟังก์ชันเดียวกันจากรหัสที่ต่างกันเป็นเทคนิคที่เก่าพอ ๆ กับขั้นตอนย่อยเอง

@Konrad

OOP อาจมีข้อบกพร่องและแน่นอนว่าไม่ใช่กระสุนเงิน แต่ทำให้การใช้งานขนาดใหญ่ง่ายขึ้นมากเพราะเป็นวิธีที่ดีในการลดการพึ่งพา

นั่นคือความเชื่อ ฉันไม่เห็นว่าอะไรทำให้ OOP ดีขึ้นอย่างมีนัยสำคัญในเรื่องนี้ไปกว่าการเขียนโปรแกรมขั้นตอนแบบเก่า เมื่อใดก็ตามที่ฉันทำตามขั้นตอนฉันกำลังแยกตัวเองออกจากลักษณะเฉพาะของการนำไปใช้งาน

สำหรับฉันแล้วมีค่ามากมายในไวยากรณ์ OOP เอง การใช้ออบเจ็กต์ที่พยายามเป็นตัวแทนของจริงหรือโครงสร้างข้อมูลมักมีประโยชน์มากกว่าการพยายามใช้ฟังก์ชันแบบแบน (หรือ "ลอย") ที่แตกต่างกันเพื่อทำสิ่งเดียวกันกับข้อมูลเดียวกัน มี "การไหล" อย่างเป็นธรรมชาติกับสิ่งต่างๆด้วย OOP ที่ดีที่ทำให้อ่านเขียนและดูแลรักษาในระยะยาวได้ดีกว่า

ไม่จำเป็นว่าใบแจ้งหนี้จะไม่ใช่ "ออบเจ็กต์" จริงๆที่มีฟังก์ชันที่สามารถดำเนินการได้เองอินสแตนซ์ออบเจ็กต์สามารถมีอยู่เพื่อทำหน้าที่กับข้อมูลโดยไม่ต้องรู้ว่ามีข้อมูลประเภทใดอยู่จริง ฟังก์ชัน "invoice.toJson ()" สามารถเรียกได้สำเร็จโดยไม่ต้องรู้ว่า "ใบแจ้งหนี้" คือข้อมูลประเภทใด - ผลลัพธ์จะเป็น Json ไม่ว่าจะมาจากฐานข้อมูล XML CSV หรือแม้แต่ออบเจ็กต์ JSON อื่นก็ตาม . ด้วยฟังก์ชันขั้นตอนคุณจะต้องรู้ข้อมูลของคุณมากขึ้นในทันทีและท้ายที่สุดด้วยฟังก์ชันเช่น "xmlToJson ()", "csvToJson ()", "dbToJson ()" ฯลฯ ในที่สุดมันก็กลายเป็นความยุ่งเหยิงโดยสมบูรณ์และ ปวดหัวอย่างมากหากคุณเคยเปลี่ยนประเภทข้อมูลพื้นฐาน

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

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

@CodingTheWheel

แต่ในกรณีที่ OOP เสียเวลาฉันจะบอกว่าเป็นเพราะขาดการฝึกอบรมโปรแกรมเมอร์ประกอบกับช่วงการเรียนรู้ที่สูงชันของการเรียนรู้การทำแผนที่ OOP เฉพาะภาษา บางคน "ได้รับ" OOP และคนอื่น ๆ จะไม่ทำ

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

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

@ Jeff

เมื่อเทียบกับการเขียนโปรแกรมขั้นตอนตรงหลักการพื้นฐานแรกของ OOP คือแนวคิดของการซ่อนข้อมูลและการห่อหุ้ม แนวคิดนี้นำไปสู่แนวคิดของคลาสที่แยกส่วนต่อประสานออกจากการนำไปใช้งาน

ซึ่งมีการใช้งานที่ซ่อนอยู่มากกว่า: iostreams ของ C ++ หรือ FILE * s ของ C?

ฉันคิดว่าการใช้อ็อบเจ็กต์บริบททึบแสง (HANDLEs ใน Win32, FILE * s ใน C เพื่อตั้งชื่อสองตัวอย่างที่รู้จักกันดี - hell, HANDLEs อาศัยอยู่อีกด้านหนึ่งของอุปสรรคโหมดเคอร์เนลและมันไม่ได้รับ มีการห่อหุ้มมากกว่านั้นมาก) พบได้ในรหัสขั้นตอนด้วยเช่นกัน ฉันกำลังดิ้นรนเพื่อดูว่านี่เป็นสิ่งเฉพาะสำหรับ OOP อย่างไร

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

ในบล็อก dev เดียวที่ฉันอ่านโดย Joel-On-Software-Founder-of-SO คนนั้นฉันอ่านมานานแล้วว่า OO ไม่ได้นำไปสู่การเพิ่มผลผลิต การจัดการหน่วยความจำอัตโนมัติทำได้ เย็น. ใครสามารถปฏิเสธข้อมูลได้

ฉันยังเชื่อว่า OO นั้นไม่ใช่ OO การเขียนโปรแกรมด้วยฟังก์ชันคือการเขียนโปรแกรมทุกอย่างแบบอินไลน์

(และฉันควรรู้เมื่อฉันเริ่มต้นด้วย GWBasic) เมื่อคุณ refactor โค้ดเพื่อใช้ฟังก์ชันvariable2654จะกลายเป็นvariable3เมธอดที่คุณใช้อยู่หรือยังดีกว่ามันมีชื่อที่คุณสามารถเข้าใจได้และถ้าฟังก์ชันนั้นสั้น ,ก็เรียกว่าvalue และที่เพียงพอสำหรับความเข้าใจอย่างเต็มรูปแบบ

เมื่อรหัสที่ไม่มีฟังก์ชันกลายเป็นรหัสด้วยวิธีการคุณจะสามารถลบรหัสได้

เมื่อคุณ refactor รหัสอย่างแท้จริง OO, b, c, qและZกลายเป็นthis, this, และthis thisและเนื่องจากฉันไม่เชื่อในการใช้thisคีย์เวิร์ดคุณจึงต้องลบไมล์ของรหัส thisที่จริงคุณจะได้รับที่จะทำแม้ว่าคุณจะใช้

ฉันไม่คิดว่า OO เป็นอุปมาตามธรรมชาติ

ฉันไม่คิดว่าภาษาเป็นคำอุปมาตามธรรมชาติเช่นกันและฉันคิดว่า "กลิ่น" ของฟาวเลอร์ดีกว่าการพูดว่า "รหัสนี้มีรสชาติไม่ดี" ที่กล่าวว่าฉันคิดว่า OO ไม่ได้เกี่ยวกับการเปรียบเปรยตามธรรมชาติและคนที่คิดว่าวัตถุเพิ่งโผล่มาที่คุณนั้นโดยพื้นฐานแล้วไม่มีประเด็น คุณกำหนดจักรวาลวัตถุและจักรวาลของวัตถุที่ดีกว่าส่งผลให้โค้ดสั้นลงเข้าใจง่ายทำงานได้ดีขึ้นหรือทั้งหมดนี้ (และเกณฑ์บางอย่างที่ฉันลืม) ฉันคิดว่าคนที่ใช้วัตถุธรรมชาติของลูกค้า / โดเมนเป็นวัตถุในการเขียนโปรแกรมกำลังขาดพลังในการกำหนดจักรวาลใหม่

ตัวอย่างเช่นเมื่อคุณทำระบบการจองสายการบินสิ่งที่คุณเรียกว่าการจองอาจไม่ตรงกับการจองทางกฎหมาย / ธุรกิจเลย

แนวคิดพื้นฐานบางอย่างเป็นเครื่องมือที่ยอดเยี่ยมจริงๆ

ฉันคิดว่าคนส่วนใหญ่พูดเกินจริงกับสิ่งนั้น "เมื่อคุณมีค้อนพวกเขาก็เป็นตะปูทั้งหมด" ฉันคิดว่าอีกด้านหนึ่งของเหรียญ / กระจกก็เหมือนจริง: เมื่อคุณมีแกดเจ็ตเช่นความหลากหลาย / การถ่ายทอดทางพันธุกรรมคุณจะเริ่มพบการใช้งานที่เหมาะกับเช่นถุงมือ / ถุงเท้า / คอนแทคเลนส์ เครื่องมือของ OO มีประสิทธิภาพมาก ฉันคิดว่าการสืบทอดครั้งเดียวเป็นสิ่งจำเป็นอย่างยิ่งสำหรับคนที่จะไม่ถูกพาไปซอฟต์แวร์มรดกหลายรายการของฉันเองที่ไม่สามารถทนได้

OOP คืออะไร?

ฉันคิดว่ามันเป็นวิธีที่ยอดเยี่ยมในการจัดการฐานรหัสขนาดใหญ่อย่างแน่นอน ฉันคิดว่ามันช่วยให้คุณจัดระเบียบและจัดระเบียบโค้ดของคุณใหม่และให้ภาษาสำหรับทำสิ่งนั้น (นอกเหนือจากภาษาโปรแกรมที่คุณใช้งานอยู่) และโมดูลาร์โค้ดด้วยวิธีที่เป็นธรรมชาติและเข้าใจง่าย

OOP ถูกกำหนดให้เกิดความเข้าใจผิดโดยนักพัฒนาซอฟต์แวร์ส่วนใหญ่

นี่เป็นเพราะมันเป็นกระบวนการเปิดหูเปิดตาเหมือนชีวิต: คุณเข้าใจ OO มากขึ้นเรื่อย ๆ ด้วยประสบการณ์และเริ่มหลีกเลี่ยงรูปแบบบางอย่างและจ้างคนอื่นเมื่อคุณฉลาดขึ้น หนึ่งในตัวอย่างที่ดีที่สุดคือคุณหยุดใช้การสืบทอดสำหรับคลาสที่คุณไม่ได้ควบคุมและเลือกใช้รูปแบบFacadeแทน

เกี่ยวกับมินิเรียงความ / คำถามของคุณ

ฉันอยากจะบอกว่าคุณพูดถูก การนำกลับมาใช้ใหม่เป็นความฝันส่วนใหญ่ นี่คือคำพูดจาก Anders Hejilsberg เกี่ยวกับหัวข้อนั้น (ยอดเยี่ยม) จากที่นี่ :

หากคุณขอให้โปรแกรมเมอร์เริ่มต้นเขียนการควบคุมปฏิทินพวกเขามักจะคิดกับตัวเองว่า "โอ้ฉันจะเขียนตัวควบคุมปฏิทินที่ดีที่สุดในโลก! มันจะเป็นแบบหลายรูปแบบเมื่อเทียบกับประเภทของปฏิทินมันจะมีผู้แสดงผล และแมงกะพรุนและนี่นั่นและอื่น ๆ " พวกเขาต้องจัดส่งแอปพลิเคชันปฏิทินภายในสองเดือน พวกเขาวางโครงสร้างพื้นฐานทั้งหมดนี้ไว้ในการควบคุมจากนั้นใช้เวลาสองวันในการเขียนแอปพลิเคชันปฏิทินเส็งเคร็งไว้ด้านบน พวกเขาจะคิดว่า "ในแอปพลิเคชันเวอร์ชันถัดไปฉันจะทำมากกว่านี้"

เมื่อพวกเขาเริ่มคิดว่าพวกเขาจะนำการออกแบบเชิงนามธรรมอื่น ๆ ทั้งหมดไปใช้อย่างไรปรากฎว่าการออกแบบของพวกเขาผิดอย่างสิ้นเชิง และตอนนี้พวกเขาวาดภาพตัวเองจนเข้ามุมแล้วพวกเขาก็ต้องโยนของทั้งหมดออกไป ฉันได้เห็นสิ่งนั้นซ้ำแล้วซ้ำเล่า ฉันเชื่อมั่นในความเรียบง่าย เว้นแต่คุณจะแก้ปัญหาทั่วไปจริง ๆ อย่าพยายามวางกรอบสำหรับการแก้ปัญหาเฉพาะเพราะคุณไม่รู้ว่ากรอบงานนั้นควรมีลักษณะอย่างไร

คุณเคยสร้างหน้าต่างโดยใช้ WinAPI หรือไม่?

หลายครั้งมากกว่าที่ฉันสนใจที่จะจำ

จากนั้นคุณควรทราบว่าคุณกำหนดคลาส (RegisterClass) สร้างอินสแตนซ์ของมัน (CreateWindow) เรียกวิธีการเสมือน (WndProc) และเมธอดเบสคลาส (DefWindowProc) เป็นต้น WinAPI ยังใช้ระบบการตั้งชื่อจาก SmallTalk OOP โดยเรียกวิธีการว่า "ข้อความ" (Window Messages)

แล้วคุณจะรู้ด้วยว่ามันไม่มีการส่งข้อความของตัวเองซึ่งเป็นความว่างเปล่าที่ยิ่งใหญ่ นอกจากนี้ยังมี subclassing เส็งเคร็ง

แฮนเดิลอาจไม่สามารถสืบทอดได้ แต่สุดท้ายก็มีใน Java พวกเขาไม่ได้ขาดชั้นเรียน แต่เป็นตัวยึดสำหรับชั้นเรียนนั่นคือสิ่งที่คำว่า "จัดการ" หมายถึง เมื่อดูที่สถาปัตยกรรมเช่น MFC หรือ. NET WinForms จะเห็นได้ชัดทันทีว่ายกเว้นไวยากรณ์ไม่มีอะไรแตกต่างจาก WinAPI มากนัก

ไม่สามารถสืบทอดได้ทั้งในอินเทอร์เฟซหรือการนำไปใช้งานทดแทนได้น้อยที่สุดและไม่แตกต่างอย่างมีนัยสำคัญจากสิ่งที่ coders ขั้นตอนดำเนินการมาตลอด

นี่มันจริงๆเหรอ? บิตที่ดีที่สุดของ OOP เป็นเพียง ... รหัสขั้นตอนดั้งเดิม? นั่นคือเรื่องใหญ่?

ฉันเห็นด้วยอย่างสมบูรณ์กับคำตอบของInSciTek Jeffฉันจะเพิ่มการปรับแต่งต่อไปนี้:

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

การใช้คุณสมบัติ OO (ลำดับชั้นนามธรรมที่ซ้อนกันโดยเฉพาะอย่างยิ่ง) เมื่อไม่มีประเด็นก็ไม่มีจุดหมาย แต่สำหรับโดเมนแอปพลิเคชันบางโดเมนมีประเด็น

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

เพียงเพราะคุณสามารถสร้างบางสิ่งให้เป็นวัตถุไม่ได้หมายความว่าคุณควร อย่างไรก็ตามหากการทำเช่นนั้นจะทำให้โค้ดของคุณเป็นระเบียบมากขึ้น / อ่านง่ายขึ้นคุณควรทำอย่างแน่นอน

ตัวอย่างที่ใช้ได้จริงซึ่ง OOP มีประโยชน์มากคือคลาส "ผลิตภัณฑ์" และออบเจ็กต์ที่ฉันใช้บนเว็บไซต์ของเรา เนื่องจากทุกหน้าเป็นผลิตภัณฑ์และทุกผลิตภัณฑ์มีการอ้างอิงถึงผลิตภัณฑ์อื่น ๆ จึงอาจสร้างความสับสนอย่างมากว่าข้อมูลที่คุณอ้างถึงผลิตภัณฑ์ใด ตัวแปร "strURL" นี้เป็นลิงก์ไปยังหน้าปัจจุบันหรือไปที่หน้าแรกหรือไปยังหน้าสถิติหรือไม่ แน่นอนว่าคุณสามารถสร้างตัวแปรที่แตกต่างกันได้ทุกประเภทที่อ้างถึงข้อมูลเดียวกัน แต่ proCurrentPage-> strURL นั้นเข้าใจง่ายกว่ามาก (สำหรับนักพัฒนา)

นอกจากนี้การแนบฟังก์ชั่นเข้ากับหน้าเหล่านั้นจะสะอาดกว่ามาก ฉันสามารถทำ proCurrentPage-> CleanCache (); ตามด้วย proDisplayItem-> RenderPromo (); ถ้าฉันเพิ่งเรียกใช้ฟังก์ชันเหล่านั้นและสมมติว่ามีข้อมูลปัจจุบันใครจะรู้ว่าจะเกิดความชั่วร้ายแบบไหน นอกจากนี้หากฉันต้องส่งผ่านตัวแปรที่ถูกต้องไปยังฟังก์ชันเหล่านั้นฉันกลับไปที่ปัญหาในการมีตัวแปรทุกชนิดสำหรับผลิตภัณฑ์ต่างๆที่วางอยู่รอบ ๆ

การใช้ออบเจ็กต์ข้อมูลและฟังก์ชันทั้งหมดของผลิตภัณฑ์ของฉันดีและสะอาดและเข้าใจง่าย

อย่างไรก็ตาม ปัญหาใหญ่ของ OOP คือเมื่อมีคนเชื่อว่า EVERYTHING ควรเป็น OOP สิ่งนี้สร้างปัญหามาก ฉันมี 88 ตารางในฐานข้อมูลของฉัน ฉันมีคลาสแค่ 6 คลาสและบางทีฉันควรจะมีประมาณ 10 คลาสฉันไม่จำเป็นต้องมี 88 คลาส เวลาส่วนใหญ่ในการเข้าถึงตารางเหล่านั้นโดยตรงสามารถเข้าใจได้อย่างสมบูรณ์ในสถานการณ์ที่ฉันใช้และ OOP จะทำให้การทำงานหลักของสิ่งที่เกิดขึ้นเป็นเรื่องยาก / น่าเบื่อมากขึ้น

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

ฉันไม่สนใจการใช้ซ้ำมากเท่าที่ฉันทำเพื่อให้อ่านง่าย ประการหลังหมายความว่ารหัสของคุณเปลี่ยนได้ง่ายกว่า สิ่งนี้มีค่าเพียงอย่างเดียวในการสร้างซอฟต์แวร์

และ OO เป็นวิธีที่มีประสิทธิภาพในการทำให้โปรแกรมของคุณอ่านง่าย ใช้ซ้ำหรือไม่ใช้ซ้ำ

"โลกแห่งความจริงไม่ใช่" OO ","

จริงๆ? โลกของฉันเต็มไปด้วยวัตถุ ตอนนี้ฉันใช้อยู่ ฉันคิดว่าการมีซอฟต์แวร์ "วัตถุ" จำลองวัตถุจริงอาจไม่ใช่เรื่องเลวร้าย

การออกแบบ OO สำหรับสิ่งที่เป็นแนวคิด (เช่น Windows ไม่ใช่หน้าต่างโลกแห่งความจริง แต่เป็นแผงแสดงผลบนหน้าจอคอมพิวเตอร์ของฉัน) มักจะเป็นที่ต้องการมากมาย แต่สำหรับสิ่งต่างๆในโลกแห่งความเป็นจริงเช่นใบแจ้งหนี้ใบสั่งส่งสินค้าการเคลมประกันและสิ่งที่ไม่ใช่ฉันคิดว่าสิ่งต่างๆในโลกแห่งความเป็นจริงเป็นวัตถุ ฉันมีกองอยู่บนโต๊ะทำงานดังนั้นมันต้องเป็นของจริง

จุดประสงค์ของ OOP คือการให้โปรแกรมเมอร์อีกวิธีหนึ่งในการอธิบายและสื่อสารวิธีแก้ปัญหาในรหัสไปยังเครื่องและผู้คน ส่วนที่สำคัญที่สุดคือการสื่อสารกับผู้คน OOP อนุญาตให้โปรแกรมเมอร์ประกาศความหมายของโค้ดผ่านกฎที่บังคับใช้ในภาษา OO

ตรงกันข้ามกับข้อโต้แย้งมากมายในหัวข้อนี้แนวคิด OOP และ OO นั้นแพร่หลายไปทั่วทุกโค้ดรวมถึงโค้ดในภาษาที่ไม่ใช่ OOP เช่น C โปรแกรมเมอร์ขั้นสูงที่ไม่ใช่ OO จำนวนมากจะประมาณคุณสมบัติของอ็อบเจ็กต์แม้ในภาษาที่ไม่ใช่ OO

การมี OO ในภาษาเป็นเพียงการให้โปรแกรมเมอร์อีกวิธีหนึ่งในการแสดงออก

ส่วนที่ใหญ่ที่สุดในการเขียนโค้ดไม่ใช่การสื่อสารกับเครื่องส่วนนั้นเป็นเรื่องง่ายส่วนที่ใหญ่ที่สุดคือการสื่อสารกับโปรแกรมเมอร์ที่เป็นมนุษย์