มา promote การเขียนโปรแกรมด้วย AOP ครับ Options

[cblue]

ผมทำวิจัยโดยตรงกับ AOP โดยเฉพาะคลุกคลีกับ aspectj 1.5 มากเป็นพิเศษ
ได้มีโอกาสงัดแงะ code ของ project นี้พอสมควร
รวมทั้งคิดว่าหลายท่านได้ใช้ AOP จริงผ่าน spring framework กันบ้างแล้ว
และคิดว่าอีกหลายท่านใน forum คงมีความรู้พื้นฐานเรื่อง AOP กัน
เลยถือโอกาส promote และย้ำแนวคิดการใช้ AOP สำหรับ software development ครับ

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 เองเพื่อใช้ในองค์กรนะครับ

This post has been edited by cblue: Apr 9 2006, 11:31 PM

[pordee]

ขอบคุณมากคราบ กำลังต้องการความรู้เกี่ยวกับ AOP อยู่แล้วคราบ ยังไงถ้ามีความรู้อะไรเกี่ยวกับ AOP ช่วยเอามาpost ให้อีกน่ะคราบ จะติดตามอยู่เรื่อยๆ คราบผม

[playmobus]

น่าสนใจดีครับ

แต่ต้องระวังเรื่อง implementation เหมือนกันนะครับ การเปลี่ยนจาก Proxy-AOP ไปเป็น AspectJ อาจจะต้องแก้ design บางส่วนของระบบด้วย ที่เคยเจอมาก็เรื่อง declarative transaction demarcation ต้องระวังให้มาก

[cblue]

น่าสนใจดีครับ

แต่ต้องระวังเรื่อง implementation เหมือนกันนะครับ การเปลี่ยนจาก Proxy-AOP ไปเป็น AspectJ อาจจะต้องแก้ design บางส่วนของระบบด้วย  ที่เคยเจอมาก็เรื่อง declarative transaction demarcation ต้องระวังให้มาก

คือผมไม่ได้มีความคิดจะให้เปลี่ยนจาก proxy-based มาเป็น aspectj
ความตั้งใจตรงนี้คืออยากลองนำเสนอแนวทางการสร้าง aspect ในระดับที่สูงกว่า infrastructure
(ผมมอง transactional, logging เป็น infrastructure ครับ)
และ preserve base code เดิมไว้ทั้งหมดได้ (หมายถึงแยกกัน maintain ครับ)

ผมยืนยันครับว่าใช้ proxy-based และ aspectj ร่วมกันได้ ระบบที่ผม run อยู่ ใช้ Spring
HibernateInterceptor ครอบ Dao class (proxy-based aop) ในขณะที่มี aspect ที่สร้างด้วย
aspectj โหลดผ่าน javaagent และทำ load-time weaving ครับ

มี 2 concept ของ aop ที่น่าสนใจครับ คือ
1. quantification คือจัดการเป็นกลุ่ม ๆ (ผ่าน pointcut)
2. obliviousness คือ base code ไม่จำเป็นต้องรับรู้การมี aspect

This post has been edited by cblue: Apr 9 2006, 11:21 PM

[playmobus]

คือผมไม่ได้มีความคิดจะให้เปลี่ยนจาก proxy-based มาเป็น aspectj

จะใช้ proxy-based หรือ aspectj ขึ้นกับความเหมาะสมครับ ทั้ง proxy-based และ aspectj มีข้อด้อยและข้อเด่นในตัวของ technology ที่แตกต่างกันชัดเจนอยู่แล้ว

ความตั้งใจตรงนี้คืออยากลองนำเสนอแนวทางการสร้าง aspect ในระดับที่สูงกว่า infrastructure

น่าสนใจครับ

(ผมมอง transactional, logging เป็น infrastructure ครับ) และ preserve base code เดิมไว้ทั้งหมดได้ (หมายถึงแยกกัน maintain ครับ)

จุดนี้หละครับที่ผมได้ตั้งข้อสังเกตุเอาไว้ โดยเฉพาะเรื่องของ declarative transaction เมื่อมีการเปลี่ยน implementation ในส่วน infrastructure แล้วเกิดต้องไปแก้ design ของ application layer คงจะเป็นเรื่องที่น่าปวดหัว แต่มันเกิดขึ้นแล้ว ถ้าใช้ aspectj ทำ declarative transaction จะมีโอกาสได้ source code ที่ clean กว่า proxy based AOP

