Modular Reuse Before Classes (การใช้ซ้ำแบบโมดูลาร์ก่อนยุคของคลาส)

นักพัฒนาที่เติบโตมาก่อนยุคภาษาเชิงวัตถุอาจสงสัยว่าทำไมถึงมีรูปแบบการแบ่งแยกมากมายขนาดนี้ เหตุผลส่วนใหญ่เกี่ยวข้องกับความเข้ากันได้ย้อนหลัง (backward compatibility)—ไม่ใช่ของโค้ด แต่ของวิธีคิดของนักพัฒนา

ในเดือนมีนาคม 1968 วารสาร Communications of the Association for Computing Machinery (ACM) ได้ตีพิมพ์บทความของนักวิทยาศาสตร์คอมพิวเตอร์ Edsger Dijkstra ชื่อ “Go To Statement Considered Harmful” เขาวิพากษ์วิจารณ์การใช้คำสั่ง GOTO ที่พบได้ทั่วไปในภาษาโปรแกรมสมัยนั้น เพราะมันทำให้เกิดการกระโดดข้ามโค้ดแบบไม่เป็นเส้นตรง (nonlinear) ซึ่งทำให้การให้เหตุผลและการ debug ยากขึ้น

บทความของ Dijkstra ช่วยเปิดยุคของภาษาโปรแกรมแบบ structured ในช่วงกลางทศวรรษ 1970 ตัวอย่างเช่น Pascal และ C ซึ่งกระตุ้นให้คิดให้ลึกขึ้นว่าสิ่งต่าง ๆ ประกอบกันอย่างไร นักพัฒนาไม่นานก็ตระหนักว่าภาษาโปรแกรมส่วนใหญ่ยังไม่มีวิธีที่ดีในการจัดกลุ่มสิ่งที่คล้ายกันไว้ด้วยกันในเชิงตรรกะ ดังนั้น ยุคสั้น ๆ ของภาษาแบบ modular จึงถือกำเนิดขึ้นในช่วงกลางทศวรรษ 1980 เช่น Modula (ภาษาถัดไปของ Niklaus Wirth ผู้สร้าง Pascal) และ Ada ภาษาเหล่านี้โอบรับ construct ของ module ซึ่งใกล้เคียงกับสิ่งที่เราคิดว่าเป็น package หรือ namespace ในปัจจุบัน (แต่ไม่มีคลาส)

อย่างไรก็ตาม ยุคของ modular programming ในกลางทศวรรษ 1980 อยู่ได้ไม่นาน เพราะภาษาเชิงวัตถุเริ่มได้รับความนิยมและมอบวิธีใหม่ในการห่อหุ้ม (encapsulate) และใช้โค้ดซ้ำ กระนั้น ผู้ออกแบบภาษาก็ตระหนักถึงประโยชน์ของ module และยังคงเก็บมันไว้ในรูปแบบของ package และ namespace หลายภาษายังคงมีฟีเจอร์เพื่อความเข้ากันได้ที่ดูแปลกในปัจจุบัน แต่ถูกนำมาใช้เพื่อรองรับ paradigm ที่ต่างกันเหล่านี้ ตัวอย่างเช่น Java รองรับ paradigm แบบ modular (ผ่าน package และการ initialize ระดับ package ด้วย static initializer) รวมถึง paradigm เชิงวัตถุและเชิงฟังก์ชัน ซึ่งแต่ละแบบก็มีกฎ scoping และความแปลกประหลาดของตัวเอง

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

ควรกล่าวถึงแนวคิดทั่วไปของ namespace ซึ่งแยกออกจากการ implement ทางเทคนิคในแพลตฟอร์ม .NET ที่ก็เรียกว่า namespace เช่นกัน นักพัฒนามักต้องการชื่อที่แม่นยำและมีคุณสมบัติครบถ้วน (fully qualified) สำหรับสินทรัพย์ซอฟต์แวร์ต่าง ๆ (component, class และอื่น ๆ) เพื่อแยกแยะสิ่งเหล่านั้นออกจากกัน ตัวอย่างที่ชัดเจนที่สุดที่ผู้คนใช้กันทุกวันคืออินเทอร์เน็ต ซึ่งพึ่งพา identifier ที่ไม่ซ้ำกันในระดับ global ที่ผูกกับ IP address

ภาษาส่วนใหญ่มีกลไกความเป็นโมดูลบางอย่างที่ทำหน้าที่เป็น namespace ไปในตัวเพื่อจัดระเบียบสิ่งต่าง ๆ อย่าง variable, function หรือ method บางครั้งโครงสร้าง module ก็สะท้อนออกมาทางกายภาพด้วย เช่น โครงสร้าง package ของ Java ต้องสะท้อนโครงสร้างไดเรกทอรีของไฟล์คลาสจริง ๆ