สรุปนิยามการโปรแกรมเชิงลักษณะ 2552

Aspect-oriented programming หรือ AOP หรือที่ผมเรียกเป็นภาษาไทยว่า การโปรแกรมเชิงลักษณะ นั้นเป็นแนวคิดที่สร้างขึ้นบนการโปรแกรมเชิงวัตถุหรือ OOP (หรืออาจจะบนการโปรแกรมเชิงโครงสร้างก็ได้) โดยมีจุดประสงค์หลักเพื่อแก้ปัญหาที่ยากหรือแก้ไม่ได้ด้วย OOP ในแง่ของการแยกความเกี่ยวพัน(Separation of Concerns) ซึ่งความเกี่ยวพันที่ว่าก็คือ ความเกี่ยวพันเชิงขวาง (Croscutting Concerns) ที่ ตัดในแนวขวางของการไหลของโปรแกรม (Flow of Program) แนวคิดของ AOP คือการดึงโค้ดที่กระจายตัวในลักษณะตัดขวางเหล่านั้นมารวบไว้ด้วยกันเป็น หน่วย เรียกว่า aspect (ลักษณะ) โดยภายใน aspect จะประกอบไปด้วย pointcut ซึ่งเป็นประโยคอธิบายจุดนามธรรมที่เรียกว่า join point abstraction สำหรับ join point ก็คือจุดที่นิยามไว้ชัดเจน (well-defined points) ในการไหลของโปรแกรมอย่างเช่น constructor, method เป็นต้น ในการประกาศ pointcut จะมีการโยงเข้ากับโค้ดที่ต้องการให้ทำงานในจุดเหล่านั้น โค้ดดังกล่าวเรียกว่า advice code และจะสามารถระบุได้ว่า advice ที่ต้องการจะสาน (weave) ไปอยู่ในตำแหน่งใดของ join point เช่น before, around, after ซึ่งเรียกเป็นชนิดของ advice

ด้านล่างจะเป็นนิยามที่ผมแปลและเรียบเรียงจากหลาย ๆ ที่เพื่อเสริมความเข้าใจ

---

การโปรแกรมเชิงลักษณะ (Aspect-oriented programming) หรือ AOP เป็นกระบวนทัศน์หนึ่งของการเขียนโปรแกรมที่เพิ่มความเป็นโมดูลโดยอนุญาตให้แยกความเกี่ยวพันเชิงขวางได้

การแยกความเกี่ยวพัน เป็นการแบ่งย่อยโปรแกรมเป็นแต่ละส่วน ๆ ที่แยกจากกันโดยเด็ดขาด ซึ่งเรียกว่าความเกี่ยวพัน โดยเป็นบริเวณที่เกาะกลุ่มกันตามหน้าที่การทำงาน ทุก ๆ กระบวนทัศน์ของการเขียนโปรแกรมจะสนับสนุนการรวมกลุ่มหรือห่อความเกี่ยวพันอย่างน้อย ๆ ในระดับหนึ่งเสมอ โดยจะรวบความเกี่ยวพันเป็นหน่วยที่แยกจากกันและมีนามธรรมเพื่อนิยามหน่วยนั้น ๆ เช่น procedure, module, class, method และนามธรรมดังกล่าวก็จะเป็นตัวแทนของความเกี่ยวพันเหล่านั้น อย่างไรก็ตาม มีความเกี่ยวพันบางชนิดที่ไม่เป็นไปตามที่นิยามข้างต้น จึงไม่สามารถจะรวบเป็นหน่วยได้ด้วยนิยามเหล่านั้น เช่นกลุ่มความเกี่ยวพันเชิงขวาง (crosscutting concerns) เพราะ ความเกี่ยวพันประเภทนี้ "ตัดผ่านในแนวขวาง" กับหน่วยนามธรรมประเภทอื่นในโปรแกรมหนึ่ง ๆ

แปลและเรียบเรียงจาก Wikipedia

---

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

แปลและเรียบเรียงจากบทคัดย่อของงานตีพิมพ์ปี 1997 ของ เกรเกอร์ คิกซาเลส และคณะ

---