ผมยืนยันครับว่าใช้ proxy-based และ aspectj ร่วมกันได้

ใช่ได้ครับ ไม่มีปัญหา ตัว proxy เป็น technology ที่มากับ JVM อยู่แล้วและก็มีประโยชน์ใช้สอยหลายประการนอกเหนือจาก AOP

แต่ถ้าจะเอามาทำ AOP เพื่อใช้ใน application พร้อมๆกับ AspectJ เพื่อแก้ปัญหา crosscutting concern ก็จะทำให้เพิ่มความซับซ้อนของระบบงาน เพราะมี AOP 2 แบบในระบบเดียวกัน ซึ่งพฤติกรรมไม่เหมือนกัน

[cblue]

จุดนี้หละครับที่ผมได้ตั้งข้อสังเกตุเอาไว้ โดยเฉพาะเรื่องของ declarative transaction เมื่อมีการเปลี่ยน implementation ในส่วน infrastructure แล้วเกิดต้องไปแก้ design ของ application layer คงจะเป็นเรื่องที่น่าปวดหัว แต่มันเกิดขึ้นแล้ว

ปัญหานี้น่าสนใจครับ
ยังไงถ้ามีเวลา รบกวนคุณ playmobus ยกประเด็นนี้มา discuss เพิ่มเติมหน่อยครับ

แต่ถ้าจะเอามาทำ AOP เพื่อใช้ใน application พร้อมๆกับ AspectJ เพื่อแก้ปัญหา crosscutting concern ก็จะทำให้เพิ่มความซับซ้อนของระบบงาน เพราะมี AOP 2 แบบในระบบเดียวกัน ซึ่งพฤติกรรมไม่เหมือนกัน   

ตรงนี้คงต้องชี้แจงครับว่าความเข้าใจเรื่อง separation of concerns ของผมกับคุณ playmobus ไม่ตรงกัน
ใน system จริง ๆ เราไม่ได้มีแค่ AOP 1 หรือ 2 ตัว run อยู่นะครับ จริง ๆ แล้วมันมากกว่านั้น
สมมติว่าใน system หนึ่ง ๆ อาจจะประกอบไปด้วย Hibernate, Springframework, Axis client สำหรับ call Web Service ทั้งหมดอาจ deploy ลงใน Tomcat
- Hibernate ทำ AOP-style interceptor ด้วย CGLIB อยู่แล้วครับ
- Springframework ไม่ได้สนใจ concern ของ Hibernate, และทำ Interceptor อีกจำนวนหนึ่ง รวมทั้งสร้าง Spring AOP
- Axis client ไม่ได้สนใจ concern ของ Hibernate, Spring และ Axis ก็ทำ proxy-based AOP สำหรับ call services ผ่าน WSDL
ยิ่งถ้า application ชุดนี้ต้อง deploy ลง JBoss จะยิ่งเห็นชัดเลยครับ เพราะ service อย่าง JBoss cluster ก็ใช้ AOP ของมันทำ object replication
จึงไม่น่าจะแปลกอะไรถ้าจะมีการใช้ Aspect ที่ developed ด้วย AspectJ เพื่อจัดการ concern อื่น ๆ อีก ครับ

เลยวนกลับไปที่จุดประสงค์หลักของ AOP และ principle ของ SE
ที่พยายามแก้ปัญหาทีละ concern ครับ
ผมมองอย่างนี้ครับ เราสร้าง system A แล้วก็ isolate มัน จากนั้นสร้าง aspect B แล้วก็ isolate system A และ aspect B แล้วก็สร้าง aspect C ให้ system A แล้วก็ isolate system A และ aspect B, C ไปเรื่อย ๆ โดน aspect B และ C และอื่น ๆ อาจมาจาก aop คนละ framework
ตัวอย่างที่ผมยกมาก็เป็นไปตามนี้ครับ

This post has been edited by cblue: Apr 10 2006, 04:02 AM

[playmobus]

