OOP ยากหรือไม่เพราะไม่ใช่ธรรมชาติ?

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

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

เราคิดในแง่ของ bivalent (บางครั้ง trivalent เช่นใน "ฉันให้คุณดอกไม้") คำกริยาที่กริยาคือการกระทำ (ความสัมพันธ์) ที่ทำงานบนวัตถุสองชิ้นเพื่อสร้างผลลัพธ์ / การกระทำบางอย่าง โฟกัสอยู่ในการดำเนินการและทั้งสอง (หรือสาม) [ไวยากรณ์] วัตถุมีความสำคัญเท่าเทียมกัน

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

ไม่เพียง แต่การโฟกัสจะเปลี่ยนเป็นคำนาม แต่หนึ่งในคำนาม (เรียกว่าเป็นเรื่องไวยากรณ์) จะได้รับ "ความสำคัญ" ที่สูงกว่าอีกอันหนึ่ง (วัตถุไวยากรณ์) ดังนั้นหนึ่งจะต้องตัดสินใจว่าจะพูด terminalWindow.show (someText) หรือ someText.show (terminalWindow) แต่ทำไมผู้คนถึงต้องตัดสินใจเรื่องเล็ก ๆ น้อย ๆ เช่นนี้โดยไม่มีผลการดำเนินงานเมื่อผู้คนหมายถึงการแสดงจริงๆ (terminalWindow, someText) [ผลที่ตามมานั้นไม่มีนัยสำคัญในการใช้งาน - ในทั้งสองกรณีข้อความจะปรากฏบนหน้าต่างเทอร์มินัล - แต่อาจมีความร้ายแรงมากในการออกแบบลำดับชั้นของชั้นเรียนและตัวเลือก "ผิด" สามารถนำไปสู่การสับสน

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

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

OOP ผิดธรรมชาติสำหรับปัญหาบางอย่าง ดังนั้นขั้นตอนของ ฟังก์ชั่นดังนั้น ฉันคิดว่า OOP มีปัญหาสองอย่างที่ทำให้ดูเหมือนยากจริงๆ

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

   โดยทั่วไปแล้ว OO นั้นดีที่สุดเมื่อคุณมีพฤติกรรมที่เชื่อมโยงกับสถานะที่พวกเขาดำเนินการอยู่และลักษณะที่แน่นอนของรัฐคือรายละเอียดการนำไปใช้ แต่การดำรงอยู่ของมันจะไม่สามารถถูกแยกออก ตัวอย่าง: คลาส Collections

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

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

2. โดยทั่วไปแล้ว OOP จะแสดงประโยชน์ในโครงการขนาดใหญ่ที่จำเป็นต้องมีรหัสที่ห่อหุ้มอย่างดี สิ่งนี้ไม่ได้เกิดขึ้นมากในโครงการเริ่มต้น

IMHO มันเป็นคำถามของรสนิยมส่วนตัวและวิธีคิด ฉันไม่ได้มีปัญหามากกับ OO

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

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

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

หากมีความสัมพันธ์ระหว่างวัตถุก็จะเกี่ยวข้องตามนิยาม ใน OO คุณสามารถแสดงมันด้วยการเชื่อมโยง / การรวม / การพึ่งพาการใช้งานระหว่างสองคลาส

เราคิดในแง่ของ bivalent (บางครั้ง trivalent เช่นใน "ฉันให้คุณดอกไม้") คำกริยาที่กริยาคือการกระทำ (ความสัมพันธ์) ที่ทำงานบนวัตถุสองชิ้นเพื่อสร้างผลลัพธ์ / การกระทำบางอย่าง โฟกัสอยู่ที่การดำเนินการและวัตถุทั้งสอง (หรือสาม) [ไวยากรณ์] มีความสำคัญเท่ากัน

แต่พวกเขายังคงมีบทบาทที่ชัดเจนในบริบท: หัวเรื่อง, วัตถุ, แอ็คชั่น ฯลฯ "ฉันมอบดอกไม้ให้คุณ" หรือ "คุณมอบดอกไม้ให้ฉัน" ไม่เหมือนกัน (ไม่ต้องพูดถึง "ดอกไม้มอบให้ฉัน": -)

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

ฉันไม่เห็นด้วยกับสิ่งนี้ IMHO ประโยคภาษาอังกฤษ "บิลไปนรก" อ่านมากขึ้นตามธรรมชาติในรหัสโปรแกรมเป็นมากกว่าbill.moveTo(hell) move(bill, hell)และที่จริงแล้วในความเป็นจริงจะคล้ายกับเสียงที่ใช้งานอยู่เดิมมากขึ้น

ดังนั้นหนึ่งจะต้องตัดสินใจว่าจะบอกว่า terminalWindow.show (someText) หรือ someText.show (terminalWindow)

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

เมื่อพิจารณาถึงปัญหาเหล่านี้มันเกิดขึ้นได้อย่างไรว่าวิธีการหลักในการทำ OOP ที่เป็นที่นิยมในปัจจุบันเป็นอย่างไร?

อาจเป็นเพราะนักพัฒนา OO ส่วนใหญ่เห็น OO ต่างจากคุณหรือไม่?

โปรแกรมเมอร์บางคนพบว่า OOD ยากเพราะโปรแกรมเมอร์เหล่านั้นชอบคิดเกี่ยวกับวิธีการแก้ปัญหาสำหรับคอมพิวเตอร์ไม่ใช่เกี่ยวกับวิธีการแก้ไขปัญหา

... แต่จุดเน้นของ OOP คือการออกแบบแต่ละคลาสและลำดับชั้น

OOD ไม่เกี่ยวกับเรื่องนั้น OOD นั้นเกี่ยวกับการหาวิธีที่สิ่งต่าง ๆ ทำงานและโต้ตอบกัน

เราคิดในแง่ของ bivalent (บางครั้ง trivalent เช่นใน "ฉันให้คุณดอกไม้") คำกริยาที่กริยาคือการกระทำ (ความสัมพันธ์) ที่ทำงานบนวัตถุสองชิ้นเพื่อสร้างผลลัพธ์ / การกระทำบางอย่าง โฟกัสอยู่ที่การดำเนินการและวัตถุทั้งสอง (หรือสาม) [ไวยากรณ์] มีความสำคัญเท่ากัน

การมุ่งเน้นไปที่ OOD นั้นเป็นการกระทำเสมอโดยที่การกระทำนั้นเป็นพฤติกรรมของวัตถุ วัตถุไม่มีอะไรเลยหากไม่มีพฤติกรรม ข้อ จำกัด เฉพาะวัตถุของ OOD คือทุกสิ่งต้องทำโดยบางสิ่ง

ฉันไม่เห็นผู้กระทำมีความสำคัญมากกว่าสิ่งที่ทำไปแล้ว

แต่ทำไมผู้คนถึงต้องตัดสินใจเรื่องเล็ก ๆ น้อย ๆ เช่นนี้โดยไม่มีผลการดำเนินงานเมื่อผู้คนหมายถึงการแสดงจริงๆ (terminalWindow, someText)

สำหรับฉันนั่นคือสิ่งเดียวกันกับสัญกรณ์ที่แตกต่างกัน คุณยังต้องตัดสินใจว่าใครเป็นผู้แสดงและใครเป็นคนแสดง เมื่อคุณรู้แล้วไม่มีการตัดสินใจใน OOD Windows แสดงข้อความ -> หน้าต่างแสดง (ข้อความ)

มีสิ่งต่าง ๆ มากมายออกมา (โดยเฉพาะในพื้นที่ดั้งเดิม) บอกว่ามันเป็น OO เมื่อมันไม่ใช่ ตัวอย่างเช่นมีรหัส C ++ จำนวนมากที่ไม่ใช้รูปที่ของ OOD

OOD นั้นง่ายเมื่อคุณแยกความคิดว่าคุณกำลังแก้ไขปัญหาสำหรับคอมพิวเตอร์ คุณกำลังแก้ปัญหาสำหรับสิ่งที่ทำ

บางทีฉันไม่สามารถได้คะแนน แต่:

การอ่านหนังสือเล่มแรกเกี่ยวกับ OOP (ช่วงต้น 90s, คู่มือบางอย่างของบอร์แลนด์ถึง Pascal) ฉันรู้สึกทึ่งกับความเรียบง่ายและศักยภาพของมัน (ก่อนหน้านี้ฉันเคยใช้ Cobol, Fortran, ภาษาแอสเซมบลีและเนื้อหาก่อนประวัติศาสตร์อื่น ๆ )

สำหรับฉันมันค่อนข้างชัดเจน: สุนัขเป็นสัตว์สัตว์ต้องกินสุนัขของฉันเป็นสุนัขดังนั้นต้องกิน ...

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

ฉันยอมรับว่าบางส่วนของโครงสร้างในภาษา OO สมัยใหม่ค่อนข้างอึดอัดเล็กน้อย แต่มันเป็นวิวัฒนาการ

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

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

ฉันยังคงประหลาดใจกับความยากลำบากอันยิ่งใหญ่ที่หลักฐานเท็จนี้มอบให้ฉัน

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

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

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

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

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

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

นี่เป็นเพียงส่วนหนึ่งของสิ่งที่ผิดปกติกับ OOP

โดยพื้นฐานแล้วฟังก์ชั่นกลายเป็นพลเมืองชั้นสองและสิ่งนี้ไม่ดี

ภาษาสมัยใหม่ (ruby / python) ไม่ประสบปัญหานี้และมีหน้าที่เป็นวัตถุชั้นหนึ่งรวมถึงให้คุณสร้างโปรแกรมโดยไม่ต้องสร้างลำดับชั้นของชั้นเรียน

OOP ไม่ยาก สิ่งที่ทำให้ยากต่อการใช้งานเป็นอย่างดีคือความเข้าใจตื้น ๆ เกี่ยวกับสิ่งที่ดีสำหรับที่โปรแกรมเมอร์ได้ยิน maxims สุ่มและทำซ้ำพวกเขาเองภายใต้ลมหายใจของพวกเขาเพื่อรับพรจาก Gang of Four อันศักดิ์สิทธิ์ Martin Fowler ที่มีความสุขหรือ ใครก็ตามที่พวกเขาอ่าน

แก้ไข

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

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

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

ฉันได้ทำงานกับภาษา OOP เป็นหลัก (C ++, Java) แต่ฉันมักจะรู้สึกว่าฉันสามารถใช้ Pascal หรือ Ada ได้อย่างมีประสิทธิภาพแม้ว่าฉันจะไม่เคยลองใช้มันสำหรับโครงการขนาดใหญ่

เปรียบเทียบกับ OOP ที่คุณต้องค้นหาวัตถุหนึ่ง (คำนาม) ก่อนและบอกให้ดำเนินการบางอย่างกับวัตถุอื่น

[ตัด]

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

เมื่อฉันอ่านย่อหน้าสุดท้ายนี้อย่างรอบคอบยิ่งขึ้นในที่สุดฉันก็เข้าใจประเด็นหลักของคำถามของคุณและฉันต้องเขียนคำตอบใหม่ตั้งแต่ต้น :-)

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

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