สำหรับบทความบน Onjava.com ของ Graham O'Regan ที่เขียนไว้เมื่อปี 2004 นั้น (ค้น Google ด้วยคำว่า aspect-oriented programming แล้วอยู่อันดับ 3) มีหลายท่านอ่านแล้วบอกว่าเข้าใจง่าย แต่ด้วยแนวคิดแล้วนั้นออกจะผิดหลุดกรอบหลักของ AOP ไปมาก โดยไปเน้นการแก้ไขโปรแกรมแบบไดนามิค (เปลี่ยนความหมายของโปรแกรมขณะรัน) แทนที่จะพูดถึงแนวคิดตัดขวางซึ่งเป็นพื้นฐานของ AOP

"Aspect-Oriented Programming (AOP) complements OO programming by allowing the developer to dynamically modify the static OO model to create a system that can grow to meet new requirements. Just as objects in the real world can change their states during their lifecycles, an application can adopt new characteristics as it develops." (ตัวหนาเน้นโดยผม)

ซึ่งพอจะพูดได้ว่าบทความนี้เป็นต้นเหตุแห่งความเข้าใจ AOP ผิด ๆ ของยุคหลังปี 2000 เลยทีเดียว

การศึกษาความหมายของ proceed

ตอนนี้ผมพยายามที่จะศึกษา formal definition ของภาษา AOP โดยใช้ภาษา MiniMAO ของ Clifton และ Leavens เป็นเครื่องมือช่วย MiniMAO0 เป็น base language (ภาษาฐาน) มีข้อดีคือเป็น calculus ขนาดเล็กสุดที่ใช้อธิบายภาษาเชิงวัตถุได้ โดยลดรูปลงมาจาก Java ในแง่มุมเดียวกับ FGJ แต่ MiniMAO0 มีจุดพิเศษเพราะแยกความหมาย (semantics) ของ call และ execution ออกจากกัน เพื่อให้สะท้อนความหมายของ join point ให้ได้ดีขึ้นกว่าภาษาอื่น ๆ เช่น FGJ เป็นต้น

เป้าหมายก็คือทำความเข้าใจความหมายของ proceed ผ่านทาง MiniMAO1 ซึ่งเป็นส่วนขยายภาษาเชิงลักษณะของ MiniMAO0 แล้วนิยามความหมายของ parproceed เพื่อการทำงานเชิงขนาน

สำหรับผู้สนใจผมอธิบายแนวคิดของ parproceed เบื้องต้นไว้ใน paper ของ VMIL workshop ปี 2007 ชื่อ A Distributed Dynamic Aspect Machine for Scientific Software Development

การใช้ Groovy AOP เพื่ออธิบายตรรกเชิงธุรกรรมในเกรลส์

เนื่องจากผมจะไปร่วมการประชุม AOSD '08 และไปนำเสนองานวิจัยใน SLAT 2008 workshop วันนี้ได้รับการบ้านมาหนึ่งชิ้นจากผู้จัด workshop โดยให้เตรียมการอธิบายสถานการณ์ในการพัฒนาซอฟต์แวร์ที่เจอมา ว่าการพัฒนาซอฟต์แวร์เชิงลักษณะเกี่ยวข้องกับสมบัติทางวิศวกรรมซอฟต์แวร์เชิงคุณภาพ (เลือกมา 1 ตัว) อย่างไร

ผมเลือกที่จะอธิบาย 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 ยังไม่สนับสนุนสมบัติข้อดีได้ดีพอ

ภาษา AOP ที่ใกล้ตัวเรามากที่สุด

เคยนั่งคิดเล่น ๆ กันมั้ยครับว่าภาษา AOP ที่เราใช้กันมากที่สุด คือภาษาอะไรและอยู่ในแอพพลิเคชั่นประเภทใด

ภาษา AOP ที่เราใช้กันมากที่สุดก็คือ CSS ครับ และแน่นอนว่าอยู่ใน web browser นั่นเอง

CSS จะประกอบไปด้วยสองส่วนคือ selectors และ declaration block ถ้ามองจากมุมมองของ AOP แล้วก็เหมือนกับว่า CSS จะอิมพลีเม้นต์ pointcut-advice model โดยที่มี selectors เป็น pointcut และ declaration block เป็น around advice นั่นแปลว่าใน CSS ไม่มี advice model แบบ before, after และอื่น ๆ ครับ

ตัวอย่าง aspect อย่างง่าย