ตรงนี้คงต้องชี้แจงครับว่าความเข้าใจเรื่อง seperation of concerns ของผมกับคุณ playmobus ไม่ตรงกัน ใน system จริง ๆ เราไม่ได้มีแค่ AOP 1 หรือ 2 ตัว run อยู่นะครับ จริง ๆ แล้วมันมากกว่านั้น
สมมติว่าใน system หนึ่ง ๆ อาจจะประกอบไปด้วย Hibernate, Springframework, Axis client สำหรับ call Web Service ทั้งหมดอาจ deploy ลงใน Tomcat

ถูกต้องครับ คงจะไม่ตรงกันจริงๆ คงต้องยกความสนใจของคุณ cblue ขึ้นมาอีกครั้งหนึ่งที่บอกว่า

ความตั้งใจตรงนี้คืออยากลองนำเสนอแนวทางการสร้าง aspect ในระดับที่สูงกว่า infrastructure

เห็นกล่าวอย่างนี้ ก็นึกว่าจะ design ตัว aspect ขึ้นมาใช้ในระดับของ application ที่คุณ cblue เขียนเอง ในที่นี่ผมหมายถึง domain layer เพราะ layer อื่นๆแทบจะมี framework รองรับไว้หมดแล้ว ยกตัวอย่างเช่น

การที่โปรแกรมเมอร์ใช้ Hibernate ในการพัฒนาระบบงานก็ไม่ได้หมายความว่าเขาจะต้องไป design หรือยุ่งเกี่ยวอะไรกับ aspect กรณีอย่างนี้มันเป็น infrastructure (แต่ถ้า Hibernate ใช้ทั้ง Proxy-AOP และ AspectJ ในการแก้ปัญหา Persistence นี่หละแปลก คงจะต้องขอคำอธิบายว่าทำไมถึงต้องทำเช่นนั้น)

คิดว่าคงจะมองไปคนละมุมก็เท่านั้นเองหละครับ

ปล. ตัวอื่นๆไม่สงสัยแต่ Axis Client ใช้ AOP ในการเรียกใช้ WebService ด้วยหรือ?

This post has been edited by playmobus: Apr 10 2006, 04:29 AM

[cblue]

เห็นกล่าวอย่างนี้ ก็นึกว่าจะ design ตัว aspect ขึ้นมาใช้ในระดับของ application ที่คุณ cblue เขียนเอง 

ใช่ครับ ผมหมายความอย่างนั้น
ผมใช้คำว่า aspect ที่สูงกว่าระดับ infrastructure เพราะเท่าที่เห็นการออกแบบ aspect ปัจจุบันก็เพื่อใช้เป็น infrastructure ของ
application server ในขณะที่จริง ๆ แล้วเราสามารถใช้ aspect ในการจัดการ domain, logic หรือ presentation ได้ด้วย
สำหรับใน reply ที่แล้วก็เพื่ออธิบายประเด็นของ separation of concerns และการใช้งานร่วมกันของหลาย AOP system เท่านั้นครับ

ในที่นี่ผมหมายถึง domain layer เพราะ layer อื่นๆแทบจะมี framework รองรับไว้หมดแล้ว

ยังหรอกครับ ยังมีอีกเยอะครับและมีได้ในทุก ๆ layer ครับ
เช่น aspect ที่เพิ่มความสัมพันธ์ (relations) ลงไปใน business objects เพื่อใช้งานเฉพาะอย่าง
(ใช้ inter-type declaration และ advise property บางตัวที่ต้องการ)
หรือ aspect ที่คอยนับจำนวนครั้งและหาค่าเฉลี่ยของจำนวนการขาย จาก method ระดับ business logic หลาย ๆ ตัว ที่เกี่ยวข้องกับการขาย
(ใช้ inter-type declaration และ advise after method เหล่านั้น)
หรือ aspect ที่ช่วย update presentation layer ในบางลักษณะ
(ใช้ inter-type declaration และ advise after method อาจจะทั้งในระดับ logic และ business objects)
เป็นต้นครับ
อื่น ๆ ก็เช่นการเรียกใช้บาง method ซ้ำถ้าเกิด exception บางตัว ครับ
อย่างไรก็ตาม จุดสำคัญคือ modularity และ obliviousness ครับ
นั่นคือถ้าไม่เกิดปัญหาคล้าย ๆ กับที่ผมยกตัวอย่างไว้ การใช้ aspect ในระดับสูงกว่า infrastructure อาจจำเป็นน้อย