หยุดมองหากระบวนทัศน์เฉพาะของ OOP และลองใช้ JavaScript

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

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

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

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

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

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

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

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

มันเป็นวิธีธรรมชาติในการคิดถึงโลกผ่านการจัดหมวดหมู่ นั่นเป็นสิ่งที่ OO คิดไว้ไม่มากก็น้อย OOP นั้นยากเพราะการเขียนโปรแกรมยาก

ฉันคิดว่าความยากลำบากบางอย่างเกิดขึ้นเมื่อผู้คนพยายามใช้ OOP เพื่อเป็นตัวแทนของความเป็นจริง ทุกคนรู้ว่ารถยนต์มีสี่ล้อและเครื่องยนต์ ทุกคนรู้ว่ารถสามารถStart(), และMove()SoundHorn()

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

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

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

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

ไม่ มีหลายวิธีในการแก้ปัญหาการเขียนโปรแกรมโดยใช้: การทำงาน, ขั้นตอน, ตรรกะ, OOP, อื่น ๆ

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

นอกจากนี้ยังมีกระบวนทัศน์ "ทุกอย่างเป็นรายการหรือรายการ" ที่ใช้ใน LISP ผมชอบที่จะพูดถึงเป็นสิ่งที่แตกต่างจากโปรแกรมการทำงาน PHP ใช้ในอาเรย์แบบเชื่อมโยง

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

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

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

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