ในโพสต์นี้ผมแนะนำตัวอย่าง aspect ที่น่าจะเข้าใจได้ไม่ยากนักสำหรับการเริ่มต้นหัดเขียน AOP
โจทย์คือ "สร้าง aspect สำหรับจับเวลาให้เมธอดในคลาส Target" ครับ

1. ให้สร้่าง aspect เป็นชื่อ TimeMeasurement ตั้ง package เป็นอะไรก็ได้ เช่น net.ckblog.aspect.TimeMeasurement จะได้ไฟล์ชื่อ TimeMeasurement.aj ซึ่งจะคอมไพล์ได้ด้วยตัวคอมไพเลอร์ของ AspectJ
2. ให้สร้างคลาส ชื่อ Target อาจจะเป็น net.ckblog.Target แล้วให้มี 2 เมธอด ชื่อ compute1000() กับ compute2000() แล้วลองเขียนโค้ดให้วนรอบใน 2 เมธอดนั้น 1000 รอบ และ 2000 รอบ ตามลำดับ
จากนั้นให้เตรียมคลาส Main เพื่อสร้าง object ของ Target แล้วทำการเรียกใช้ทั้งสองเมธอดดังกล่างใน main()
3. กลับมาที่ aspect TimeMeasurement ให้ประกาศ pointcut โดยเราจะใช้ pointcut designator (PCD) ชื่อ execution() ในการเลือก join point 2 จุด ณ ตำแหน่งการทำงานของเมธอด ของ compute1000() และ compute2000()
ซึ่งเหตุผลในการใช้ PCD มาจากวิธีคิดแบบนี้ครับ
- การทำงานของเมธอด คือ execution of method (ต่างจากการเรียกใช้ คือ call)
- นั่นคือความหมายของ PCD ชื่อ execution(...) (ถ้าเป็นการเรียกใช้ก็จะเป็น PCD ชื่อ call())
และเป้าหมายของเราคือเมธอด compute1000() และ compute2000
จะได้ pointcut ดังต่อไปนี้

  execution(public Target.compute1000()) || 
  execution(public Target.compute2000())

ความหมายคือ เราสร้าง pointcut จาก PCD มากกว่า 1 ตัว และในกรณีนี้ เราใช้ PCD 2 ตัวทำการ or กัน
ในการใช้งานจริง จะสามารถยุบรวมให้เป็น PCD เดียวโดยใช้ wildcard ซึ่งจะเป็นตามโค้ดต่อไปนี้ครับ

  execution(public Target.compute*())

(หมายเหตุ: pointcut นี้จะเลือกทุก ๆเมธอดของคลาส Target ที่ชื่อเมธอด ขึ้นต้นด้วย compute นะครับ
นั่นคือถ้าเีราเพิ่ม compute3000() เข้าไป method ใหม่ก็จะโดนเลือกด้วย ซึ่งจะทำให้ความหมายไม่ตรงเป๊ะ ๆ กับ code แรก
แต่ผมต้องการแสดงให้เห็นว่าเราสามารถเลือกเชิงประมาณโดยใช้ wildcard ได้)

4. ต่อมาเราก็จะประกาศ advice เพื่อให้ทำงาน ณ ตำแหน่ง join point ที่เราเลือกมาด้วย pointcut ในข้อ 3 ครับ
ก่อนจะไปต่อ ผมเล่าให้ฟังนิดนึงว่า join point มีสมบัติสำคัญ ๆ คือ
1) เราเข้ามาที่จุด join point ได้
2) เมื่อมาถึงแล้ว เราทำงานที่จุด join point ได้
3) และเมื่อมาถึงแล้ว เราออกจากจุด join point ได้

ซึ่ง advice ก็คือคำแนะนำที่เราบอกกับโปรแกรมว่าควรจะทำอะไรที่จุด join point นี้

ตาม aspect เราตั้งใจว่าจะ "จับเวลา" การทำงานของ 2 method
นั้นคือเราะจะมีการจับเวลา "ก่อน" และ "หลัง" ในแต่ละ join point ที่เลือกไว้ด้วย pointcut ในข้อ 3 ครับ
ตรงนี้เราจะใช้ before() เพื่อนิยามการแนะนำขณะเข้า join point
และ after() เพื่อนิยามการแนะนำขณะออกจาก join point
ดังนั้นเราก็จะได้

