ผมเลือกที่จะอธิบาย Comprehensibility ที่สะท้อนออกมาจาก Groovy AOP เมื่อใช้งานกับ Grails เลยแปลงานตัวเองแล้วนำมาให้อ่านกันครับ
การใช้ Groovy AOP เพื่ออธิบายตรรกเชิงธุรกรรมในเกรลส์
เอกสารชิ้นนี้อธิบายปัญหาที่พบเมื่อนำ Groovy AOP ไปใช้กับเฟรมเวิร์คเกรลส์ซึ่งสะท้อน สมบัติ Comprehensibility
ในเฟรมเวิร์คเกรลส์นั้นมีองค์ประกอบ (artefact) ระดับสูง(ที่มีความหมายเชิงนามธรรมสูงกว่าคลาส) หลาย ๆ อย่างเช่น ตัวควบคุม (Controller) หรือ โดเมนคลาส เป็นต้น ภาษา AOP ที่จะนำไปใช้กับเกรลส์นั้นจำเป็นที่จะต้องสนับสนุนการประกาศ pointcut ระดับที่สูงขึ้นเพื่อใช้อธิบายองค์ประกอบเหล่านั้น นอกจากนี้ เกรลส์สนับสนุนการพัฒนาส่วนขยายผ่านระบบปลั๊กอิน และนักพัฒนาก็สามารถนิยามองค์ประกอบเพิ่มขึ้นมาในปลั๊กอินที่พัฒนาขึ้นใหม่ได้ ดังนั้นภาษา AOP จึงจำเป็นที่จะต้องมีความสามารถในการพัฒนาส่วนขยายเช่นกัน เพื่อให้รองรับจุดร่วม (join point) ที่เพิ่มเข้ามาจากองค์ประกอบเหล่านั้น
ยกตัวอย่างเช่น ในปัจจุบัน Groovy AOP สนับสนุน pointcut พื้นฐานดังเช่น:
- pcall(pattern)
- etc.
แต่ pointcut เหล่านี้ไม่ได้สะท้อนความหมายขององค์ประกอบในเกรลส์ ซึ่งนักพัฒนาจะต้องการ pointcut เช่น:
- controller(pattern)
- action(pattern)
- etc.
ต่อไปนี้คือตัวอย่างของเวบแอพพลิเคชั่นที่เขียนด้วยเกรลส์
class BookController {
def list = {
def books = Book.list()
render(view:'book', model:[books: books])
}
def show = {
...
}
def update = {
...
}
}และนี่คือ aspect ที่เขียนด้วย Groovy AOP:
aspect SecurityAspect {
def pc = pcall('BookController.*')
around(pc) {
// check access
}
}และ aspect ต่อไปนี้เขียนด้วย Groovy AOP และใช้ pointcut ระดับสูงขึ้น (เพื่อจับความหมายของ ตัวควบคุม และ action):
aspect SecurityAspect {
def pc = controller('book') & action('*')
around(pc) {
// check access
}
}ตัวอย่างถัดมาคือ aspect เขียนด้วยไวยากรณ์อีกแบบของ Groovy AOP ด้วย pointcut ระดับสูงเช่นกัน แต่ไม่มีการนิยาม poincut แยก (ใช้แบบย่อ) ซึ่งแนวทางไวยากรณ์แบบนี้นำมาจากลักษณะภาษาที่นักพัฒนาเกรลส์คุ้นเคย
aspect SecurityAspect {
around(controller:'book', action:'*') {
// check access
}
}และนอกจากนี้ Groovy AOP ควรสนับสนุนความสามารถในการขยายระบบเพื่อให้ครอบคลุมองค์ประกอบซอฟต์แวร์ใหม่ ๆ ที่อาจเพิ่มเข้ามาได้ผ่านทางระบบปลั๊กอินของเกรลส์
บทสรุป
Groovy AOP นั้นสามารถปรับใช้งานกับเฟรมเวิร์คเกรลส์ได้เนื่องจากตัวมันเป็นระบบ AOP เอนกประสงค์สำหรับภาษากรูวี่ ตัว Groovy AOP สามารถใช้อธิบายตรรกะเชิงธุรกรรมได้ในรูปของ ลักษณะระดับแอพพลิเคชั่น อย่างไรก็ตาม ตัวเฟรมเวิร์คเกรลส์นั้นมีความเป็นพลวัตรสูงและนักพัฒนาสามารถเพิ่มองค์ประกอบซอฟต์แวร์ได้ด้วยการสร้างปลั๊กอินตัวใหม่ เพื่อให้ระบบ AOP รองรับกับความต้องการนี้ ตัวระบบควรมีความสามารถรองรับการนิยาม pointcut ในลักษณะเดียวกันกับสถาปัตยกรรมปลั๊กอิน
ตัวอย่างในบทความนี้สะท้อน Comprehensibility อย่างไร
- เพื่อให้ภาษา AOP เพิ่มความเข้าใจให้กับนักพัฒนา
ตัวระบบควรใช้ภาษาที่นักพัฒนาคุ้นเคย (โดยอ้างอิงจากภาษาหลัก หรือ เฟรมเวิร์คที่ระบบ AOP จะเข้าไปจัดการ)
- เพื่อสนับสนุนความสามารถในการเปลี่ยนแปลงและปรับแต่ง
ระบบควรเปิดช่องทางให้สามารถนิยาม PCD ใหม่ ๆ ได้
- AOSD สนับสนุน Comprehensibility ดีแค่ไหน อย่างไร ?
ขึ้นกับการอิมพลีเม้นต์และภาษาหลัก (เช่น Java / AspectJ, Groovy / Groovy AOP)
อย่างไรก็ตามในปัจจุบัน Groovy AOP ยังไม่สนับสนุนสมบัติข้อดีได้ดีพอ
