ตัวอย่างที่ดีของ a cross-cutting concernคืออะไร? ตัวอย่างเวชระเบียนในหน้าวิกิพีเดียดูเหมือนจะไม่สมบูรณ์สำหรับฉัน
โดยเฉพาะจากตัวอย่างนี้เหตุใดการบันทึกจึงนำไปสู่การทำซ้ำรหัส ( การกระจาย ) (นอกเหนือจากการโทรธรรมดาเช่นlog("....")ทุกที่ซึ่งดูเหมือนจะไม่ใช่เรื่องใหญ่)
อะไรคือความแตกต่างระหว่าง a core concernและ a cross-cutting concern?
เป้าหมายสุดท้ายของฉันคือการทำความเข้าใจเกี่ยวกับ AOP ให้ดีขึ้น
คำตอบ:
ก่อนที่จะทำความเข้าใจความกังวลกรุยทางเราจะต้องเข้าใจความกังวล
กังวลเป็นคำที่หมายถึงส่วนหนึ่งของระบบแบ่งบนพื้นฐานของการทำงานที่
ความกังวลมีสองประเภท:
ตัวเลขนี้แสดงถึงแอปพลิเคชันทั่วไปที่แยกย่อยออกเป็นโมดูล ข้อกังวลหลักของแต่ละโมดูลคือการให้บริการสำหรับโดเมนเฉพาะ อย่างไรก็ตามแต่ละโมดูลเหล่านี้ยังต้องการฟังก์ชันเสริมที่คล้ายคลึงกันเช่นการบันทึกความปลอดภัยและการจัดการธุรกรรม ตัวอย่างของความกังวลในการตัดขวางคือ "การบันทึก" ซึ่งมักใช้ในแอปพลิเคชันแบบกระจายเพื่อช่วยในการแก้ไขข้อบกพร่องโดยการติดตามการเรียกใช้เมธอด สมมติว่าเราทำการบันทึกที่จุดเริ่มต้นและจุดสิ้นสุดของแต่ละฟังก์ชัน ซึ่งจะส่งผลให้เกิดการตัดขวางคลาสทั้งหมดที่มีอย่างน้อยหนึ่งฟังก์ชัน
ฉันคิดว่าตัวอย่างเดียวที่ดีที่สุดของความกังวลข้ามการตัดทอนคือพฤติกรรมการทำธุรกรรม ตัวอย่างเช่นการต้องวางบล็อก try-catch โดยมีการส่งคอมมิตและการโทรย้อนกลับในวิธีการบริการทั้งหมดของคุณจะเป็นการขับไล่ การใส่คำอธิบายประกอบวิธีการด้วยเครื่องหมายที่ AOP สามารถใช้เพื่อห่อหุ้มด้วยลักษณะการทำธุรกรรมที่ต้องการถือเป็นชัยชนะที่ยิ่งใหญ่
ผู้สมัครที่ดีอีกคนหนึ่งที่เป็นตัวอย่างของข้อกังวลข้ามเรื่องคือการอนุญาต การใส่คำอธิบายประกอบวิธีการบริการด้วยเครื่องหมายที่บอกว่าใครสามารถเรียกมันได้และการให้คำแนะนำของ AOP บางส่วนตัดสินใจว่าจะอนุญาตให้เรียกใช้เมธอดหรือไม่นั้นดีกว่าที่จะจัดการวิธีนั้นในรหัสวิธีการบริการ
การใช้การบันทึกด้วยคำแนะนำ AOP อาจเป็นวิธีที่ช่วยให้มีความยืดหยุ่นมากขึ้นเพื่อให้คุณสามารถเปลี่ยนแปลงสิ่งที่จะบันทึกได้โดยการเปลี่ยนจุดเชื่อมต่อ ในทางปฏิบัติฉันไม่เห็นโครงการที่ทำบ่อยนัก โดยปกติแล้วการใช้ไลบรารีเช่น log4j ที่ให้คุณกรองตามระดับการบันทึกและหมวดหมู่ในขณะรันไทม์หากคุณต้องการจะทำงานได้ดีเพียงพอ
ข้อกังวลหลักคือสาเหตุที่แอปพลิเคชันมีอยู่ตรรกะทางธุรกิจที่แอปพลิเคชันทำงานโดยอัตโนมัติ หากคุณมีแอปพลิเคชันโลจิสติกส์ที่จัดการการขนส่งสินค้าการหาจำนวนสินค้าที่คุณสามารถบรรจุบนรถบรรทุกได้หรือเส้นทางใดที่ดีที่สุดสำหรับรถบรรทุกในการส่งมอบอาจเป็นปัญหาหลัก โดยทั่วไปแล้วความกังวลข้ามการตัดทอนเป็นรายละเอียดการใช้งานที่ต้องแยกออกจากตรรกะทางธุรกิจ
นอกเหนือจากคำตอบที่ได้รับการยอมรับแล้วฉันยังต้องการพูดถึงอีกตัวอย่างหนึ่งสำหรับข้อกังวลข้ามเรื่อง: การไกล่เกลี่ย สมมติว่าฉันแค่ต้องการเรียกส่วนประกอบอื่น ๆ ในระบบนิเวศของฉันในเครื่องราวกับว่ากำลังทำงานอยู่ในกระบวนการ บางทีในบางกรณีพวกเขาก็ทำ แต่ตอนนี้ฉันต้องการเรียกใช้บริการของฉันแบบกระจายในคลาวด์หรือคลัสเตอร์ เหตุใดฉันจึงควรสนใจด้านนี้ในฐานะนักพัฒนาแอปพลิเคชัน แง่มุมสามารถดูแลในการค้นหาว่าใครโทรมาและทำอย่างไรโดยจัดลำดับข้อมูลที่ส่งหากจำเป็นและทำการโทรจากระยะไกล หากทุกอย่างกำลังดำเนินการอยู่ด้านนั้นก็จะส่งต่อการโทรในพื้นที่ ในด้าน callee แง่มุมจะยกเลิกการกำหนดค่าข้อมูลทำการโทรในพื้นที่และส่งคืนผลลัพธ์
ตอนนี้ให้ฉันเล่าเรื่องเล็กน้อยเกี่ยวกับสิ่งที่ "เล็กน้อย" เช่นเอาต์พุตบันทึก: เมื่อไม่กี่สัปดาห์ที่ผ่านมาฉันได้ปรับโครงสร้างโค้ดที่ซับซ้อน แต่ไม่ใหญ่เกินไป (โค้ดประมาณ 250K บรรทัด) สำหรับไคลเอ็นต์ มีการใช้กรอบการบันทึกประเภทหนึ่งในคลาสสองสามร้อยคลาสในอีกสองสามร้อยคลาส จากนั้นก็มีหลายพันบรรทัดSystem.out.println(*)ที่ซึ่งควรเป็นเอาต์พุตบันทึกจริงๆ ดังนั้นฉันจึงลงเอยด้วยการแก้ไขโค้ดหลายพันบรรทัดที่กระจัดกระจายไปทั่วฐานรหัส โชคดีที่ฉันสามารถใช้กลเม็ดอันชาญฉลาดใน IntelliJ IDEA (การค้นหาและแทนที่โครงสร้าง) เพื่อเร่งการดำเนินการทั้งหมด แต่คุณไม่คิดว่ามันเป็นเรื่องเล็กน้อย! แน่นอนว่าการบันทึกการดีบักที่ขึ้นอยู่กับบริบทอย่างมากจะเกิดขึ้นภายในเนื้อความของวิธีการเสมอ แต่การบันทึกที่สำคัญหลายประเภทเช่นการเรียกใช้เมธอดการติดตาม (แม้กระทั่งตามลำดับชั้นด้วยเอาต์พุตที่เยื้องอย่างดี) การบันทึกทั้งข้อยกเว้นที่จัดการหรือไม่ได้จัดการการตรวจสอบผู้ใช้ (การบันทึกการโทรไปยัง วิธีการที่ จำกัด ตามบทบาทของผู้ใช้) และอื่น ๆ สามารถนำไปใช้ในแง่มุมต่างๆได้อย่างง่ายดายโดยที่พวกเขาไม่ก่อให้เกิดมลพิษต่อซอร์สโค้ด นักพัฒนาแอปพลิเคชันในชีวิตประจำวันไม่จำเป็นต้องคิดถึงเรื่องนี้หรือแม้แต่เห็นการโทรของคนตัดไม้ที่กระจัดกระจายไปตามฐานรหัส
ฉันสามารถหาคำอธิบายที่คล้ายกันสำหรับข้อกังวลข้ามเรื่องอื่น ๆ การรักษารหัสให้สะอาดและปราศจากการกระจัดกระจายและการพันกันของ IMO เป็นเรื่องของความเป็นมืออาชีพไม่ใช่ทางเลือกใด ๆ สุดท้าย แต่ไม่ท้ายสุดมันช่วยให้โค้ดสามารถอ่านได้บำรุงรักษาและเปลี่ยนสภาพได้ สาธุ
ความกังวลเกี่ยวกับการตัดขวางเป็นสถานการณ์ที่ควรมีอยู่เสมอโดยไม่คำนึงถึงประเภทของการใช้งาน
ตัวอย่างเช่น Logging, Security, Performance Profiling, Localization, Accessibility, Transaction เป็นต้นโดยไม่คำนึงถึงซอฟต์แวร์ที่เรากำลังสร้างการบันทึกเป็นสิ่งจำเป็น (มิฉะนั้นจะมีการดีบักหรือรับข้อมูลที่เกี่ยวข้องจากข้อมูล prod อย่างไร) จำเป็นต้องมีการรักษาความปลอดภัย (การพิสูจน์ตัวตน / การอนุญาต ฯลฯ ) ซึ่งมีเพียงผู้ใช้ที่แท้จริงเท่านั้นที่สามารถเข้าสู่แอปพลิเคชันด้วยชุดสิทธิ์ที่เหมาะสม เราจำเป็นต้องรู้ว่าแอปพลิเคชันของคุณทำงานเป็นอย่างไรจากนั้นเราต้องทำโปรไฟล์ ในกรณีที่ผู้ใช้ต่างประเทศใช้แอปพลิเคชัน (ด้วยภาษาท้องถิ่นของตนเอง) เราจำเป็นต้องสนับสนุนแอปพลิเคชันเดียวกันนี้ การช่วยสำหรับการเข้าถึงคือกรณีการใช้งานสำหรับผู้พิการในการใช้แอปพลิเคชันของเรา
ตอนนี้ไม่ว่าแอปพลิเคชันของเราจะทำงานบนเดสก์ท็อปหรือเว็บอื่น ๆ หากจำเป็นต้องใช้โดยผู้ใช้ปลายทางในสภาพแวดล้อมทางภูมิศาสตร์ในสภาพแวดล้อมการผลิตจำเป็นต้องมีการตัดต่อ จนถึงตอนนี้ฉันยังไม่ได้พูดอะไรเกี่ยวกับแอปพลิเคชันอื่น ๆ แต่ให้รายการข้อกังวลที่ควรได้รับการแก้ไขก่อนปล่อยให้ผู้ใช้ปลายทางในสภาพแวดล้อมการผลิต และนั่นคือทั้งหมดที่เกี่ยวกับความกังวลแบบ cross cut (ซึ่งต้องได้รับการจัดการโดยแอปพลิเคชัน / วิธีการ / คลาสเช่นในระดับต่างๆ)