before(): <ชื่อ pointcut>() {
  // จับเวลาใส่ตัวแปร
}

after(): <ชื่อ pointcut>() {
  // จับเวลา แล้วเอาไปลบกับตัวแปรที่ตั้งค่าไว้ในโค้ดของ before
  // แล้ว System.out.println(เวลา);
}

แล้วก็สั่งรันโปรแกรม ก็เป็นอันเสร็จพิธีครับ

ในตัวอย่างที่ผมยกมาให้ดูนี้ ผมใช้ join point model แบบ pointcut-advice เพื่่ออธิบาย aspect สำหรับ"จับเวลา" โดยสร้าง pointcut จากการใช้ PCD 2 ชุดมา or กัน เพื่อเลือก (quantify) join point 2 ตำแหน่งใน class Target แล้วก็สร้าง advice เพื่อแนะนำให้โปรแกรมทำการจับเวลา "ก่อน" และ "หลัง" จุดที่เลือกมาด้วย pointcut ผมตั้งใจละ code ไว้ให้ผู้อ่านลองนำไปเขียนเพิ่มเติมเองนะครับ

สำหรับ join point อีก model ที่มีใน AspectJ คือ inter-type declaration หรือเรียกว่า introduction จะกล่าวถึงในโพสต์อื่น ๆ ครับ

หมายเหตู ผมโพสต์ตอบแบบเดียวกันนี้ไว้ในกระดานข่าวของ narisa.com กระทู้นี้ครับ

เหตุผลที่ AOP แตกต่างจาก MOP

ผมกำลังสร้างระบบย่อยเชิงลักษณะ (AOP subsystem) สำหรับ Groovy โดยอิมพลีเม้นต์บน Meta Object Protocol (MOP - ระเบียบการเหนือวัตถุ?) ให้สนับสนุนสมบัติหลัก 2 ประการของแบบจำลอง pointcut-advice นั่นคือ การเลือกเชิงปริมาณ (Quantification) และ การไม่รับรู้ (Obliviousness)

โดยปกติ การใช้เมต้าคลาสใน Groovy ก็สนับสนุนการไม่รับรู้ของวัตถุเป้าหมายได้อยู่แล้วเนื่องจากระเบียบการเหนือวัตถุจะใช้เมต้าคลาสของแต่ละวัตถุในการเรียกใช้เมธอดและเข้าถึงสมบัติของวัตถุนั้น ๆ
สิ่งที่ขาดไปก็คือการเลือกเชิงปริมาณ ที่ใน AspectJ ใช้ wildcard เพื่อเลือกหลาย ๆ joinpoint จาก ประโยค pointcut เพียง 1 ประโยค
รวมถึงจุดเล็ก ๆ น้อย ๆ ในการอิมพลีเม้นต์ที่ยอมให้พฤติกรรมซับซ้อนเช่น proceed หลายระดับใน advice แบบ around ทำได้ง่ายขึ้น
และนี่คือจุดสำคัญที่ AOP แตกต่างจาก MOP และเป็นเหตุผลว่าทำไม AOP ถึงยังจำเป็นแม้จะมี MOP อยู่แล้วในภาษาพลวัตร

Groovy และเมต้าคลาสที่สนับสนุน AOP

ผมบล้อกเกี่ยวกับการอิมพลีเม้นต์เมต้าคลาสใน Groovy เพื่อสนับสนุนการโปรแกรมเชิงลักษณะตามโมเดลของ AspectJ โค้ดที่โพสต์ไว้ส่วนใหญ่มากจากบทความของ John McClean บน InfoQ ที่เพิ่งไปอ่านเจอมา ตกใจเล็กน้อยที่เค้าเขียนไว้นานแล้ว แต่ก็ดีใจที่เจอ เพราะผมยังห่างไกลเรื่องแนวคิดทาง Meta Object Protocol (MOP) อยู่มาก เห็นการเอาทั้ง 2 แนวคิด (คือ AOP และ MOP) มารวมกันทำให้ผมเข้าใจมันมากขึ้นและทำให้งานวิจัยค่อนข้างก้าวกระโดดทีเดียว



