เหตุใดจึงเป็นการดีที่จะแยกโปรแกรมออกเป็นหลายคลาส [ปิด]


62

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

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

โครงการนี้อยู่ใน Java และฉันเป็นคนเดียวที่ทำงานกับมันสำหรับการบันทึก


1
เพื่อทำให้ซอฟต์แวร์แต่ละชิ้นง่ายขึ้น! infoq.com/presentations/Simple-Made-Easy-QCon-London-2012
TehShrike

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

12
ชาวโรมันเคยพูดว่า: หารและต่อเนื่อง
Giorgio

7
@Giorgio หรือในภาษาอังกฤษเพราะละตินไม่ได้ถูกใช้เพื่อให้ได้อีกต่อไป: แบ่งและพิชิต
Matthieu M.

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

คำตอบ:


71

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

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

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


7
แนวคิด / ความคิดจำนวนมากในการเขียนโปรแกรม (หลักการ OO, การควบคุมแหล่งที่มาแบบกระจาย, มาตรฐานการเข้ารหัส) จะสมเหตุสมผลจริงๆเมื่อคุณทำงานในโครงการที่ค่อนข้างใหญ่ในทีม คุณจะเข้าใจว่าทำไมเมื่อคุณทำงานในโครงการดังกล่าว
joshin4colours

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

2
คำสำคัญบางคำอาจเป็น "ข้อต่อ" หรือ "decoupling", "encapsulation", "การซ่อนข้อมูล"
marktani

@BrendanLong ฉันเห็นด้วยและฉันยังจะเพิ่ม encapsulation ที่เป็นไปไม่ได้เกือบ เว้นแต่ว่าคุณจะเขียนโปรแกรมแยกต่างหากแน่นอน ... แต่โดยปกติแล้วจะมีหลายส่วนที่ไม่ได้พึ่งพาซึ่งกันและกัน แต่จะมีการพึ่งพาร่วมกันเท่านั้น
Jo So

29

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

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

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


12

นี่เป็นคำถามที่ดี! ง่ายและถามดี ดี ... คำตอบนั้นไม่ง่ายนักที่จะเข้าใจนักเรียนที่เรียนวิทยาศาสตร์คอมพิวเตอร์และอาจไม่รู้ใน OO อย่างลึกซึ้งและอาจไม่มีประสบการณ์ทำงาน

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

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

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

ฉันจะบอกว่าแยกความกังวลการทำงานร่วมกันและ decoupling เป็นแนวคิดที่อยู่ในขอบเขตที่สูงกว่าทางวินัยของ OOP โปรแกรมเมอร์ที่มีความจำเป็นตรรกะและการทำงานเหมือนกันทุกคนมุ่งมั่นเพื่อการทำงานร่วมกันสูงและการมีเพศสัมพันธ์ต่ำ
sara

8

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

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

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

ถือโปรแกรมไว้ในหัว ลิงค์จาก Giorgio


1
+1: การทำงานเป็นทีมก็สำคัญเช่นกัน! ดูเช่นpaulgraham.com/head.htmlและย่อหน้าที่มีชื่อเรื่อง "ไม่มีคนแก้ไขโค้ดชิ้นเดียวกันหลายคน"
Giorgio

@ จอร์โจฉันเพียงแค่อ่านผ่านมัน แต่ดูเหมือนว่าทรัพยากรที่ยอดเยี่ยม! ฉันจะเพิ่มลงในคำตอบของฉันเพียงเพราะบางคนอาจไม่ได้ดูในส่วนความเห็น จะให้อ่านอย่างละเอียดมากขึ้นอย่างแน่นอน
Sephallia

นอกจากนี้ยังนำไปใช้กับการควบคุมการแก้ไข - การทำงานกับไฟล์ที่แยกต่างหากหมายถึงความขัดแย้งและการผสานที่น้อยลง
Reinstate Monica

7

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

ที่ถูกกล่าวว่าถ้าคุณแบ่งรหัสของคุณออกเป็นหน่วยทางลอจิคัลที่แตกต่างกัน (Classes, modules ฯลฯ ) คือคุณสามารถมีส่วนสั้น ๆ ที่เข้าใจง่ายของโค้ด ที่สามารถรักษาได้ในภายหลัง โมดูลของฉันหลายแห่งมีโค้ดน้อยกว่า 20 บรรทัด ฉันรู้ว่ารหัสทั้งหมดในเรื่องที่กำหนดอยู่ในสถานที่ที่เฉพาะเจาะจง นอกจากนี้ยังหมายความว่าถ้ามีคนอื่นเข้าร่วมโครงการพวกเขาจะมีเวลาค้นหาสิ่งต่าง ๆ ได้ง่ายขึ้น

ดังที่ Gerald Sussman กล่าวว่าควรเขียนโปรแกรมของเราก่อนเพื่อให้ผู้คนสามารถอ่านได้และที่สองเพื่อให้คอมพิวเตอร์สามารถรันได้ (และถ้าคุณมี nto อ่าน "โครงสร้างและการตีความของโปรแกรมคอมพิวเตอร์ แต่คุณควร)


4

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

คุณเพียงแค่ต้องแบ่งและพิชิตเพื่อจัดการกับมัน


3

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

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

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

Java ได้รับการออกแบบมาเป็นพิเศษสำหรับผู้ที่กำลังเขียนโค้ด Object Oriented แต่แม้แต่โปรแกรม OO ที่เข้มข้นที่สุดก็ใช้การเขียนโปรแกรมที่มีโครงสร้างและคุณสามารถทำลายภาษาใดก็ได้ (ฉันทำ OO แบบธรรมดา C. ) คุณสามารถทำ SP หรืออะไรก็ได้ใน Java ลืมชั้นเรียนและมุ่งเน้นวิธีการขนาดใหญ่ที่สามารถแบ่งย่อยออกเป็นขนาดเล็กจัดการได้ ฉันควรเพิ่ม SP ให้มากช่วยให้คุณสามารถนำรหัสของคุณมาใช้ซ้ำและใช้กับ DRY (google it ได้ แต่มันหมายถึง "อย่าทำซ้ำตัวเอง")

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


0

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

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

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


0

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

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

อย่างไรก็ตามนี่ไม่ใช่ที่ที่ชั้นเรียนเปล่งประกาย พิจารณาStringคลาส: คุณสามารถมีคุณสมบัติเดียวกันทั้งหมดโดยใช้charอาร์เรย์และฟังก์ชั่นคงที่ ณ จุดนี้ฟังก์ชั่นให้คุณเพิ่มความปลอดภัยและน้ำตาลทรายเล็กน้อย คุณสามารถเขียนstring.length()แทนlength(char_array); นั่นไม่ใช่เรื่องใหญ่มาก แต่หลายคนยังคงชอบมัน ยิ่งกว่านั้นคุณรู้ว่าถ้ามีคนให้คุณStringมันถูกสร้างขึ้นด้วยตัวStringสร้างและมันจะต้องทำงานกับlengthฟังก์ชั่น - ถ้ารุ่นอาร์เรย์ไม่สามารถจัดการกับตัวละครบางอย่างแล้วมันก็ไม่มีวิธีที่จะป้องกันไม่ให้คุณใส่ไว้ในนั้น .

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

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


0

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


0

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

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.