บทนำ

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

การนำแอปพลิเคชันจำหน่ายตั๋วไปใช้งาน

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

รหัสฝึกหัด:https://github.com/Java-Crew/objects-study/tree/jayon/src/main/java/chapter01/step01

ปัญหาคืออะไร

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

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

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

รหัสที่นอกเหนือความคาดหมาย

ลองมาดูสาเหตุที่ไม่ตรงตามวัตถุประสงค์ของการสื่อสารกัน

• สิ่งที่เมธอด enter() ของคลาส Theater ทำ
  • โรงละครจะเปิดกระเป๋าของผู้ชมเพื่อตรวจสอบว่ามีบัตรเชิญอยู่ข้างในหรือไม่
  • ถ้ามีบัตรเชิญอยู่ข้างใน กระเป๋า โรงละครจะสั่งให้พนักงานขายย้ายตั๋วที่เก็บไว้ในตู้ขายตั๋ว ไปไว้ในกระเป๋าของผู้ชม
  • ถ้าไม่มีบัตรเชิญอยู่ข้างใน กระเป๋า โรงละครจะนำเงินสดออกจากกระเป๋าของผู้ชม เท่ากับราคาตั๋ว ซื้อตั๋ว และใส่ตั๋วไว้ในกระเป๋า
• จากมุมมองของผู้ชม โรงละครซึ่งเป็นบุคคลที่สามจะต้องเปิดกระเป๋าของพวกเขา และนำเงินไปด้วยตนเอง และใส่ตั๋วไว้ในกระเป๋าของพวกเขา
• จากมุมมองของพนักงานขาย โรงละครซึ่งเป็นบุคคลที่สามจะต้องดูแลตู้ขายตั๋ว ของพวกเขาโดยไม่ขออนุญาต และจัดการกับเงินสดและตั๋ว
• รหัสที่เข้าใจได้หมายถึงรหัสที่ทำงานไม่นอกเหนือความคาดหวังของเรา และโรงละครนี้ก็ออกนอกความคาดหมายของเรา
  • ผู้ชมควรนำเงินสดออกจากกระเป๋าของตนเองเพื่อชำระเงิน และรับตั๋วจากพนักงานขาย
  • พนักงานขายควรนำตั๋วออกจากตู้ขายตั๋วด้วยตัวเอง ส่งให้กับผู้ชม และรับเงินสดจากผู้ชมเพื่อเก็บไว้ในตู้ขายตั๋ว
• นอกจากนี้ เพื่อให้เข้าใจเมธอด enter() เราจำเป็นต้องจำรายละเอียดต่างๆ ทั้งหมดด้วย
  • Audience มี Bag
  • Bag มีเงินสดและตั๋ว
  • TiketSellet ขายตั๋วจาก TicketOffice และ TicketOffice มีเงินสด และตั๋วเก็บไว้

รหัสที่อ่อนไหวต่อการเปลี่ยนแปลง

เมธอด enter() มีสองเงื่อนไข

• ผู้ชมจะพกกระเป๋าติดตัวไปเสมอเพื่อเก็บเงินสดและบัตรเชิญ
• พนักงานขายขายตั๋วจากตู้ขายตั๋วเท่านั้น

แล้วสถานการณ์ต่อไปนี้จะเป็นอย่างไร

• ผู้ชมอาจไม่มีกระเป๋า
• ผู้ชมอาจใช้บัตรเครดิตแทนเงินสด
• พนักงานขายอาจขายตั๋วจากนอกตู้ขายตั๋ว

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

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

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

ปรับปรุงการออกแบบ

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

เพิ่มระดับความเป็นอิสระ

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

การเขียนโปรแกรมเชิงกระบวนการและเชิงวัตถุ

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

รหัสฝึกหัด:https://github.com/Java-Crew/objects-study/tree/jayon/src/main/java/chapter01/step02

สามารถปรับปรุงได้อีก

• คลาส Bag ของคลาส Audience ยังคงเป็นหน่วยงานที่ไม่เป็นอิสระ ที่ถูกควบคุมโดยคลาส Audience ดังนั้นเราจึงต้องสร้างคลาส Bag เป็นออบเจ็กต์ที่เป็นอิสระ
• TicketOffice ของคลาส TicketSeller ถูกควบคุมโดย TicketSeller ด้วย ดังนั้นเราจึงต้องสร้าง TicketOffice เป็นออบเจ็กต์ที่เป็นอิสระ
  • อย่างไรก็ตาม หลังจากเปลี่ยนแปลงแล้ว TicketOffice จะมีการผูกมัดเพิ่มเติมกับ Audience
  • การออกแบบต้องมีการพิจารณา trade-off อย่างรอบคอบ ในกรณีนี้ เราสามารถตัดสินใจที่จะสร้าง TicketOffice เป็นออบเจ็กต์ที่ไม่เป็นอิสระในระดับหนึ่งเพื่อลดการผูกมัด กับ Audience

รหัสฝึกหัด:https://github.com/Java-Crew/objects-study/tree/jayon/src/main/java/chapter01/step03

ใช่แล้ว มันเป็นเรื่องโกหก!

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

การออกแบบเชิงวัตถุ

เหตุใดการออกแบบจึงจำเป็น

• การออกแบบคือการวางรหัส
• การออกแบบที่ดีคือการออกแบบที่สามารถตอบสนองความต้องการในวันนี้ ได้อย่างสมบูรณ์แบบและรองรับการเปลี่ยนแปลงในอนาคตได้อย่างราบรื่น

การออกแบบเชิงวัตถุ

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

แหล่งที่มา

• ออบเจ็กต์