จากบทความที่ว่า ผมเห็นชัดเจนมากขึ้นว่าทำไมคนในโลกภาษาพลวัตรทั้งหลายเฉย ๆ กับ AOP เพราะ advice พื้นฐานของ AOP จำพวก before, after, around กลายเป็นของง่าย ๆ ด้วยเมต้าคลาส แต่จุดหนึ่งที่น่าสนใจคือ สมบัติของ AOP ในการเลือกเชิงปริมาณ (Quantification) นั้นยังทำได้ยากในแบบ crosscutting แต่ง่่ายในแบบ hierarchy ด้วยเมต้าคลาส แต่ยังไงก็ง่ายกว่าภาษาเชิงวัตถุแบบสถิตย์อย่าง Java (เมื่อไม่ใช้อะไรที่เกี่ยวข้องกับ AOP เลย) อยู่ดี

การโปรแกรมเขิงลักษณะในอีก 10 ปี

Panelists จากการประชุมวิชาการ AOSD 07 พูดเสนอมุมมองที่น่าสนใจหลาย ๆ อย่างเกี่ยวกับ AOP ในอีก 10 ปีข้างหน้าว่าจะมีรูปแบบอย่างไร ผมเลยสรุปและรวมเข้ากันกับแนวคิดที่เสนอโดย Keynote Speakers 2 คนจาก AOSD 07 เช่นกันครับ งานวิจัยของผมมีหลาย ๆ ส่วนที่เป็นไปในแนวทางที่ทั้ง Panelists และ Keynote เสนอมา ผมเลยจะแทรกความเห็นของผมลงไปด้วยนะครับ



Crosscutting Concerns ไม่จำเป็นต้องตัดขวางเฉพาะการไหลของโปรแกรม - ประเด็นนี้ค่อนข้างตรงใจผมครับ เนื่องจากงานวิจัยใกล้เคียงกับที่ผมทำอยู่ ก็สามารถอธิบายได้ด้วย AOP และมันก็ไม่ใช่การไหลของโปรแกรมเสียทีเดียว ซึ่งจุดนี้ยืนยันแนวคิดการใช้งาน AOP ในโลกของ High-Performance Computing ได้ค่อนข้างดีครับ



การทำให้ภาษาเชิงลักษณะเข้าใจได้ง่ายขึ้น โดยการปรับปรุงส่วนของภาษาที่ใช้อธิบาย pointcut เป็นเรื่องใหญ่เรื่องหนึ่งที่เป็นปัญหาปลายเปิดให้ค้นคว้ากันครับ - ผมเห็นด้วยกับความคิดดังกล่าว เพราะทีมอื่น ๆ ในแล็บบอกให้ผมฟังว่าภาษาทาง AOP มันดูซับซ้อนและเข้าใจยาก อันนี้จริงครับ เพราะมันทรงพลังมาก และก็ค่อนข้างท้าทายที่เราจะทำให้ภาษาง่ายขึ้นและยังทรงพลังอยู่



จุดใหญ่จุดหนึ่งที่น่าสนใจเกี่ยวกับการโปรแกรมเชิงลักษณะในอีก 10 ปีถัดไปคือการพัฒนาและกระตุ้นการใช้งาน aspect ในระดับ domain ซึ่งเป็นเรื่องค่อนข้างที่จะท้าทายพอสมควรอีกเช่นกันครับ ประเด็นนี้เกี่ยวข้องกับประเด็นข้างบน นั้นคือ ผมมองว่าเราต้องมีภาษาที่ง่ายพอที่จะทำให้คนกลุ่มใหญ่ใช้ AOP ก่อน แล้วการนำ AOP ไปใช้ในระดับ domain ก็จะตามมามากขั้นครับ



จุดหลัก ๆ อีกประเด็นที่ผมจับได้ก็คือ ความพยายามในการสนับสนุน AOP สำหรับภาษาพลวัตร แนวคิดนี้ค่อนข้างทำได้ยาก เนื่องจากธรรมชาติของภาษาพลวัตร เช่น Ruby หรือ Groovy นั้นไม่ได้ต้องการ AOP อย่างชัดเจน เพราะกลไกของ Metaclass สามารถสนับสนุนการเปลี่ยนแปลงพฤติกรรมขณะเวลารันได้อยู่แล้ว จึงเป็นหัวข้อที่ท้าทายมาเรื่องหนึ่งครับ