การเขียนโปรแกรมเชิงวัตถุจริง ๆ แบบจำลองโลกแห่งความจริงหรือไม่ [ปิด]

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

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

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

ดังนั้น: การเขียนโปรแกรมเชิงวัตถุจริง ๆ จำลองโลกแห่งความจริง?

ไม่เลย.

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

โมเดลทุกชนิดไม่ได้จำลองโลกแห่งความจริงไม่ใช่ทั้งหมด

พวกเขาเลือกโมเดลบางส่วนซึ่งเกี่ยวข้องกับแอปพลิเคชันในมือ

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

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

การเขียนโปรแกรมเชิงวัตถุช่วยให้คุณจำลองโลกแห่งความจริงได้หรือไม่?

ใช่แน่นอน

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

ฉันจำเป็นต้องสร้างแบบจำลองซอฟต์แวร์หลังจากโลกแห่งความจริงเสมอหรือไม่?

NO

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

มีเอนทิตีของหลักสูตรที่ไม่ได้มีอยู่จริง แต่ผ่านการสร้างแบบจำลองเราสามารถสร้างแนวความคิดที่ดี

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

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

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

... โลกนี้ยิ่งกว่าสิ่งที่จะแสดงออกด้วยไวยากรณ์เชิงวัตถุ

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

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

อ้างแหล่งที่มา: Victoria Livschitz, The Next Move in Programming

ใช่ OO มักจะถูกใช้เพื่อสร้างโมเดลเอนทิตีโลกแห่งความจริง

แม้ในชั้นธุรกิจของฉันฉันมีชั้นเรียนเช่นผู้สังเกตการณ์ผู้จัดการโรงงาน ฯลฯ ซึ่งไม่ใช่วัตถุในโลกแห่งความเป็นจริง

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

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

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

นั่นไม่ได้หมายความว่า OO จะต้องจำลองโลกแห่งความเป็นจริงและไม่เป็นทางออกที่ดีที่สุดเสมอไป เพียงแค่ว่าเป็นกฎง่ายๆ“ OO การสร้างแบบจำลองโลกแห่งความจริง” ทำให้รู้สึกที่สมบูรณ์แบบ

ขึ้นอยู่กับโลกแห่งความจริงที่คุณกำลังพูดถึง

Jorge Luis Borges เขียนเรื่องราว "Tlön, Uqbar, Orbis Tertius" ซึ่งผู้อยู่อาศัยคนหนึ่งดูเหมือนจะรับรู้โลกที่แท้จริงของพวกเขาแตกต่างกัน:

[... ] ผู้คนในTlönจำนวนจินตภาพ [... ] ถือรูปแบบที่สุดขั้วของอุดมคติในอุดมคติของ Berkeleian ปฏิเสธความเป็นจริงของโลก โลกของพวกเขานั้นเป็นที่เข้าใจกันว่า "ไม่เหมือนกับการตกลงกันของวัตถุในอวกาศ แต่เป็นชุดการกระทำอิสระที่แตกต่างกัน" หนึ่งในภาษาจินตนาการของTlönขาดคำนาม มันคือหน่วยกลาง "คำกริยาที่ไม่มีตัวตนมีคุณสมบัติตามคำต่อท้ายพยางค์เดียวหรือคำนำหน้าซึ่งมีพลังของคำวิเศษณ์" Borges แสดงรายการเทียบเท่าTlönicของ "ดวงจันทร์ขึ้นเหนือน้ำ": hlör u fang axaxaxas mlö, ความหมายตามตัวอักษร "ขึ้นด้านหลังกระแสน้ำบนดวงจันทร์" [... ] ในภาษาอื่นของTlön "หน่วยพื้นฐานไม่ใช่คำกริยา แต่เป็นคำคุณศัพท์ monosyllabic" ซึ่งในการรวมกันของสองคนหรือมากกว่าเป็นคำนามรูป: "ดวงจันทร์" กลายเป็น "รอบโปร่งแสงบน มืด "หรือ"

(คัดลอกมาจากบทความเกี่ยวกับวิกิพีเดีย )

สำหรับฉันแล้วประเด็นไม่มากนักที่โลกสามารถรับรู้ได้แตกต่างจากที่เราทำซึ่งเป็นความคิดโบราณ แต่การรับรู้โครงสร้างของความเป็นจริงนั้นขึ้นอยู่กับภาษาที่เราพูดไม่ว่าจะเป็นภาษาธรรมชาติหรือภาษาโปรแกรม Tlöneseอาจมีความสุขมากกับ Lisp และอาจเห็น Java (AKA The Kingdom Of Nouns ) ว่าผิดธรรมชาติมากในขณะที่โปรแกรมเมอร์ Terran ส่วนใหญ่มักจะชอบวัตถุที่เน้นภาษาที่ใช้งานได้ ฉันชอบทั้งสองสไตล์เนื่องจากฉันคิดว่ามันเป็นเรื่องของมุมมอง ปัญหาบางอย่างถูกโจมตีได้ดีที่สุดเมื่อใช้งานได้ส่วนปัญหาอื่น ๆ ที่มีเทคนิคการโปรแกรมเชิงวัตถุ โปรแกรมเมอร์ที่ดีมักจะมองปัญหาที่ยากจากมุมที่แตกต่างกันเสมอก่อนที่เขาจะพยายามแก้ปัญหา หรือขณะที่อลันเคย์วาง: มุมมองเป็นมูลค่า 80 คะแนนไอคิว

ดังนั้นคำตอบของฉันสำหรับคำถามของคุณคือ: คุณกำลังพูดถึงโลกแห่งความจริง? แล้วยังไง?

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

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

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

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

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

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

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

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

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

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

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

