AOP เอาไว้แก้ปัญหาเรื่อง Cross cutting concern นะ
แปลเป็นไทย cross cutting concern ก็คือ สิ่งที่เราต้องสนใจที่ตัดผ่านสิ่งที่เราสนใจ
ยกตัวอย่างละกัน เราจะทำระบบอะไรสักอย่าง เช่น โอนเงินระหว่างบัญชี จากธนาคารละกันนะ
ในส่วนนี้ concern หลักของ bussiness ก็แค่ ลดเงินของ บัญชีนึง แ้้ล้วไปเพิ่มใส่อีกบัญชีนึง
แต่จากระบบนี้ เราจะมี cross cutting concern ที่ตัดผ่านงานเราเยอะแยะเลย เช่น การใส่ใจเรื่อง security authentication, transection management, logging message, presistance, availability ต่างๆ
พวกนี้อาจจะเป็นทั้ง functional หรือ non-function requirement ของระบบก็ได้ค่ะ
จะเห็นว่าในระบบเรานี้ นอกจากส่วน โอนเงิน cross cutting concern เหล่านี้มันลากตัดผ่าน ระบบอื่นๆ อีกเพียบเลย
บางระบบ อาจจะมี แค่ logging แต่ไม่มี security authen
บางระบบ ก็ใช้ concern ต่างๆ พวกนี้ไม่เท่ากัน
เวลา implement ด้วยแนวทาง OOP จึงทำให้เกิดปัญหาต่างๆ คือ
- concern เหล่านี้ลากตัดผ่านกระจัดกระจาย ทั่วไปในงานเรา (scattering) บางงานใช้บ้าง ไม่ใช้บ้าง
- โค๊ดของงานเราในแต่ละ modular ยุ่งเหยิง (tangling) เพราะมัวแต่ไปจัดการเรื่อง cross cutting เหล่านี้ ทั้งที่จริงๆ แล้ว bussiness ของงานมันแค่นิดเดียวเอง
เมื่อเป็นเช่นนี้แ้ล้วก็ระบบก็จะมี low cohesive เกิด high couple ไ่ล่ code ก็ยาก แ้ล้วก็ reuse ได้ยากอีกเช่นกันนะ
แนวทางใหม่ที่นำเสนอขึ้นนั่นคือ AOP (aspect oreinted programming)ค่ะ
aop สามารถนำมาประยุกต์ให้เข้ากับ OOP ได้อย่างดี ช่วยแก้ปัญหาที่พบได้เร็วขึ้น
concern แยกออกจากกันอย่างชัดเจน สามารถ trace concern เหล่านี้ได้มากกว่าค่ะ
ลองหาเอกสาร AOP เพิ่มเติมดูละกันนะคะ
สำหรับ JAVA ถ้าอยากเขียนงานให้สามารถทำ AOP ได้ลองศึกษา AspectJ ดูละกันค่ะ
จากที่รักบอกมา เจ้าค่ะ
หนูเป็นเด็กอยากรู้อยากเห็น เจ้าค่ะ
จากคุณ deans4j แห่ง Blognone.com http://www.blognone.com/node/1426
Review
AOP หรือ aspect-oriented programming (ใน thesis ป. โท ผมเมื่อ 3-4 ปีก่อน ใช้คำว่า
"การโปรแกรมเชิงลักษณะ" ครับ) เป็น paradigm สำหรับแก้ปัญหาความซ้ำซ้อนของ code แนวขวาง
(crosscutting concern) AOP พิจารณาจุดใน program flow เช่น constructor, method
และอื่น ๆ เป็น joinpoint abstraction และยอมให้จับกลุ่มจุดเหล่านั้นด้วยคำอธิบาย
เรียกว่า pointcut สำหรับ code ที่จะให้ทำงานที่ pointcut จะเรียกว่า advise code
ซึ่งจะสามารถระบุได้ว่าจะให้ทำงานในตำแหน่งอ้างอิงใดกับจุดที่รวบไว้โดย pointcut นั้นๆ เช่น before, after,
และ around ครับ นอกจากนี้ AOP ยอมให้ประกาศ field, method และอื่น ๆ เพิ่มเข้าไปใน code เดิม
ซึ่งเรียกว่า introduction หรือ inter-type declaration และทั้งหมด
ก็รวบอยู่ในหน่วย ๆ เดียวเรียกว่า aspect
Proxy-based AOP
Spring framework ดังสุดในกลุ่มนี้ (อย่างน้อยก็จากมุมมองของผม) สำหรับ aspect ที่ spring เน้น
ก็คือ Transactional และอื่น ๆ เมื่อมองจาก AOP การจัดการ transaction ก็เป็นเพียง aspect เดียวเท่านั้นครับ
ซึ่งจริงๆ เราสามารถสร้างและใช้ aop ได้ในหลายแนวทาง การติดอยู่กับ aspect ที่มีมากับ framework หนึ่ง ๆ
จะทำให้ code บางส่วนซ้ำซ้อนในที่สุด
ผมจึงคิดว่าจุดที่ต้องส่งเสริมกันคือความเข้าใจพื้นฐานในการแยก aspect ออกจาก object-orieted code
และที่อยากให้หลายท่านลองกันก็คือ aspectj ครับ
Aspect-Oriented System
AspectJ เป็นภาษาและระบบ aspect สำหรับ Java ที่พูดได้ว่า powerful ที่สุด ใน AspectJ 1.5 ที่เพิ่ง released
เมื่อต้นปีได้สนับสนุน Java 5 อย่างเต็มตัวทั้งในเทอมของภาษาและสถาปัตยกรรม
AspectJ 1.5 สนับสนุนการประกาศ pointcut สำหรับ annotation และทำงานร่วมกับ generic ได้
Java 5 อนุญาตให้ระบุ agent สำหรับเปลี่ยนแปลง bytecode ขณะ load class ขึ้นไปประมวลผล
และ AspectJ 1.5 ก็ใช้ความสามารถนี้ได้อย่างดี
Aspect Refactoring
แนวคิดในการสร้างและใช้ aop อยู่ที่พื้นฐานความเข้าใจในการแยก aspect ออกมาจาก object-oriented code ครับ
เราจะเห็นประโยชน์ของ aop ชัดขึ้นไปอีกระดับนึงตามตัวอย่างนี้ครับ
เมื่อ code ชุดนึง maintain ด้วยทีม A และเป็น production แล้ว
ทีม B ถูก set ขึ้นเพื่อแก้ปัญหาบางอย่างที่ต้องเพิ่มความสามารถให้ code หลัก
ทีม B เข้าถึง source code ได้แต่การ patch code ที่มีการกระจายตัวสูงทำให้ต้องแก้ไข code แทบทุกไฟล์ใน project
วิธีการที่ ทีม B สามารถทำได้ด้วย AOP ก็คือ เลือก code มาบางส่วน และเริ่มต้นพัฒนาด้วย OOP ก่อน เมื่อเห็นว่า code ทำงานได้แล้ว
ก็พิจารณาจุดตัด (joinpoint) และดึง code ส่วนที่เพิ่มเข้าไปใหม่เหล่านั้นออกมาเป็น aspect
จากนั้นก็ทดสอบสร้าง pointcut เพื่อให้ aspect ที่สร้างขึ้นสามารถสาน (weave) เข้าไปใน code ทั้งหมดได้
โดยการ test ควรทำด้วย static weaving (การสาน code ที่เปลี่ยนแปลง .class ตั้งแต่เวลา compile โปรแกรม)
เมื่อ test ระบบเรียบร้อยแล้ว และคาดหวังว่าระบบจะทำได้โดยไม่มีข้อผิดพลาดแล้ว ก็ให้แยก aspect ออกมาเป็น .jar ต่างหาก
และใช้ javaagent เป็นตัวทำ load-time weaving ขณะ runtime และ deploy ลง container
ด้วยแนวคิดจากตัวอย่างที่ผมยกขึ้นมาจะเห็นได้ชัดว่ามีการแบ่งความรับผิดชอบชัดเจนมาก
ขึ้นใน team นั่นคือ
ทีม A สามารถ maintain code หลักต่อไปได้ และ ทีม B เพิ่มความสามารถให้ระบบได้โดยที่ไม่ต้องไปทะเลาะกับทีม A
เช่นเมื่อระบบรวน ทีม B ก็สามารถยกเลิก aspect ได้โดยปิด javaagent และแยกได้ชัดเจนว่า bug ที่เกิดขึ้นเนื่องจากระบบเดิมหรือตัว aspect ใหม่
คิดว่าแนวทางที่ผมเขียนมานี้คงทำให้หลาย ๆ ท่านได้ idea ในการสร้าง aspect เองเพื่อใช้ในองค์กรนะครับ
จากคุณ cblue แห่ง narisa.com http://www.narisa.com/forums/index.php?showtopic=11868
0 comments:
แสดงความคิดเห็น