จะอธิบายแนวคิดของ OOP ให้กับบุคคลที่ไม่ใช่ช่างเทคนิคได้อย่างไร?

ฉันมักจะพยายามหลีกเลี่ยงการบอกคนอื่นว่าฉันเป็นโปรแกรมเมอร์เพราะส่วนใหญ่แล้วฉันจะอธิบายให้พวกเขาฟังว่ามันหมายถึงอะไรจริง ๆ เมื่อฉันบอกพวกเขาฉันกำลังเขียนโปรแกรมใน Java พวกเขามักถามคำถามทั่วไปเกี่ยวกับภาษาและความแตกต่างจาก x และ y ฉันไม่สามารถอธิบายสิ่งต่าง ๆ ได้ดีเพราะ 1) ฉันไม่มีประสบการณ์มากมายในสนามและ 2) ฉันเกลียดการอธิบายสิ่งต่าง ๆ กับคนที่ไม่ใช่ช่างเทคนิค

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

ฉันมักจะลองและอธิบายการเขียนโปรแกรมเชิงวัตถุโดยใช้ตัวอย่างโลกแห่งความจริง

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

จากนั้นฉันจะขอให้พวกเขาลืมเกี่ยวกับรถยนต์หรือรถบรรทุกและขอให้พวกเขาอธิบายยานพาหนะต่อไป:

"โอ้มันเคลื่อนไหวได้ดี"

"มันมีโอเปอเรเตอร์หรือไดรเวอร์"

ฯลฯ ...

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

"ประตู"

"Windows"

แล้วรถบรรทุก ....

"ประตู" "windows" "ล้อเพิ่มเติม!"

ในไม่ช้าหลังจากการสนทนามากมายบุคคลอื่นโดยทั่วไปได้ระบุ:

1) สิ่งที่ถือเป็นยานพาหนะ

2) สิ่งที่ถือเป็นรถยนต์

3) สิ่งที่ถือเป็นรถบรรทุก

4) อะไรประกอบเป็นเครื่องบิน

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

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

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

ในขณะนี้ความเชี่ยวชาญเทมเพลตบางส่วนกลับกัน .... :)

วัตถุเป็นคำนามวิธีการเป็นคำกริยา

นี่คือบางส่วนของคำตอบกระป๋องของฉันที่ฉันให้กับบุคคลที่ไม่ใช่ด้านเทคนิค:

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

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

การพูดและการเดินสามารถมีหลายรูปแบบเช่นภาษาที่กำลังพูดหรือความเร็วหรือลักษณะที่คนกำลังเดิน

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

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

-> ข้อความนี้มักจะเพียงพอที่จะตัดความอยากรู้อยากเห็นของพวกเขา (หรืออาจทำให้พวกเขาน้ำตา) แต่ถ้าพวกเขามีคำถามเพิ่มเติมข้อความข้างต้น (ฉันเชื่อว่า) เป็นรากฐานที่ดีสำหรับการสนทนา ฉันไม่คิดว่าคนที่ไม่ใช่ด้านเทคนิคเกี่ยวข้องกับคำศัพท์ทางเทคนิคมากเกินไปเช่น "Abstraction," "Composition," "Polymorphism" ฯลฯ แต่ถ้าเป็นภาษาที่ฉันใช้ในคำสั่งกระป๋องทำให้ฉัน เพื่อดึงตัวอย่างตามมัน

ฉันมักจะเรียนรู้ OOP เช่นนี้:

คุณมีนาฬิกาและมันบอกเวลา - ในการเขียนโปรแกรมคุณใส่รหัสและสิ่งของทั้งหมดที่คุณต้องทำทั้งหมดเข้าด้วยกัน (ฟังดูค่อนข้างชัดเจน แต่คนไม่เคยทำแบบนี้มาก่อนในช่วงแรก) อย่างไรก็ตามที่เรียกว่าencapsulation

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

นอกจากนี้คุณดูนาฬิกาที่ฉันมีบนข้อมือของฉัน แต่คุณสามารถนาฬิกาอื่น ๆ ที่มีลักษณะแตกต่างกันเช่นนาฬิกาคุณปู่หรือนาฬิกาดิจิตอล แต่ดูเหมือนว่ามันแตกต่างกัน แต่ก็ยังคงเป็นนาฬิกาปลุก - ดีที่เรียกว่าแตกต่าง

และที่นั่นคุณมีมุมการเขียนโปรแกรมเชิงวัตถุ 3 มุม ที่เหลือก็แค่เขียนโค้ด

ฉันแค่บอกให้พวกเขาสมัครหลักสูตรใน OOP ถ้าพวกเขาต้องการเข้าใจจริงๆ

ฉันหมายถึงอุปมาเหล่านั้นทั้งหมดเช่น Car.startEngine (); คือขอหน้ามัน - แร็พที่บริสุทธิ์ เมื่อฉันเข้าสู่ OOP เป็นครั้งแรกเมื่อหลายปีก่อนฉันพบว่าสิ่งเหล่านี้เป็นนามธรรมเพียงโดเมนยิ่งขึ้นไปอีก

แทนที่จะอธิบายว่า OOP นั้นเกี่ยวกับการจัดการความซับซ้อนของภาษาขั้นตอนเกือบ 80% ของผู้เขียนหนังสือเขียนโปรแกรมสมมติว่าโปรแกรมเมอร์เป็นคนโง่ไร้เดียงสาที่จำเป็นต้องพูดอย่างง่าย ๆ (ดูคำประชดที่นี่?)