(แต่ถ้า Hibernate ใช้ทั้ง Proxy-AOP และ AspectJ ในการแก้ปัญหา Persistence นี่หละแปลก คงจะต้องขอคำอธิบายว่าทำไมถึงต้องทำเช่นนั้น)

ประเด็นนี้เห็นด้วยครับ

ปล. ตัวอื่นๆไม่สงสัยแต่ Axis Client ใช้ AOP ในการเรียกใช้ WebService ด้วยหรือ?

ใช้ในลักษณะเดียวกันกับ Hibernate ครับ
เป็น proxy-based สร้าง class ขึ้นมาครอบ interface ขณะ runtime
library ก็ CGLIB ครับ

[gyger]

น่าสนใจทีเดียว ถามเพิ่มหน่อยนึงครับ การโปรแกรมในรูปแบบ aop นี่ จะทำให้การ debug, แก้ไข ยากขึ้นหรือไม่ เพราะว่าการทำงานไม่ได้มาจาก sourcecode แค่จุดเดียว
ทำไปทำมามันจะมีปัญหากับระบบขนาดใหญ่หรือเปล่า ?

ผมหมายถึงระบบที่คนเขียนอาจไม่ใช่คน maintain น่ะครับ

[playmobus]

ใช้ในลักษณะเดียวกันกับ Hibernate ครับ
เป็น proxy-based สร้าง class ขึ้นมาครอบ interface ขณะ runtime
library ก็ CGLIB ครับ

สงสัยจะเป็นโปรเจคอื่นที่นำ AOP มาใช้กับ Axis หรือเปล่าครับ? โดยเฉพาะพวก container บางตัวอย่าง JBoss
ลำพัง Axis 1.x / Axis 2 ไม่ได้ใช้ cglib นะครับ ในตัว Axis 2 มีการนำเสนอ Message Interceptor อย่างเอาจริงเอาจังแต่ก็ไม่มี AOP นะครับ เทคนิคจะออกไปในแนวประมาณ Servlet Filter มากกว่า

[playmobus]

น่าสนใจทีเดียว ถามเพิ่มหน่อยนึงครับ การโปรแกรมในรูปแบบ aop นี่ จะทำให้การ debug, แก้ไข ยากขึ้นหรือไม่ เพราะว่าการทำงานไม่ได้มาจาก sourcecode แค่จุดเดียว

ตั้งข้อสังเกตุได้ดีมากๆครับ ผมคิดว่าถ้ามองเรื่องการ debug คงจะยากมากๆเลยครับ ถ้าไม่มี IDE ดีๆ(จริงๆ) หรือต่อให้มี Eclipse + AJDT ก็ยังยากเลยครับ

แต่ถ้าได้พิจารณาแล้วว่า Aspect ที่จะใส่เข้ามาจะต้องเป็น cross cutting ซึ่งแก้ไม่ได้ด้วย OOP เช่น พวก security, declarative transaction demarcation หรืออะไรประมาณนี้ การ debug ก็คงจะไม่จำเป็นโดยปริยาย (จุดนี้มองใน level ของคนพัฒนาตัว business app นะครับ แค่ทำ Unit Test ก็เพียงพอแล้ว)

ทำไปทำมามันจะมีปัญหากับระบบขนาดใหญ่หรือเปล่า ?

ถ้าใช้ถูกเรื่อง น่าจะเป็นประโยชน์มากๆครับ แต่ถ้าใช้ผิดประเภทก็เป็นโทษครับ
ผมคิดว่า common concern ให้ OOP ทำ ส่วน cross cutting concern ใช้ AOP ทำ

[cblue]

น่าสนใจทีเดียว ถามเพิ่มหน่อยนึงครับ การโปรแกรมในรูปแบบ aop นี่ จะทำให้การ debug, แก้ไข ยากขึ้นหรือไม่ เพราะว่าการทำงานไม่ได้มาจาก sourcecode แค่จุดเดียว
ทำไปทำมามันจะมีปัญหากับระบบขนาดใหญ่หรือเปล่า ?

