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 เลยทีเดียว
ด้านล่างจะเป็นนิยามที่ผมแปลและเรียบเรียงจากหลาย ๆ ที่เพื่อเสริมความเข้าใจ
การโปรแกรมเชิงลักษณะ (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 เลยทีเดียว