ใช่มันเป็นเรื่องปกติอย่างสมบูรณ์แบบที่จะอธิบายรายการและเวกเตอร์เพราะนั่นคือสิ่งที่เราทำงานร่วมกันไม่ใช่ Car.Engine และ PoliceMan.Arrest (เว้นแต่ว่าคุณเป็น dev เกม แต่อีกครั้งคุณยังต้องมีส่วนแบ่งของ อดีต).

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

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

ฉันพูดคุยเกี่ยวกับบทสนทนาที่ฉันมีกับภรรยาเกี่ยวกับสิ่งนี้ในคำตอบนี้ที่นี่: /software/45464/how-to-convince-non-programmer-his-notions-about- คอมพิวเตอร์มีความผิด / 45467 # 45467

แก้ไข: คำถามที่ฉันตอบมีการกลั่นกรองออกไปดังนั้นฉันจะตอบคำตอบของฉันที่นี่อีกครั้ง

นั่งอยู่ในร้านอาหารกับภรรยาของฉันเธอถามฉันว่า "Object Oriented หมายถึงอะไร"

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

ดังนั้นฉันจึงหยิบ Splenda แพ็คเก็ตออกจากภาชนะ ฉันพูดว่า "นี่คือวัตถุคุณสมบัติของมันคืออะไร"

เธอพูดว่า "มันเป็นสี่เหลี่ยมมันทำจากกระดาษมันมี splenda มันเป็นสีน้ำเงินมันมีการพิมพ์อยู่"

ฉันหยิบซองน้ำตาลขึ้นมา "มันมีอะไรที่เหมือนกันกับอันนี้"

เธอพูดว่า "ความเป็นสี่เหลี่ยมกระดาษที่มีการพิมพ์"

ฉันพูดว่า "แล้วพวกเขาทั้งคู่มีอะไรที่หวาน ๆ "

เธอพูดว่า "แน่นอน"

ฉันพูดว่า "นี่คือทั้งสองกรณีของสิ่งที่เราอาจเรียกว่าแพ็คเก็ตสารให้ความหวานที่เป็นนามธรรม

เธอพูดว่า "แน่นอน"

ฉันพูดว่า "และแต่ละคนมีคุณสมบัติที่สืบทอดมาจากแพ็กเก็ตนามธรรม

เธอพูดว่า "ถูกต้อง Oh! และถ้าฉันต้องการทำเช่นเดียวกับแพคเก็ต Saccharine ฉันจะเอายาสามัญและตั้งรายละเอียดเกี่ยวกับมันสำหรับ Saccharine แล้วฉันจะทำอย่างนั้น!"

ฉันพูดว่า "Bingo: การเขียนโปรแกรมเชิงวัตถุ"

คุณและฉันรู้ว่าเธอแค่ใช้สัญชาตญาณในการออกแบบโรงงาน อะไรก็ตาม มันแสดงให้เห็นถึงมรดกการห่อหุ้มตัวตนของคลาสวัตถุ ... สิ่งที่ดี

คำถามนี้ดูเหมือนว่าผู้สมัครจะถูกปิดอย่างไรก็ตาม ...

เช่นเดียวกับสิ่งต่าง ๆ ส่วนใหญ่ OOP นั้นง่ายมากที่จะอธิบายในระดับแนวคิด โปรแกรมเมอร์โมเดลวัตถุ และ:

• วัตถุมีสถานะ (เขตข้อมูล / สมาชิกข้อมูล)
• วัตถุมีการกระทำ (วิธีการ / ฟังก์ชั่น)
• วัตถุที่สร้างต่อกัน (การสืบทอด)

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

ตัวอย่างโทรศัพท์มือถือ:

ลองนึกภาพคุณเป็นเจ้าของโรงงานคุณต้องการอธิบายโทรศัพท์ทั่วไป

• ขั้นตอนที่ 1: รายการคุณสมบัติโทรศัพท์ทั่วไปเช่นความสูงน้ำหนักสี ฯลฯ
• ขั้นตอนที่ 2: ทำรายการฟังก์ชั่นโทรศัพท์ทั่วไป เช่นโทรออกรับสายส่ง SMS ฯลฯ

ตอนนี้คุณมี "พิมพ์เขียว" ทั่วไปของคุณสร้างโทรศัพท์ต่อไปนี้ให้ฉัน:

โทรศัพท์ 1:

• ความสูง -> 102 มม

• น้ำหนัก -> 85 กรัม

• Colour-> Pink

โทรศัพท์ 2:

• ความสูง -> 125 มม

• น้ำหนัก -> 96 กรัม

• Colour-> Red

ฉันคิดว่าวิธีที่ดีที่สุดในการอธิบายประเภทที่ไม่ใช่ด้านเทคนิคเกี่ยวกับ OOP คือการเชื่อมโยงกับพวกเขา

โดยพื้นฐานแล้ว OOD & OOP ต้องการให้คุณคิดเกี่ยวกับระบบที่คุณกำลังออกแบบและนำไปใช้เป็นโลกแห่งการโต้ตอบกับสิ่งต่าง ๆ

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

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

"อืมบ๊อบ" คุณตอบกลับไปมา “ มันค่อนข้างง่ายจริง ๆ คุณรวบรวมขยะใช่ไหมอะไรโดยทั่วไปคุณทำงานของคุณหรือไม่”

“ ฉันไปตามรถตู้รอบเมืองเพื่อเก็บขยะและนำไปไว้ในรถตู้” บ๊อบตอบอย่างแปลก ๆ

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

บ๊อบหลับไปในเบียร์ของเขา คุณเดินไป

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

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

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

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

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

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

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

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

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

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