หากต้องการยกเลิก OO ให้สร้างภาษาที่ทำให้ง่ายต่อการเปลี่ยนจากสิ่งที่โปรแกรมเมอร์ส่วนใหญ่รู้ในวันนี้ (ส่วนใหญ่เป็นขั้นตอนด้วย OO เล็กน้อย) เป็นกระบวนทัศน์ที่คุณต้องการ ตรวจสอบให้แน่ใจว่ามี API ที่สะดวกสบายในการทำงานทั่วไปและส่งเสริมให้ดี ผู้คนจะทำโปรแกรม X-in-name-only ในภาษาของคุณ จากนั้นคุณสามารถคาดหวังว่าจะใช้เวลาเป็นปี ๆ ในการที่คนจะเก่งในการทำ X

ฉันคิดว่าภาษา OOP และ OOP มีปัญหาเช่นกัน

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

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

อีกประเด็นหนึ่งก็คือคอมพิวเตอร์จะดำเนินการตามคำสั่งอย่างต่อเนื่อง สมมติว่าคุณมีVCRและTelevisionวัตถุคุณจะเล่นวิดีโออย่างไร คุณอาจจะเขียนสิ่งนี้:

connect(television, vcr);
vcr.turnOn();
television.turnOn();
insert(vcr, yourFavoriteCasette);
vcr.play();
while (vcr.isPlaying()) {} // Wait while the VCR is playing the casette.
vcr.eject();
vcr.turnOff();
television.turnOff();

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

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