ผมหมายถึงระบบที่คนเขียนอาจไม่ใช่คน maintain น่ะครับ

ตอบประเด็นการ debug นะครับ
โดยทั่วไป ต้องยอบรับว่า การ debug ยากขึ้นครับ
ยิ่งในกรณีที่ใช้ transparent AOP อย่าง load-time weaving (aspectj) หรือ proxy-based AOP (spring) ได้มีโอกาสไปฟัง Rob Harrop พูด และมีคนถามประเด็นนี้เหมือนกันครับ
Rob บอกว่า ปัจจุบันเทคนิคอย่าง test-first จึงมีบทบาทกับการ develop aspect มากขึ้น

สำหรับประเด็นการแก้ไข
ตาม concept แล้ว การแก้ไข code base จะไม่กระทบ aspect ครับ
คือในแง่ของการ implement aspect ที่สูงกว่าระดับ infrastructure เรามักคุม scope การ weave aspect ให้เจาะจงไปที่ class บางกลุ่ม และไม่ให้มัน general เท่า infrastructure ครับ
สำหรับการแก้ไข aspect source จะค่อย ๆ ง่ายขึ้นครับ ตอนนี้เราสามารถมองเห็นจุดของการ weave ได้ใน Eclipse AJDT ครับ

แต่ถ้าได้พิจารณาแล้วว่า  Aspect ที่จะใส่เข้ามาจะต้องเป็น cross cutting ซึ่งแก้ไม่ได้ด้วย OOP เช่น พวก security, declarative transaction demarcation หรืออะไรประมาณนี้ การ debug ก็คงจะไม่จำเป็นโดยปริยาย (จุดนี้มองใน level ของคนพัฒนาตัว business app นะครับ แค่ทำ Unit Test ก็เพียงพอแล้ว)

คำตอบของคุณ playmobus ระบุได้ตรงประเด็นครับ
ตรงนี้คือความเป็น modularity ที่ AOP พยายามจะ provide

This post has been edited by cblue: Apr 10 2006, 01:16 PM

[cblue]

สงสัยจะเป็นโปรเจคอื่นที่นำ AOP มาใช้กับ Axis หรือเปล่าครับ? โดยเฉพาะพวก container บางตัวอย่าง JBoss
ลำพัง Axis 1.x / Axis 2 ไม่ได้ใช้ cglib นะครับ ในตัว Axis 2 มีการนำเสนอ Message Interceptor อย่างเอาจริงเอาจังแต่ก็ไม่มี AOP นะครับ เทคนิคจะออกไปในแนวประมาณ Servlet Filter มากกว่า

โอ๊ะ โทษทีครับ
ผมไปดู distribution มาแล้ว ไม่มี cglib จริง ๆ
และตัว client call ใช้ proxy-based (AxisClientProxy) ครับ

[cblue]

ทำไปทำมามันจะมีปัญหากับระบบขนาดใหญ่หรือเปล่า ?

ถ้าใช้ถูกเรื่อง น่าจะเป็นประโยชน์มากๆครับ แต่ถ้าใช้ผิดประเภทก็เป็นโทษครับ
ผมคิดว่า common concern ให้ OOP ทำ ส่วน cross cutting concern ใช้ AOP ทำ

AOP ใช้เพื่อสนับสนุน OOP เป็นหลักอยู่แล้วครับ ไม่ได้มาแทนที่
Kiczales คนแรกที่นำเสนอ AOP ก็บอกไว้ครับว่า AOP ใช้แก้ปัญหาที่เหลืออีกประมาณ 15% ที่ทำได้ยากด้วย OOP ครับ

This post has been edited by cblue: Apr 10 2006, 01:12 PM

[xcaleber]

โอ้ พอดีเลยครับ แหม ตอนนี้ผมกำลังสนใจทำ thesis เกี่ยวกับ AOP อยู่เหมือนกัน ไม่ทราบว่าพอจะแนะนำหัวข้อที่น่าสนใจที่เกี่ยวข้องไหมครับ?