ดูเหมือนว่าฉันจะไม่เป็นความจริงกับสิ่งใดนอกชั้นธุรกิจ

ไม่ในขณะที่คุณชี้ให้เห็นสิ่งต่าง ๆ หลายอย่าง "แบบจำลอง" ในภาษา OOP เป็นแนวคิดนามธรรมเช่นคิวข้อความและตัวควบคุมและสแต็ค

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

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

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

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

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

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

ความแตกต่างที่ใหญ่ที่สุดระหว่าง OOP และไม่ใช่ OOP คือ OOP ผูกรหัสกับข้อมูล ดังนั้นแทนที่จะเรียกรหัสเช่นนี้:

verb(noun);

เราทำสิ่งนี้แทน:

noun->verb();

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

การเขียนโปรแกรมเชิงวัตถุจริง ๆ แบบจำลองโลกแห่งความจริงหรือไม่

ไม่สมบูรณ์.

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

ตัวอย่างเช่นหากแอปพลิเคชันรถเข็นมีปัญหาในมือเรามีเอนทิตีต่าง ๆ เช่น

1. ผลิตภัณฑ์ซึ่งเป็นศัพท์ที่เป็นนามธรรมซึ่งสามารถมีสมาชิกได้หลายคนเช่นหนังสือ, แกดเจ็ต, รถยนต์ซึ่งสามารถแบ่งย่อยได้อีกครั้ง

2. เกณฑ์ภาษีเช่น (ภาษีขาย) จะขึ้นอยู่กับตำแหน่งของซอฟต์แวร์ที่ใช้งานเนื่องจากอาจมีการเปลี่ยนแปลงตามนโยบายของรัฐบาล

3. การพิจารณาภาษีขึ้นอยู่กับว่านำเข้าผลิตภัณฑ์ตามเกณฑ์ภาษีหรือไม่

4. ผู้ใช้สามารถมีตะกร้าสินค้าซึ่งมีรายการผลิตภัณฑ์ ฯลฯ

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

ฉันคิดว่าคุณกำลังอ่านมากเกินไปในสิ่งที่ตั้งใจจะเป็นคำพูดที่น่าเบื่อหน่ายประวัติศาสตร์ ความคิดหลายอย่างของการเขียนโปรแกรม OO, คลาส, โพลีมอร์ฟิซึม, ฟังก์ชั่นเสมือนจริงและอื่น ๆ ได้ถูกนำเสนอในภาษา Simula ย้อนกลับไปในทศวรรษ 1960 (http://en.wikipedia.org/wiki/Simula) ตามชื่อที่แนะนำ Simula ถูกออกแบบมาให้เป็นภาษาสำหรับการเขียนแบบจำลอง ดังนั้นในอดีตใช่แนวคิด OO ถูกนำเสนอในความพยายามที่จะจำลอง "โลกแห่งความจริง" ไม่ว่าพวกเขาจะประสบความสำเร็จมากกว่าสไตล์อื่น ๆ เป็นเรื่องของการอภิปราย

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

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

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

ในทางกลับกันหากคุณกำลังสร้างแบบจำลองส่วนประกอบต่าง ๆ ที่โต้ตอบเพื่อสร้างพฤติกรรมที่ต้องการการปฏิบัติต่อพวกเขาในฐานะตัวแทนแทนที่จะเป็นสิ่งที่อยู่เฉยๆจะทำให้การทำอย่างถูกต้องง่ายขึ้นโดยไม่พลาดอะไรเลย ถ้าฉันต้องการเปิดทีวีของฉันฉันเพียงกดปุ่มถ้าสายไฟไม่ได้เสียบปลั๊กสายไฟTV.turnOnจะตรวจสอบให้ฉัน ดังนั้นจึงไม่มีความเสี่ยงในการเปลี่ยนฟันเฟืองและลืมหันไปหาสิ่งอื่นที่สัมผัสมันเนื่องจากฟันเฟืองตัวเอง (หากโปรแกรมถูกต้อง) จะดูแลการโต้ตอบรองที่เกิดขึ้นจากการกระทำหลัก

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

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

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

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

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

บทความของ Wikipediaเกี่ยวกับเรื่องนี้สรุปได้ดี:

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

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

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

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

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

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

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

จนถึงตอนนี้สิ่งนี้ไม่ได้พูดคุยเกี่ยวกับ OO ใช่ไหม? มาทำกันเถอะ

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

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

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

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

ฉันหวังว่าจะช่วยให้คุณเข้าใจว่า OO นั้นเกี่ยวกับอะไรโดยไม่ปรากฏว่าลำเอียงเกินไประหว่าง OO และกระบวนทัศน์การทำงาน

OOP สร้างโมเดลที่ดีจากมุมมองการเขียนโปรแกรม แต่ไม่ได้สะท้อนถึงโลกแห่งความเป็นจริง

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

apply_discount_of 5.percent:
         when order.Total > 1000 and customer.IsPreferred
         when order.Total > 10000

suggest_registered_to_preferred:
         when order.Total  > 100 and not customer.IsPreferred

อีกตัวอย่างหนึ่งคือกรอบการทดสอบการยอมรับของผู้ใช้แบบอัตโนมัติโดยใช้ภาษาGherkin

Feature: Some terse yet descriptive text of what is desired
    In order to realize a named business value
    As an explicit system actor
    I want to gain some beneficial outcome which furthers the goal

Scenario: Some determinable business situation
    Given some precondition
        And some other precondition
    When some action by the actor
        And some other action
        And yet another action
    Then some testable outcome is achieved
        And something else we can check happens too

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