ลองดูที่DCI (ข้อมูลบริบทและการโต้ตอบ) ที่คิดค้นโดยนักประดิษฐ์ของรูปแบบ MVC

เป้าหมายของ DCI คือ (อ้างจาก Wikipedia):

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

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

มักจะได้ยินว่า OOP สอดคล้องกับวิธีที่ผู้คนคิดเกี่ยวกับโลก แต่ฉันจะไม่เห็นด้วยอย่างยิ่งกับคำสั่งนี้ (... )

เมื่อมีการประกาศในหนังสือและที่อื่น ๆ เป็นเวลาหลายทศวรรษฉันก็ไม่เห็นด้วย อย่างไรก็ตามฉันคิดว่า Nygaard และ Dahl เป็นคนที่คิดแบบนั้นและฉันคิดว่าพวกเขามุ่งเน้นไปที่การคิดแบบจำลองได้ง่ายขึ้นเมื่อเทียบกับทางเลือกของเวลา

(... ) แต่จุดเน้นของ OOP คือการออกแบบคลาสของแต่ละบุคคลและลำดับชั้น

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

"ข้อเสนอสำหรับคำจำกัดความที่เรียบง่ายทันสมัย" Object "และ" Object Oriented " http://wcook.blogspot.com.br/2012/07/proposal-for-simplified-modern.html

เมื่อพิจารณาถึงปัญหาเหล่านี้มันเกิดขึ้นได้อย่างไรว่าวิธีการหลักในการทำ OOP ที่เป็นที่นิยมในปัจจุบันเป็นอย่างไร?

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

และถ้ามีอะไรที่สามารถทำได้เพื่อกำจัดมันได้?

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

สุดท้ายแบ่งปันสิ่งที่คุณพบกับเรา

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

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

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

ในทางตรงกันข้ามวัตถุที่แสดงถึงกระบวนการเช่น "เข้ารหัส" หรือ "บีบอัด" หรือ "เรียงลำดับ" ดูเหมือนว่า "คำกริยา"

วัตถุบางอย่างจะใช้สำหรับบทบาทของพวกเขาเป็น namespace เช่นสถานที่ที่จะนำฟังก์ชั่น "คงที่" ใน Java

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

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

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

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

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

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

ควรเป็นข้อกำหนดที่บังคับสำหรับโปรแกรมเมอร์ Object Oriented ทุกคนที่จะรู้วิธีการเขียนแอปพลิเคชันเล่นหมากรุกในแอสเซมเบลอร์สำหรับหน่วยความจำสูงสุด 16K จากนั้นพวกเขาจะเรียนรู้วิธีการตัดแต่งไขมันตัดความเกียจคร้านและสร้างวิธีแก้ปัญหาอันชาญฉลาด