"สวัสดี Amigo! ฉันอยากจะบอกคุณเกี่ยวกับข้อดีอีกอย่างของ OOP คุณคงเห็นแล้วว่า โปรแกรมต่างๆ นั้นเหมือนสัตว์มากกว่าสิ่งก่อสร้าง มันไม่ได้ถูกสร้างขึ้น พวกมันเติบโตขึ้นการพัฒนาหมายถึงการเปลี่ยนแปลงอย่างต่อเนื่องในการก่อสร้าง คุณสามารถ มีการวางแผนที่ดีและปฏิบัติตาม T. แต่ในการพัฒนาซอฟต์แวร์นั้นไม่ใช่อย่างนั้น"
บ่อยครั้ง คุณไม่สามารถทำบางสิ่งในแบบที่คุณตั้งใจไว้ได้ และคุณต้องแก้ไขโปรแกรมของคุณใหม่หลายครั้ง และยิ่งบ่อยครั้งที่ความต้องการของลูกค้าเปลี่ยนไป
"แต่ถ้าลูกค้าให้ข้อมูลจำเพาะที่ละเอียดจริงๆ"
"ลองดูว่าเกิดอะไรขึ้นเมื่อเวลาผ่านไปหากผลิตภัณฑ์ประสบความสำเร็จ ลูกค้าจะต้องการเปิดตัวเวอร์ชันใหม่ และจากนั้นอีกรุ่นหนึ่ง และอีกรุ่นหนึ่งและแน่นอน คุณจะต้องทำ « การเปลี่ยนแปลงเล็กๆ น้อยๆ » เพื่อ ผลิตภัณฑ์ที่มีอยู่ดังนั้น การพัฒนาซอฟต์แวร์จึงเป็นชุดของการเปลี่ยนแปลงที่ยาวนาน มีเพียงจังหวะเท่านั้นที่แตกต่างกันเวอร์ชันใหม่อาจออกในแต่ละสัปดาห์ เดือนละครั้ง หรือทุก ๆ หกเดือน"
"แล้วสรุปจากทั้งหมดนี้คืออะไร"
"โครงสร้างภายในของผลิตภัณฑ์ต้องได้รับการบำรุงรักษาในลักษณะที่จะทำให้เกิดการเปลี่ยนแปลงที่สำคัญ (และเล็กน้อย) ได้โดยการทำงานซ้ำให้น้อยที่สุด"
"คุณทำอย่างนั้นได้อย่างไร"
"เราได้คุยกันแล้วว่าโปรแกรมประกอบด้วยวัตถุที่โต้ตอบกันอย่างไร ลองใช้จุดหนาแทนวัตถุทั้งหมดของโปรแกรมบนกระดาน เราจะวาดลูกศรจากแต่ละวัตถุ (จุด) ไปยังวัตถุทั้งหมด (จุด) ที่โต้ตอบด้วย"
ตอนนี้ให้รวมวัตถุ (จุด) เป็นกลุ่ม จุดอยู่ในกลุ่มเดียวกันหากพวกมันเชื่อมต่อกันมากกว่าจุดอื่นๆ หากลูกศรของจุดส่วนใหญ่ชี้ไปที่จุดต่างๆ ในกลุ่มนั้น แสดงว่าเราได้จัดกลุ่มวัตถุนั้นถูกต้องแล้ว จุดที่อยู่ในกลุ่มเดียวกันเรียกว่าเชื่อมต่อกันแน่น ในขณะที่จุดในกลุ่มต่างๆ เชื่อมต่อกันอย่างหลวมๆ
สิ่งนี้เรียกว่า « หลักการของการมีเพศสัมพันธ์แบบหลวมๆ » โปรแกรมถูกแบ่งออกเป็นหลายส่วน ซึ่งมักจะเป็นเลเยอร์ ซึ่งลอจิกจะเชื่อมโยงกับโครงสร้างภายในอย่างมาก และเชื่อมโยงกับเลเยอร์/ส่วนอื่นๆ อย่างอ่อน ปฏิสัมพันธ์ระหว่างชั้นมักจะถูกแบ่งส่วนสูง เลเยอร์หนึ่งสามารถเรียกเลเยอร์อื่นได้โดยใช้คลาสย่อยเพียงเล็กน้อยเท่านั้น
"หลักการ 'การแบ่งงาน' เหมือนเดิม แต่มีขนาดที่ใหญ่ขึ้น?"
"ถูกต้อง สิ่งนี้ช่วยให้เราจัดระเบียบแผนกใหม่ ทำให้มีประสิทธิภาพมากขึ้น และจ้างคนได้มากขึ้น และหากเราไม่เปลี่ยนระเบียบการระหว่างแผนก การเปลี่ยนแปลงทั้งหมดของเราจะเป็นแบบท้องถิ่น ไม่มีใครต้องได้รับการฝึกใหม่ เราไม่ ไม่จำเป็นต้องทำใหม่ทั้งระบบ แต่ละแผนก สามารถเพิ่มประสิทธิภาพกิจการภายในด้วยวิธีนี้ได้หากเลือกกลไกสำหรับการโต้ตอบของแผนกได้ดี"
“ถ้าพวกเขาถูกเลือกมาอย่างดี แล้วถ้าพวกเขาไม่ถูกเลือกล่ะ?”
'จากนั้นคุณก็จะไม่มี « ห้องขยับได้ » สำหรับทำการเปลี่ยนแปลงอย่างรวดเร็ว และต้องทำงานใหม่ทั้งระบบ ที่เกิดขึ้นเป็นครั้งคราว เราไม่สามารถทำนายอนาคตได้ แต่เราสามารถลดจำนวนครั้งที่เราต้องเขียนโปรแกรมใหม่ได้"
“โอเค ผมเห็นประโยชน์ของการแบ่งโปรแกรมแบบนั้น แต่ OOP จะมาอยู่ในภาพได้อย่างไร”
"เมื่อเราเลือกวิธีจัดโครงสร้างแผนกและวิธีโต้ตอบ เราจะใช้ ' หลักการนามธรรม ' ในการเขียนโปรแกรม นามธรรมถูกใช้เพื่อกำหนดวิธีที่ดีที่สุดในการแยกโปรแกรมและวิธีที่ส่วนต่างๆ ควรโต้ตอบ หลักการนี้สามารถ และนำไปใช้ซ้ำกับส่วนประกอบต่างๆ จนกว่าเราจะแยกโปรแกรมออกเป็นแต่ละคลาส"
"และซ่อนโครงสร้างภายในของชิ้นส่วนเหล่านี้ และจำกัดวิธีที่พวกมันมีปฏิสัมพันธ์กับส่วนอื่นๆ อย่างเข้มงวด นั่นคือการห่อหุ้มใช่ไหม"
"ถูกต้องการห่อหุ้มและนามธรรมเป็นรากฐานที่สำคัญของ OOPโปรแกรมที่ดีต้องเป็นไปตามหลักการทั้งสองนี้ หลังจากนั้น เราจะมาดูหลักการอื่นๆ และมาทำความเข้าใจกับข้อดีของหลักการเหล่านี้"
"ของดี ฉันรอไม่ไหวแล้ว!"
GO TO FULL VERSION