มีทางเลือกอะไรอีกบ้างสำหรับการตัดขวางที่เกี่ยวข้องกับการเขียนโปรแกรมอื่น ๆ [ปิด]

การเขียนโปรแกรมที่มุ่งเน้นด้านการสัญญาว่าจะจัดการกับความกังวลข้าม แต่ฉันยังไม่ได้ขายอย่างสมบูรณ์ในนั้น มีความพยายามอื่น ๆ ที่จะจัดการกับปัญหานี้หรือไม่?

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

แม้ว่ามันจะไม่ได้ผลอย่างสวยงามเสมอไป นั่นคือเหตุผลที่ผู้คนพยายามแก้ไขปัญหากับสิ่งต่าง ๆ เช่น AOP

อีกสองตัวเลือกที่ฉันยังไม่ได้สำรวจ:

ฟังก์ชั่นการเขียนโปรแกรมด้วย Monads และ Arrows

ใน FP คุณแสดงถึงความกังวลใจอย่างอื่นเช่นสิ่งที่คุณส่งผ่านไปในการเรียกใช้ฟังก์ชัน เนื่องจากการทำเช่นนั้นทำให้คุณเบื่อหน่ายอย่างชัดเจนคุณสามารถใช้ Monads (หรือลูกศร) เพื่อซ่อนข้อมูลเพิ่มเติมที่ถูกส่งผ่านไป

ตัวอย่าง AOP ที่พบบ่อยที่สุดคือการบันทึก ด้วย Monads คุณจะต้องสร้าง Monad "Logger" ที่เก็บรายการข้อความไว้ ฟังก์ชั่นใด ๆ ที่คุณทำผ่าน LoggerMonad มีความสามารถในการโพสต์ข้อความบันทึก ด้วย Arrows คุณจะทำโมเดลโฟลว์ข้อมูลทั้งหมดของแอ็พพลิเคชันและจะทำรูทีนการบันทึกลงในโมเดลตามความเหมาะสม ฉันคิด. ลูกศรค่อนข้างซับซ้อน

การเขียนโปรแกรมตามเอนทิตี / ส่วนประกอบ

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

วิธีการทั้งสองนี้ช่วยให้การเปลี่ยนแปลงข้ามตัดทำได้ง่ายมากอย่างง่ายดาย แต่ทั้งสองเป็นแบบจำลองสถาปัตยกรรมระดับสูง ดังนั้นคุณอาจต้องใช้มันตั้งแต่ต้น แบบจำลองทางทฤษฎีสามารถทำงานในระบบ OOP ที่มีอยู่แล้ว ฉันคิดว่าพระอาจจะเกินไปถ้าภาษาของคุณมีพลังมากพอ

มีหลายวิธีในการจัดการปัญหาการตัดขวางข้อกังวล:

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

• พัฒนาคุณสมบัติภาษาที่สมบูรณ์ยิ่งขึ้น : การแสดงออกที่หลากหลายของการตัดขวางสามารถแก้ไขได้ด้วยกลไกที่เป็นนามธรรมที่ดีกว่าและบางครั้งจำเป็นต้องใช้คุณสมบัติภาษาใหม่ ตัวอย่างเช่นภาษาขั้นสูงที่มีฟังก์ชั่นการใช้งานและคุณสมบัติเชิงวัตถุมักจะไม่ใช้รูปแบบการออกแบบมากนักเพราะไม่จำเป็น โปรดทราบว่ารูปแบบการออกแบบสามารถข้ามไปมาได้เนื่องจากลักษณะเหล่านี้อธิบายถึงบทบาทของวัตถุและคลาสที่แตกต่างกันหลายอย่าง ใน Java การสะท้อนสามารถนำมาใช้แทนการใช้มุมมองได้แม้ว่าจะมีค่าใช้จ่ายรันไทม์ที่สูงขึ้น ตัวอย่างเช่นการใช้การสะท้อนคุณสามารถสนับสนุนรูปแบบผู้เข้าชมมากกว่าหลายร้อยชั้นด้วยรหัสเพียงไม่กี่บรรทัด ห้องสมุดดีเจจากภาคตะวันออกเฉียงเหนือเป็นวิธีแก้ปัญหาหนึ่งที่ทำเช่นนั้น มิกซ์อินเป็นเทคนิคที่ทรงพลังที่มีอยู่ใน C ++ (แต่ไม่ใช่จาวา) และสามารถให้เคสการใช้งานเดียวกันกับคุณได้

• ให้การสนับสนุนเครื่องมือที่ดีกว่า : เทคนิคเช่นการใช้grepและการดำเนินการ refactoring สามารถจัดการกับปัญหาที่เกี่ยวข้องกับรหัส crosscutting ตัวอย่างเช่นชื่อของวิธีการที่ประกาศในอินเตอร์เฟสสามารถตัดข้ามโปรแกรมได้ (สังเกตความแตกต่างทางเทคนิคที่นี่: มันเป็นชื่อของวิธีการไม่ใช่วิธีการนำไปใช้, crosscuts นั้น) ซึ่งมักจะไม่มีปัญหาใน IDE เช่น Eclipse ซึ่งคุณสามารถใช้ "เปลี่ยนชื่อ refactoring" เพื่อเปลี่ยนทั้งหมดของ สถานที่ในรหัสของคุณที่ใช้ชื่อ ด้วยวิธีนี้เป็นไปได้ที่จะไม่ต้องใช้คุณสมบัติภาษาเมื่อสภาพแวดล้อมการเขียนโปรแกรมแสดงออกมาเพียงพอสำหรับคุณ

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

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

สำหรับสิ่งเหล่านี้ฉันคิดว่าการศึกษา AOP นั้นเหมาะสม AOP สามารถช่วยคุณขยายแนวคิดเกี่ยวกับโค้ดแม้ว่าคุณจะไม่ได้ใช้ภาษา AOP

ในองค์ประกอบรหัสการแท็กทั่วไปที่มีคุณสมบัติการประกาศแต่โดยเฉพาะระบบแอตทริบิวต์ในโลก C # /. NET / Mono

ฉันไม่มีความเชี่ยวชาญใน AOP แต่จากการอ่านเกี่ยวกับเรื่องนี้ในช่วงหลายปีที่ผ่านมาดูเหมือนว่ารูปแบบmetaprogramming ที่อ่อนแอกว่าที่Lisp เสนอมักจะอ่อนแอกว่าโดยเฉพาะส่วนต่างๆเช่นโปรโตคอล metaobject

สิ่งนี้ไม่น่าแปลกใจเลยฉันคิดว่า: Gregor Kiczales เป็นหนึ่งในผู้แต่ง AMOP และต่อมาก็เขียน AspectJ สำหรับ Java!