1. ประวัติบริษัท
ฉันต้องการเล่าเรื่องที่แสดงให้เห็นว่าOOPช่วยต่อสู้กับความซับซ้อนของระบบขนาดใหญ่ ได้อย่างไร สิ่ง นี้จำเป็นสำหรับคุณในการทำความเข้าใจวัตถุประสงค์ของOOP
กาลครั้งหนึ่งนานมาแล้ว มีบริษัทเล็กๆ ที่ให้บริการขนส่งระหว่างกาแลกซี่...
เรียกมันว่า Galaxy Rush มีพนักงาน 5 คน คนหนึ่งทำงานด้านการเงิน คนที่สองทำงานในคลังสินค้า คนที่สามทำงานด้านการจัดส่ง คนที่สี่ดูแลเรื่องโฆษณา และคนที่ห้าดูแลทั้งองค์กร
พวกเขาทำงานหนักมากและประสบความสำเร็จในทุกสิ่ง บริษัทมีชื่อเสียงที่ดีและทำเงินได้มากมาย แต่ทุกปีมีออร์เดอร์เพิ่มขึ้นเรื่อย ๆ เจ้านายจึงต้องจ้างพนักงานเพิ่ม อีกหลายรายการสำหรับคลังสินค้า อีกหลายรายการสำหรับการจัดส่ง อีกหนึ่งรายการสำหรับการเงิน และผู้เชี่ยวชาญด้านการโฆษณาเพิ่มเติมเพื่อขยายส่วนแบ่งการตลาดของบริษัท
และนั่นคือจุดเริ่มต้นของปัญหา มีคนมากขึ้นและพวกเขาก็เริ่มที่จะขวางทางกัน
นักการตลาดใช้จ่ายเงินในบัญชีธนาคารไปกับแคมเปญโฆษณาใหม่ ดังนั้นจึงไม่มีเงินที่จะซื้อสินค้าที่ต้องจัดส่งอย่างเร่งด่วน
คลังสินค้ามีไฮเปอร์ไดร์ฟใหม่เอี่ยม 10 ตัวที่จัดส่งให้ลูกค้าเดือนละครั้ง ผู้ให้บริการขนส่งรายหนึ่งบินเข้ามาและนำไฮเปอร์ไดรฟ์สำหรับลูกค้ารายอื่นออกไป ทำให้คำสั่งซื้อปกติสำหรับไฮเปอร์ไดรฟ์ 10 ตัวล่าช้าไปหนึ่งเดือน ผู้จัดส่งรายแรกไม่ทราบว่าผู้จัดส่งรายที่สองเป็นผู้เติมเต็มคำสั่งซื้ออื่น
ผู้ช่วยผู้จัดการคนใหม่ส่งคนส่งของไปบนยานอวกาศเพื่อซื้อสินค้าเพิ่มเติม ในขณะเดียวกันคนอื่นๆ ก็รอให้ยานอวกาศที่มีอยู่ปรากฏขึ้น มีการจัดส่งด่วนจำนวนมาก แต่ผู้ช่วยคนนี้ดูแลเฉพาะการจัดซื้อและพยายามทำงานของเธอให้ดี ยิ่งพนักงานทำงานได้ดีเท่าไร เขาก็ยิ่งรบกวนการทำงานของผู้อื่นมากขึ้นเท่านั้น
จากการวิเคราะห์สถานการณ์ หัวหน้าตระหนักดีว่าทรัพยากรที่สำคัญ เช่น ยานอวกาศ เงินสด และผลิตภัณฑ์ไม่ได้ถูกใช้อย่างเหมาะสม แต่จะอยู่ภายใต้กฎ "คุณเลื่อน คุณแพ้" พนักงานคนใดก็ตามอาจใช้ทรัพยากรที่ทุกคนต้องการในการทำงาน ซึ่งจะทำให้พนักงานคนอื่นๆ และบริษัทโดยรวมตกอยู่ในอันตราย
ต้องทำอะไรสักอย่างหัวหน้าจึงตัดสินใจแบ่งบริษัทขนาดใหญ่ออกเป็นแผนกต่างๆ เขาสร้างแผนกจัดส่ง แผนกการตลาด แผนกจัดซื้อ แผนกการเงิน และแผนกสินค้าคงคลัง ไม่มีใครสามารถขึ้นยานอวกาศได้อีกต่อไป หัวหน้าแผนกจัดส่งได้รับข้อมูลทั้งหมดเกี่ยวกับการจัดส่งและออกเรือไปยังผู้จัดส่งพร้อมคำสั่งซื้อที่ให้ผลกำไรสูงสุด นอกจากนี้ โกดังไม่อนุญาตให้คนส่งของเอาสินค้าที่พวกเขาต้องการไป การหยิบสินค้าจากคลังสินค้ากลายเป็นกระบวนการควบคุมแทน แผนกการเงินจะไม่ปล่อยเงินทุนสำหรับแคมเปญการตลาดหากรู้ว่าจะมีการซื้อในเร็วๆ นี้ แต่ละแผนกมีหน้าสาธารณะหนึ่งหน้า - หัวหน้าแผนกโครงสร้างภายในของแต่ละแผนกเป็นธุรกิจของตนเอง ถ้าคนส่งของต้องการรับสินค้า เธอไปหาผู้จัดการคลังสินค้า ไม่ใช่ไปที่โกดัง หากมีคำสั่งซื้อใหม่เข้ามา หัวหน้าแผนกจัดส่งจะได้รับ ( public-facing representative) ไม่ใช่ผู้จัดส่ง ( someone not authorized to interact with the other departments)
กล่าวอีกนัยหนึ่งหัวหน้ารวมทรัพยากรและการกระทำที่เกี่ยวข้องกับทรัพยากรเป็นกลุ่ม (แผนก)และยังห้ามมิให้ผู้อื่นเข้าไปยุ่งเกี่ยวกับโครงสร้างภายในของแผนก การติดต่อระหว่างแผนกต้องผ่านบุคคลเฉพาะ
จากมุมมองของOOPนี่ไม่มีอะไรมากไปกว่าการแบ่งโปรแกรมออกเป็นวัตถุ โปรแกรมขนาดใหญ่ของวิธีการและตัวแปรกลายเป็นโปรแกรมที่ประกอบด้วยวัตถุ และวัตถุมีตัวแปรและวิธีการ
ปัญหาคือพนักงานทุกคนสามารถทำงานกับทรัพยากรใดก็ได้และสั่งการพนักงานคนอื่น ๆ โดยไม่ต้องดูแลหรือควบคุม เรากำหนดข้อจำกัดเล็กๆ น้อยๆ แต่ได้รับคำสั่งซื้อมากขึ้น และเรายังสามารถควบคุมทุกอย่างได้ดีขึ้นอีกด้วย
นี่คือการแบ่งแยกและเอาชนะในรูปแบบที่บริสุทธิ์ที่สุด
2. วิธีสร้างโปรแกรม
ฉันต้องการสัมผัสจุดสำคัญอีกจุดหนึ่งที่เผยให้เห็นข้อดีอีกอย่างของOOP คุณเห็นว่าโปรแกรมเป็นเหมือนสัตว์มากกว่าอาคาร? พวกเขาไม่ได้สร้างขึ้น พวกเขาเติบโตขึ้น การพัฒนาคือการเปลี่ยนแปลงตลอดเวลา ในการก่อสร้าง คุณสามารถมีการวางแผนที่ดีและปฏิบัติตามได้อย่างแม่นยำ นี่ไม่ใช่กรณีของการพัฒนาซอฟต์แวร์
บ่อยครั้งมากในการเขียนโปรแกรม คุณไม่สามารถทำบางสิ่งได้ตามที่คุณตั้งใจไว้แต่แรก และต้องทำใหม่หลายครั้ง ความต้องการของลูกค้าเปลี่ยนแปลงบ่อยขึ้น
แต่ถ้าลูกค้าให้ข้อมูลจำเพาะที่แม่นยำมากล่ะ นั่นทำให้สิ่งต่าง ๆ แย่ลงไปอีก ดูว่าเกิดอะไรขึ้นกับผลิตภัณฑ์เมื่อเวลาผ่านไป
ความสำเร็จของผลิตภัณฑ์จะทำให้ลูกค้าต้องการออกเวอร์ชันใหม่ แล้วจึงออกเวอร์ชันใหม่ และแน่นอน สิ่งที่คุณต้องทำคือเพิ่ม "การเปลี่ยนแปลงเล็กน้อย" ให้กับผลิตภัณฑ์ที่มีอยู่ คุณจะเห็นได้ว่าการพัฒนาผลิตภัณฑ์เป็นลำดับของการเปลี่ยนแปลงอย่างต่อเนื่อง ต่างกันแค่มาตราส่วนเวลา เวอร์ชันใหม่สามารถออกได้สัปดาห์ละครั้ง เดือนละครั้ง หรือทุกๆ หกเดือน
แล้วเราจะได้ข้อสรุปอะไรจากทั้งหมดนี้? โครงสร้างภายในของผลิตภัณฑ์จำเป็นต้องได้รับการบำรุงรักษาในลักษณะที่อนุญาตให้ทำการเปลี่ยนแปลงที่สำคัญ (และเล็กน้อย) ได้โดยการทำงานซ้ำน้อยที่สุด
การทำงานร่วมกันของวัตถุ
แต่การลงมือทำนั้นยากกว่าการตัดสินใจที่จะทำ เราได้กล่าวไปแล้วว่าโปรแกรมประกอบด้วยวัตถุที่มีปฏิสัมพันธ์ซึ่งกันและกัน มาวาดวัตถุของโปรแกรมทั้งหมดบนกระดานแทนด้วยคะแนน และวาดลูกศรจากแต่ละวัตถุ (จุด) ไปยังวัตถุ (จุด) อื่น ๆ ทั้งหมดที่โต้ตอบด้วย
ตอนนี้เราจะรวมวัตถุ (จุด) เป็นกลุ่ม ควรจัดกลุ่มคะแนนหากการเชื่อมต่อระหว่างจุดนั้นรุนแรงกว่าจุดที่มีจุดอื่นมาก หากลูกศรส่วนใหญ่จากจุดหนึ่งไปยังจุดอื่นๆ ในกลุ่มของมันเอง แสดงว่ากลุ่มนั้นถูกสร้างขึ้นอย่างถูกต้อง เรากล่าวว่าคะแนนภายในกลุ่มมีความเชื่อมโยงกันสูงในขณะที่คะแนนในกลุ่มต่างๆ มีการเชื่อมโยงกันต่ำกว่า
หลักการของข้อต่อหลวม
มี "หลักการของข้อต่อหลวม" โปรแกรมแบ่งออกเป็นหลายส่วน ซึ่งมักจะเป็นเลเยอร์ ตรรกะของเลเยอร์/ชิ้นส่วนเหล่านี้เชื่อมโยงอย่างแน่นหนากับโครงสร้างภายใน และเชื่อมโยงกับเลเยอร์/ชิ้นส่วนอื่นๆ อย่างหลวมๆ ปฏิสัมพันธ์ระหว่างเลเยอร์มักจะถูกควบคุมอย่างมาก เลเยอร์หนึ่งอาจหมายถึงเลเยอร์ที่สองและใช้ชุดย่อยเพียงเล็กน้อยของคลาสนั้น นี่คือหลักการของ "การแบ่งบริษัทออกเป็นแผนก" ที่เราเห็นก่อนหน้านี้ แต่ในระดับที่ใหญ่ขึ้น
ผลลัพธ์คือเราสามารถจัดระเบียบแผนกใหม่ตามความจำเป็นเพื่อเพิ่มประสิทธิภาพ และเราสามารถจ้างคนจำนวนมากขึ้นสำหรับแผนก และตราบใดที่เราไม่เปลี่ยนระเบียบการปฏิสัมพันธ์กับแผนกอื่นๆ ของเรา การเปลี่ยนแปลงทั้งหมดที่เกิดขึ้นก็จะ ยังคงอยู่ในท้องถิ่น ไม่มีใครต้องเรียนรู้อะไรใหม่ คุณไม่จำเป็นต้องทำงานใหม่ทั้งระบบ แต่ละแผนกสามารถดำเนินการเพิ่มประสิทธิภาพภายในประเภทนี้ได้ หากเลือกกลไกสำหรับการโต้ตอบระหว่างแผนกเป็นอย่างดี
เลือกได้ดี. แต่ถ้าเลือกไม่ถูกล่ะ? จากนั้นความสามารถในการเปลี่ยนแปลงจะหมดลงอย่างรวดเร็ว และคุณจะต้องทำใหม่ทั้งระบบ สิ่งนี้ต้องทำเป็นครั้งคราว คุณไม่สามารถทำนายอนาคตได้ แต่คุณรักษาจำนวนการทำซ้ำให้น้อยที่สุดได้
หลักการของนามธรรม
การเลือกวิธีการจัดโครงสร้างแผนกและวิธีการโต้ตอบคือ " หลักการของสิ่งที่เป็นนามธรรม " ในการเขียนโปรแกรม มันถูกใช้เพื่อกำหนดวิธีที่ดีที่สุดในการแบ่งโปรแกรมออกเป็นส่วนๆ และวิธีที่ส่วนเหล่านั้นควรโต้ตอบ เราสามารถนำหลักการนี้ไปใช้ใหม่ได้ โดยแบ่งส่วนที่เป็นผลลัพธ์ออกเป็นส่วนๆ จนกว่าเราจะแบ่งโปรแกรมออกเป็นแต่ละคลาส
การซ่อนโครงสร้างภายในของส่วนเหล่านี้และการจำกัดปฏิสัมพันธ์กับส่วนอื่นๆ อย่างเข้มงวดถือเป็นการห่อหุ้ม การห่อหุ้มและนามธรรมเป็นรากฐานที่สำคัญของOOP โปรแกรมที่ดีต้องเป็นไปตามสองหลักการนี้ ในอนาคต เราจะพิจารณาหลักการที่เหลือและสำรวจว่าหลักการเหล่านี้ให้ประโยชน์อะไรบ้าง