วิกิพีเดียภาษาไทย
กลับไปหน้าบทความ

อ่าน 17 นาที

การเขียนโปรแกรมเชิงแง่มุม

ในด้านวิทยาการคอมพิวเตอร์การเขียนโปรแกรมเชิงแง่มุม (Aspect-Oriented ProgrammingหรือAOP )...

การเขียนโปรแกรมเชิงแง่มุม

ในด้านวิทยาการคอมพิวเตอร์การเขียนโปรแกรมเชิงแง่มุม (Aspect-Oriented ProgrammingหรือAOP ) เป็นกระบวนทัศน์การเขียนโปรแกรมที่มุ่งเพิ่มความเป็นโมดูลาร์โดยการแยกส่วนที่เกี่ยวข้องกับหลายส่วนออก จาก กัน โดยทำได้โดยการเพิ่มพฤติกรรมให้กับโค้ดที่มีอยู่แล้ว ( คำแนะนำ หรือ advice ) โดยไม่ต้องแก้ไขโค้ด แต่ระบุส่วนที่ต้องการแก้ไขแยกต่างหากผ่านข้อกำหนด " pointcut " เช่น "บันทึกการเรียกใช้ฟังก์ชันทั้งหมดเมื่อชื่อฟังก์ชันขึ้นต้นด้วย 'set ' " วิธีนี้ช่วยให้สามารถเพิ่มพฤติกรรมที่ไม่ใช่ส่วนสำคัญของตรรกะทางธุรกิจ (เช่น การบันทึกข้อมูล) ลงในโปรแกรมได้โดยไม่ทำให้โค้ดของฟังก์ชันหลักรกเกินไป

AOP ประกอบด้วยวิธีการและเครื่องมือการเขียนโปรแกรมที่สนับสนุนการแบ่งส่วนประเด็นต่างๆ ในระดับซอร์สโค้ด ในขณะที่การพัฒนาซอฟต์แวร์เชิงแง่มุมหมายถึงสาขาวิชาวิศวกรรมโดยรวม

การเขียนโปรแกรมเชิงแง่มุม (Aspect-oriented programming) คือการแบ่งตรรกะของโปรแกรมออกเป็นส่วนๆ ที่มีความสอดคล้องกันในด้านการทำงาน (เรียกว่า " ข้อกังวล ") เกือบทุกแนวคิดการเขียนโปรแกรมสนับสนุนการจัดกลุ่มและการห่อหุ้มข้อกังวลในระดับหนึ่ง โดยการแยกข้อกังวลเหล่านั้นออกเป็นหน่วยอิสระต่างๆ ด้วยการจัดเตรียมสิ่งที่เป็นนามธรรม (เช่น ฟังก์ชัน ขั้นตอน โมดูล คลาส เมธอด) ที่สามารถนำมาใช้ในการนำไปใช้ การสร้างนามธรรม และการประกอบข้อกังวลเหล่านั้น อย่างไรก็ตาม ข้อกังวลบางอย่าง "ตัดผ่าน" นามธรรมหลายๆ อย่างในโปรแกรม และไม่สามารถนำไปใช้ในรูปแบบเหล่านั้นได้ ข้อกังวลเหล่านี้เรียกว่าข้อกังวลที่ตัดข้าม (cross-cutting concerns)หรือ ข้อกังวลแนวนอน (horizontal concerns)

การบันทึกข้อมูลเป็นตัวอย่างของปัญหาที่ส่งผลกระทบต่อทุกส่วนของระบบ เนื่องจากกลยุทธ์การบันทึกข้อมูลต้องมีผลต่อทุกส่วนของระบบที่ถูกบันทึก ดังนั้น การบันทึกข้อมูลจึงส่งผลกระทบต่อคลาสและเมธอดทั้งหมดที่ถูกบันทึก

การใช้งาน AOP ทุกรูปแบบจะมีนิพจน์ที่ตัดข้ามส่วนต่างๆ (cross-cutting expressions) ซึ่งรวบรวมข้อกังวลแต่ละอย่างไว้ในที่เดียว ความแตกต่างระหว่างการใช้งานแต่ละแบบอยู่ที่ประสิทธิภาพ ความปลอดภัย และความสามารถในการใช้งานของโครงสร้างที่ให้มา ตัวอย่างเช่น ตัวดักจับ (interceptors) ที่ระบุวิธีการเพื่อแสดงรูปแบบการตัดข้ามส่วนที่จำกัด โดยไม่มีการสนับสนุนด้านความปลอดภัยของประเภทหรือการดีบักมากนักAspectJมีนิพจน์ดังกล่าวจำนวนมากและรวบรวมไว้ในคลาสพิเศษที่เรียกว่าaspectตัวอย่างเช่น aspect สามารถเปลี่ยนแปลงพฤติกรรมของโค้ดพื้นฐาน (ส่วนที่ไม่ใช่ aspect ของโปรแกรม) โดยการใช้advice (พฤติกรรมเพิ่มเติม) ที่จุดเชื่อมต่อ ต่างๆ (จุดในโปรแกรม) ที่ระบุไว้ในการกำหนดปริมาณหรือการสอบถามที่เรียกว่าpointcut (ซึ่งตรวจจับว่าจุดเชื่อมต่อที่กำหนดตรงกันหรือไม่) aspect ยังสามารถทำการเปลี่ยนแปลงโครงสร้างที่เข้ากันได้กับไบนารีในคลาสอื่นๆ เช่น การเพิ่มสมาชิกหรือผู้ปกครองได้

ประวัติศาสตร์

AOP มีต้นกำเนิดโดยตรงหลายประการ: [ 1 ]การสะท้อนและโปรโตคอลเมตาออบ เจ็กต์ การเขียนโปรแกรมเชิงหัวข้อ ตัวกรององค์ประกอบและการเขียนโปรแกรมแบบปรับตัว[ 2 ]

Gregor Kiczalesและเพื่อนร่วมงานที่Xerox PARCได้พัฒนาแนวคิด AOP อย่างชัดเจน และต่อยอดด้วย ส่วนขยาย AspectJ AOP สำหรับ Java ในขณะที่ทีมวิจัยของ IBM เลือกใช้แนวทางที่เน้นเครื่องมือมากกว่าการออกแบบภาษา และในปี 2001 ได้เสนอHyper/JและConcern Manipulation Environmentซึ่งไม่ได้รับการใช้งานอย่างแพร่หลาย

ตัวอย่างในบทความนี้ใช้ AspectJ เป็นตัวอย่างอ้างอิง

Microsoft Transaction Serverถือเป็นแอปพลิเคชันหลักแรกของ AOP ตามมาด้วยEnterprise JavaBeans [ 3 ] [ 4 ]

แรงจูงใจและแนวคิดพื้นฐาน

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

ตัวอย่างเช่น ลองพิจารณาแอปพลิเคชันด้านการธนาคารที่มีวิธีการโอนเงินจากบัญชีหนึ่งไปยังอีกบัญชีหนึ่งซึ่งง่ายมาก ตัวอย่างในภาษา Javaจะมีลักษณะดังนี้: 

คลาสปิดผนึกBankingException ขยายจากException อนุญาตให้InsufficientFundsException และUnauthorisedUserException { // ... }public class Bank { public void transfer ( Account fromAcc , Account toAcc , int amount ) throws BankingException { if ( fromAcc . getBalance () < amount ) { throw new InsufficientFundsException (); }fromAcc.withdraw ( amount ) ; toAcc.deposit ( amount ) ; } }​​

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

เวอร์ชันที่รวมข้อกังวลใหม่ ๆ เหล่านั้นอาจมีลักษณะดังนี้: 

import java.util.logging.* ;คลาสปิดผนึกBankingException ขยายจากException อนุญาตให้InsufficientFundsException และUnauthorisedUserException { // ... }public class Bank { private static final Logger logger ; private final Database database ; public void transfer ( Account fromAcc , Account toAcc , int amount , User user ) throws BankingException { logger . info ( "กำลังโอนเงิน..." ); if ( ! isUserAuthorised ( user , fromAcc )) { logger . log ( Level . WARNING , "ผู้ใช้ไม่มีสิทธิ์" ); throw new UnauthorisedUserException (); } if ( fromAcc . getBalance () < amount ) { logger . log ( Level . WARNING , "เงินไม่เพียงพอ" ); throw new InsufficientFundsException (); } }fromAcc.withdraw ( amount ) ; toAcc.deposit ( amount ) ;​​database.commitChanges ( ); // การดำเนินการแบบอะตอมิกlogger.log ( Level.INFO , " Transaction successful . " ) ; } }

ในตัวอย่างนี้ ผลประโยชน์อื่นๆ ได้เข้ามาเกี่ยวพันกับฟังก์ชันการทำงานพื้นฐาน (บางครั้งเรียกว่าข้อกังวลด้านตรรกะทางธุรกิจ ) การทำธุรกรรม ความปลอดภัย และการบันทึกข้อมูล ล้วนเป็นตัวอย่างของข้อ กังวลที่เกี่ยวข้องกับหลายด้าน

ทีนี้ลองพิจารณาดูว่าจะเกิดอะไรขึ้นหากเราจำเป็นต้องเปลี่ยนแปลงข้อกำหนดด้านความปลอดภัยสำหรับแอปพลิเคชันอย่างกะทันหัน ในเวอร์ชันปัจจุบันของโปรแกรม การดำเนินการที่เกี่ยวข้องกับความปลอดภัยดูเหมือนจะกระจัดกระจายอยู่ในหลายเมธอด และการเปลี่ยนแปลงดังกล่าวจะต้องใช้ความพยายามอย่างมาก

AOP พยายามแก้ปัญหานี้โดยอนุญาตให้โปรแกรมเมอร์แสดงความกังวลที่เกี่ยวข้องกับหลายส่วนในโมดูลอิสระที่เรียกว่าแง่ มุม ( aspects ) แง่มุมเหล่านี้สามารถประกอบด้วยคำแนะนำ (โค้ดที่เชื่อมต่อกับจุดที่กำหนดในโปรแกรม) และการประกาศระหว่างประเภท (สมาชิกโครงสร้างที่เพิ่มเข้าไปในคลาสอื่น) ตัวอย่างเช่น โมดูลความปลอดภัยสามารถรวมคำแนะนำที่ทำการตรวจสอบความปลอดภัยก่อนเข้าถึงบัญชีธนาคารจุดตัด (pointcut) กำหนดเวลา ( จุดเชื่อมต่อ ) ที่สามารถเข้าถึงบัญชีธนาคารได้ และโค้ดในส่วนเนื้อหาของคำแนะนำจะกำหนดวิธีการตรวจสอบความปลอดภัย ด้วยวิธีนี้ ทั้งการตรวจสอบและสถานที่ต่างๆ สามารถจัดการได้ในที่เดียว นอกจากนี้ จุดตัดที่ดีสามารถคาดการณ์การเปลี่ยนแปลงโปรแกรมในภายหลังได้ ดังนั้นหากนักพัฒนาคนอื่นสร้างวิธีการใหม่เพื่อเข้าถึงบัญชีธนาคาร คำแนะนำจะถูกนำไปใช้กับวิธีการใหม่เมื่อมีการเรียกใช้

ดังนั้นสำหรับตัวอย่างข้างต้นเกี่ยวกับการใช้งานการบันทึกข้อมูลในแง่มุม (aspect) มีดังนี้: 

aspect Logger { Logger logger ;void Bank.transfer ( Account fromAcc , Account toAcc , int amount , User user ) { logger.info ( " กำลัง โอนเงิน... " ) ; }void Bank.getMoneyBack ( User user , int transactionId ) { logger.info ( " User requested money back. " ) ; }// โค้ดส่วนอื่นๆ ที่เกี่ยวข้องกับหลายส่วนงาน}

อาจมองว่า AOP เป็นเครื่องมือสำหรับการดีบักหรือเครื่องมือระดับผู้ใช้ ควรสงวนคำแนะนำไว้สำหรับกรณีที่ไม่สามารถเปลี่ยนแปลงฟังก์ชันได้ (ระดับผู้ใช้) [ 5 ]หรือไม่ต้องการเปลี่ยนแปลงฟังก์ชันในโค้ดการผลิต (การดีบัก)

แบบจำลองจุดเชื่อมต่อ

ส่วนประกอบที่เกี่ยวข้องกับคำแนะนำในภาษาเชิงแง่มุมจะกำหนดแบบจำลองจุดเชื่อมต่อ (Join Point Model: JPM) JPM กำหนดสิ่งต่อไปนี้สามประการ:

  1. เมื่อคำแนะนำสามารถทำงานได้ จุดเหล่านี้เรียกว่าจุดเชื่อมต่อ (join points)เพราะเป็นจุดในโปรแกรมที่กำลังทำงานอยู่ ซึ่งสามารถเชื่อมต่อพฤติกรรมเพิ่มเติมได้อย่างมีประโยชน์ จุดเชื่อมต่อจะต้องสามารถเข้าถึงได้และเข้าใจได้โดยโปรแกรมเมอร์ทั่วไปจึงจะมีประโยชน์ นอกจากนี้ยังควรมีความเสถียรต่อการเปลี่ยนแปลงโปรแกรมที่ไม่สำคัญ เพื่อรักษาเสถียรภาพของแง่มุมต่างๆ การใช้งาน AOP หลายๆ อย่างรองรับการเรียกใช้เมธอดและการอ้างอิงฟิลด์เป็นจุดเชื่อมต่อ
  2. วิธีการระบุ (หรือวัดปริมาณ ) จุดเชื่อมต่อที่เรียกว่าpointcuts pointcuts จะตรวจสอบว่าจุดเชื่อมต่อที่กำหนดนั้นตรงกันหรือไม่ ภาษา pointcut ที่มีประโยชน์ส่วนใหญ่จะใช้ไวยากรณ์คล้ายกับภาษาพื้นฐาน (ตัวอย่างเช่นAspectJใช้ลายเซ็นของ Java) และอนุญาตให้ใช้ซ้ำได้ผ่านการตั้งชื่อและการรวมกัน
  3. วิธีการกำหนดโค้ดที่จะทำงาน ณ จุดเชื่อมต่อAspectJเรียกสิ่งนี้ว่าadviceและสามารถเรียกใช้งานได้ก่อน หลัง และรอบๆ จุดเชื่อมต่อ บางเวอร์ชันยังรองรับการกำหนดเมธอดใน aspect บนคลาสอื่นด้วย

สามารถเปรียบเทียบโมเดลจุดเชื่อมต่อได้โดยพิจารณาจากจุดเชื่อมต่อที่เปิดเผย วิธีการระบุจุดเชื่อมต่อ การดำเนินการที่อนุญาต ณ จุดเชื่อมต่อ และการปรับปรุงโครงสร้างที่สามารถแสดงออกมาได้

โมเดลจุดเชื่อมต่อของ AspectJ

  • จุดเชื่อมต่อใน AspectJ ได้แก่ การเรียกหรือการเรียกใช้เมธอดหรือคอนสตรัคเตอร์ การเริ่มต้นใช้งานคลาสหรืออ็อบเจ็กต์ การเข้าถึงการอ่านและการเขียนฟิลด์ และตัวจัดการข้อยกเว้น แต่ไม่รวมถึงลูป การเรียก super การใช้คำสั่ง throw หรือคำสั่งหลายคำสั่งพร้อมกัน
  • จุดตัดจะถูกกำหนดโดยการรวมกันของตัวกำหนดจุดตัดพื้นฐาน (PCDs)

    "PCD ที่มีประเภทเดียวกัน" จะจับคู่กับจุดเชื่อมต่อประเภทใดประเภทหนึ่งโดยเฉพาะ (เช่น การเรียกใช้เมธอด) และมักจะรับรูปแบบลายเซ็นที่คล้ายกับภาษา Java เป็นอินพุต ตัวอย่างของ pointcut ดังกล่าวมีลักษณะดังนี้: 

    การดำเนินการ( * ตั้งค่า* ( * ))

    จุดตัดนี้จะตรงกับจุดเชื่อมต่อการเรียกใช้เมธอด หากชื่อเมธอดขึ้นต้นด้วย " set" และมีอาร์กิวเมนต์เพียงหนึ่งตัวเท่านั้น ไม่ว่าจะเป็นประเภทใดก็ตาม

    PCD แบบ "ไดนามิก" จะตรวจสอบประเภทขณะทำงานและผูกตัวแปร ตัวอย่างเช่น 

    จุดนี้( จุด)

    จุดตัดนี้จะตรงกันเมื่ออ็อบเจ็กต์ที่กำลังทำงานอยู่เป็นอินสแตนซ์ของคลาสPointโปรดทราบว่าสามารถใช้ชื่อคลาสแบบไม่ระบุคุณสมบัติได้ผ่านการค้นหาประเภทปกติของ Java

    PCD ประเภท "ขอบเขต" จะจำกัดขอบเขตทางคำศัพท์ของจุดเชื่อมต่อ ตัวอย่างเช่น: 

    ภายใน( com.company . * )​​

    จุดตัดนี้ตรงกับจุดเชื่อมต่อใดๆ ในประเภทใดๆ ในcom.companyแพ็กเกจ นี่*เป็นรูปแบบหนึ่งของสัญลักษณ์ตัวแทน (wildcards) ที่สามารถใช้จับคู่หลายสิ่งหลายอย่างด้วยลายเซ็นเดียว

    สามารถประกอบและตั้งชื่อ Pointcuts เพื่อนำกลับมาใช้ใหม่ได้ ตัวอย่างเช่น: 

    pointcut set () : execution ( * set * ( * ) ) && this ( Point ) && within ( com . company . * );
    จุดตัดนี้จะตรงกับจุดเชื่อมต่อการเรียกใช้เมธอด หากชื่อเมธอดขึ้นต้นด้วย " set" และthisเป็นอินสแตนซ์ของประเภทPointในcom.companyแพ็กเกจ สามารถอ้างอิงถึงได้โดยใช้ชื่อ " set()"
  • Advice ระบุให้รันโค้ดบางส่วน (ระบุเหมือนโค้ดในเมธอด) ณ จุดเชื่อมต่อ (ระบุด้วย pointcut) (ก่อน หลัง หรือบริเวณใกล้เคียง) รันไทม์ AOP จะเรียกใช้ Advice โดยอัตโนมัติเมื่อ pointcut ตรงกับจุดเชื่อมต่อ ตัวอย่างเช่น: 
    หลังจาก() : ตั้งค่า() { แสดงผล. อัปเดต(); }
    โดยหลักแล้วหมายความว่า: "ถ้าset()จุดตัดตรงกับจุดเชื่อมต่อ ให้รันโค้ดDisplay.update()หลังจากที่จุดเชื่อมต่อเสร็จสมบูรณ์"

รูปแบบจุดเชื่อมต่อที่เป็นไปได้อื่นๆ

นอกจากนี้ยังมี JPM ประเภทอื่นๆ อีก ภาษาให้คำแนะนำทั้งหมดสามารถกำหนดได้ในแง่ของ JPM ของตนเอง ตัวอย่างเช่น ภาษาแง่มุมสมมติสำหรับUMLอาจมี JPM ดังต่อไปนี้:

  • จุดเชื่อมต่อทั้งหมดเป็นองค์ประกอบของโมเดล
  • Pointcuts คือนิพจน์บูลีน บางอย่าง ที่รวมองค์ประกอบของโมเดลเข้าด้วยกัน
  • วิธีการแสดงผลผลกระทบ ณ จุดเหล่านี้ คือการแสดงภาพจุดเชื่อมต่อที่ตรงกันทั้งหมด

การประกาศระหว่างประเภท

การประกาศแบบ Inter-typeเป็นวิธีหนึ่งในการแสดงความกังวลที่ส่งผลกระทบต่อโครงสร้างของโมดูลต่างๆ หรือที่รู้จักกันในชื่อคลาสแบบเปิดและเมธอดส่วนขยายซึ่งช่วยให้นักเขียนโปรแกรมสามารถประกาศสมาชิกหรือคลาสแม่ของคลาสอื่นไว้ในที่เดียว โดยทั่วไปเพื่อรวมโค้ดทั้งหมดที่เกี่ยวข้องกับความกังวลในแง่มุมเดียว ตัวอย่างเช่น หากนักเขียนโปรแกรมใช้ Visitor ในการจัดการความกังวลเกี่ยวกับการแสดงผลและการอัปเดต การประกาศแบบ Inter-type โดยใช้รูปแบบ Visitorใน AspectJ อาจมีลักษณะดังนี้: 

aspect DisplayUpdate { void Point . acceptVisitor ( Visitor v ) { v . visit ( this ); } // โค้ดส่วนอื่นๆ ที่เกี่ยวข้อง... }

โค้ดส่วนนี้จะเพิ่มacceptVisitorเมธอดเข้าไปในPointคลาส

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

การดำเนินการ

โปรแกรม AOP สามารถส่งผลกระทบต่อโปรแกรมอื่นได้สองวิธีที่แตกต่างกัน ขึ้นอยู่กับภาษาและสภาพแวดล้อมพื้นฐาน:

  1. โปรแกรมแบบผสมผสานจะถูกสร้างขึ้น ซึ่งใช้งานได้ในภาษาต้นฉบับและไม่สามารถแยกแยะได้จากโปรแกรมทั่วไปสำหรับตัวแปลภาษาขั้นสุดท้าย
  2. ตัวแปลภาษาหรือสภาพแวดล้อมขั้นสุดท้ายได้รับการอัปเดตเพื่อให้เข้าใจและใช้งานคุณสมบัติ AOP ได้

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

ระบบต่างๆ สามารถใช้งานการถักทอระดับซอร์สโค้ดได้โดยใช้พรีโปรเซสเซอร์ (เช่นเดียวกับที่ C++ ใช้ในCFront ในช่วงแรก ) ซึ่งต้องเข้าถึงไฟล์ซอร์สโค้ดของโปรแกรม อย่างไรก็ตาม รูปแบบไบนารีที่กำหนดไว้อย่างดีของ Java ช่วยให้ตัวถักทอไบต์โค้ดสามารถทำงานกับโปรแกรม Java ใดๆ ก็ได้ในรูปแบบไฟล์ .class ตัวถักทอไบต์โค้ดสามารถใช้งานได้ในระหว่างกระบวนการสร้าง หรือหากโมเดลการถักทอเป็นแบบต่อคลาส ก็สามารถใช้งานได้ในระหว่างการโหลดคลาสAspectJเริ่มต้นด้วยการถักทอระดับซอร์สโค้ดในปี 2001 นำเสนอตัวถักทอไบต์โค้ดแบบต่อคลาสในปี 2002 และนำเสนอการสนับสนุนขั้นสูงในระหว่างการโหลดหลังจากรวมAspectWerkzในปี 2005

โซลูชันใดๆ ที่รวมโปรแกรมเข้าด้วยกันในระหว่างการทำงานจะต้องมีมุมมองที่แยกโปรแกรมเหล่านั้นออกจากกันอย่างเหมาะสม เพื่อรักษารูปแบบการแยกส่วนของโปรแกรมเมอร์ไว้ การรองรับไบต์โค้ดของ Java สำหรับไฟล์ต้นฉบับหลายไฟล์ทำให้ดีบักเกอร์ใดๆ ก็สามารถก้าวผ่านไฟล์ .class ที่รวมเข้าด้วยกันอย่างถูกต้องในโปรแกรมแก้ไขซอร์สโค้ดได้ อย่างไรก็ตาม โปรแกรมดีคอมไพเลอร์ของบุคคลที่สามบางตัวไม่สามารถประมวลผลโค้ดที่รวมเข้าด้วยกันได้ เนื่องจากโปรแกรมเหล่านั้นคาดหวังโค้ดที่สร้างโดย Javac มากกว่ารูปแบบไบต์โค้ดที่รองรับทั้งหมด (ดูเพิ่มเติมในหัวข้อ§ ข้อวิจารณ์ด้านล่าง)

การถักทอ ในระหว่างการปรับใช้เสนอแนวทางอื่น[ 6 ]โดยพื้นฐานแล้วหมายถึงการประมวลผลภายหลัง แต่แทนที่จะแก้ไขโค้ดที่สร้างขึ้น แนวทางการถักทอนี้จะ สร้าง คลาสย่อยของคลาสที่มีอยู่เพื่อให้การแก้ไขถูกนำมาใช้โดยการเขียนทับเมธอด คลาสที่มีอยู่ยังคงไม่ถูกแตะต้องแม้ในขณะรันไทม์ และเครื่องมือที่มีอยู่ทั้งหมด เช่น ดีบักเกอร์และโปรไฟล์เลอร์ สามารถใช้งานได้ในระหว่างการพัฒนา แนวทางที่คล้ายกันนี้ได้รับการพิสูจน์แล้วในการใช้งานเซิร์ฟเวอร์ แอปพลิเคชัน Java EE หลายแห่ง เช่นWebSphereของIBM

ศัพท์เฉพาะ

คำศัพท์มาตรฐานที่ใช้ในการเขียนโปรแกรมเชิงแง่มุมอาจรวมถึง:

ประเด็นที่เกี่ยวข้องในหลายด้าน
แม้ว่าคลาสส่วนใหญ่ในโมเดลเชิงวัตถุจะทำหน้าที่เฉพาะอย่างใดอย่างหนึ่ง แต่ก็มักจะมีความต้องการรองร่วมกันกับคลาสอื่นๆ ตัวอย่างเช่น เราอาจต้องการเพิ่มการบันทึกข้อมูลให้กับคลาสในเลเยอร์การเข้าถึงข้อมูล และให้กับคลาสในเลเยอร์ UI เมื่อใดก็ตามที่เธรดเข้าหรือออกจากเมธอด ข้อกังวลเพิ่มเติมอาจเกี่ยวข้องกับความปลอดภัย เช่นการควบคุมการเข้าถึง[ 7 ]หรือ การ ควบคุมการไหลของข้อมูล[ 8 ]แม้ว่าแต่ละคลาสจะมีฟังก์ชันหลักที่แตกต่างกันมาก แต่โค้ดที่จำเป็นในการดำเนินการฟังก์ชันรองมักจะเหมือนกัน
คำแนะนำ
นี่คือโค้ดเพิ่มเติมที่คุณต้องการนำไปใช้กับโมเดลที่มีอยู่แล้ว ในตัวอย่างนี้ นี่คือโค้ดสำหรับการบันทึกข้อมูลที่เราต้องการใช้ทุกครั้งที่เธรดเข้าหรือออกจากเมธอด:
จุดตัด
หมายถึงจุดการทำงานของแอปพลิเคชันที่จำเป็นต้องใช้หลักการตัดข้ามส่วน (cross-cutting concern) ในตัวอย่างของเรา จุดตัดหนึ่งเกิดขึ้นเมื่อเธรดเข้าสู่เมธอด และอีกจุดตัดหนึ่งเกิดขึ้นเมื่อเธรดออกจากเมธอด
ด้าน
การรวมกันของ pointcut และ advice เรียกว่า aspect ในตัวอย่างข้างต้น เราเพิ่ม aspect การบันทึกข้อมูลลงในแอปพลิเคชันของเราโดยการกำหนด pointcut และให้ advice ที่ถูกต้อง

เมื่อเปรียบเทียบกับรูปแบบการเขียนโปรแกรมอื่นๆ

แนวคิดเรื่อง Aspect เกิดขึ้นจากแนวคิดการเขียนโปรแกรมเชิงวัตถุและการเขียนโปรแกรมเชิงสะท้อนภาษา AOP มีฟังก์ชันการทำงานที่คล้ายคลึงกัน แต่มีข้อจำกัดมากกว่าโปรโตคอลเมตาออบเจ็กต์ Aspect เกี่ยวข้องอย่างใกล้ชิดกับแนวคิดการเขียนโปรแกรม เช่นหัวข้อ (subjects ) มิกซ์อิน (mixins)และการมอบหมาย (delegation ) วิธีการอื่นๆ ในการใช้กระบวนทัศน์การเขียนโปรแกรมเชิง Aspect ได้แก่ตัวกรององค์ประกอบ (Composition Filters)และ แนวทาง ไฮเปอร์สไลซ์ (hyperslices ) อย่างน้อยตั้งแต่ทศวรรษ 1970 นักพัฒนาได้ใช้รูปแบบของการดักจับและการแก้ไขการส่งคำสั่งที่คล้ายกับวิธีการใช้งานบางอย่างของ AOP แต่สิ่งเหล่านี้ไม่เคยมีอรรถศาสตร์ที่ข้อกำหนดแบบตัดขวาง (cross-cutting specifications) ให้ไว้ในที่เดียว

นักออกแบบได้พิจารณาวิธีการอื่น ๆ เพื่อให้เกิดการแยกส่วนของโค้ด เช่น ประเภทบางส่วน (partial types) ของ C#แต่แนวทางเหล่านั้นขาดกลไกการกำหนดปริมาณที่ช่วยให้สามารถเข้าถึงจุดเชื่อมต่อหลายจุดของโค้ดได้ด้วยคำสั่งประกาศเพียงคำสั่งเดียว

แม้ว่าอาจดูไม่เกี่ยวข้องกัน แต่ในการทดสอบ การใช้ mock หรือ stub จำเป็นต้องใช้เทคนิค AOP เช่น around advice ในที่นี้ วัตถุที่ทำงานร่วมกันนั้นมีไว้เพื่อวัตถุประสงค์ของการทดสอบ ซึ่งเป็นประเด็นที่เกี่ยวข้องกับหลายส่วน ดังนั้น เฟรมเวิร์ก Mock Object ต่างๆ จึงมีคุณสมบัติเหล่านี้ ตัวอย่างเช่น กระบวนการหนึ่งเรียกใช้บริการเพื่อรับยอดเงินคงเหลือ ในการทดสอบกระบวนการนั้น ไม่สำคัญว่ายอดเงินจะมาจากที่ใด แต่สำคัญเพียงแค่ว่ากระบวนการนั้นใช้ยอดเงินคงเหลือตามข้อกำหนดหรือไม่

ปัญหาเกี่ยวกับการรับเลี้ยงบุตรบุญธรรม

โปรแกรมเมอร์จำเป็นต้องอ่านและเข้าใจโค้ดเพื่อป้องกันข้อผิดพลาด[ 9 ] แม้จะได้รับการศึกษาอย่างเหมาะสม การเข้าใจประเด็นข้ามส่วนอาจเป็นเรื่องยากหากไม่มีการสนับสนุนที่เหมาะสมสำหรับการแสดงภาพทั้งโครงสร้างคงที่และการไหลแบบไดนามิกของโปรแกรม[ 10 ]ตั้งแต่ปี 2002 AspectJ เริ่มให้บริการปลั๊กอิน IDE เพื่อสนับสนุนการแสดงภาพประเด็นข้ามส่วน คุณสมบัติเหล่านั้น รวมถึงการช่วยเหลือโค้ดและการปรับโครงสร้างใหม่ ของแง่มุมต่างๆ กลาย เป็นเรื่องปกติในปัจจุบัน

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

การวิจารณ์

คำวิจารณ์พื้นฐานที่สุดเกี่ยวกับผลของ AOP คือการควบคุมการไหลของโปรแกรมถูกบดบัง และไม่เพียงแต่แย่กว่า คำสั่ง GOTO ที่ถูกวิพากษ์วิจารณ์อย่างมากเท่านั้น แต่ยังคล้ายคลึงกับคำสั่งCOME FROM ที่เป็นเรื่องตลกอีกด้วย [ 10 ]การไม่รับรู้ถึงการประยุกต์ใช้ซึ่งเป็นพื้นฐานของคำจำกัดความของ AOP หลายประการ (โค้ดที่เกี่ยวข้องไม่มีการบ่งชี้ว่าคำแนะนำจะถูกนำไปใช้ ซึ่งระบุไว้ใน pointcut แทน) หมายความว่าคำแนะนำนั้นไม่สามารถมองเห็นได้ ตรงกันข้ามกับการเรียกใช้เมธอดอย่างชัดเจน[ 10 ] [ 11 ]ตัวอย่างเช่น ลองเปรียบเทียบโปรแกรม COME FROM: [ 10 ]

5 อินพุตX 10 พิมพ์'ผลลัพธ์คือ :' 15 พิมพ์X 20 มาจาก10 25 X = X * X 30 กลับ

โดยใช้ส่วนประกอบ AOP ที่มีความหมายคล้ายคลึงกัน: 

main () { รับค่าx และพิมพ์ผลลัพธ์( x ) }รับผลลัพธ์( int x ) { คืนค่าx }วนรอบ( int x ): เรียก( result ( int )) && args ( x ) { int temp = proceed ( x ) คืนค่า temp * temp }

อันที่จริง จุดตัดอาจขึ้นอยู่กับสภาวะขณะรันไทม์ และดังนั้นจึงไม่สามารถกำหนดได้อย่างแน่นอนในเชิงสถิต ปัญหานี้สามารถแก้ไขได้ด้วยการวิเคราะห์เชิงสถิตและการสนับสนุนจาก IDE ที่แสดงคำแนะนำที่อาจตรงกัน แต่ปัญหานี้ไม่สามารถแก้ไขได้อย่างสมบูรณ์

โดยทั่วไปแล้วมีการวิจารณ์ว่า AOP อ้างว่าสามารถปรับปรุง "ทั้งความเป็นโมดูลและโครงสร้างของโค้ด" แต่บางคนโต้แย้งว่ามันกลับบั่นทอนเป้าหมายเหล่านี้และขัดขวาง "การพัฒนาที่เป็นอิสระและความเข้าใจได้ของโปรแกรม" [ 12 ]โดยเฉพาะอย่างยิ่ง การวัดปริมาณด้วย pointcuts ทำลายความเป็นโมดูล: "โดยทั่วไปแล้ว เราต้องมีความรู้เกี่ยวกับโปรแกรมทั้งหมดเพื่อที่จะให้เหตุผลเกี่ยวกับการทำงานแบบไดนามิกของโปรแกรมเชิงแง่มุม" [ 13 ]นอกจากนี้ แม้ว่าเป้าหมายของมัน (การแบ่งส่วนความกังวลที่ตัดข้าม) จะเป็นที่เข้าใจกันดี แต่คำจำกัดความที่แท้จริงของมันกลับไม่ชัดเจนและไม่ได้แยกแยะอย่างชัดเจนจากเทคนิคอื่นๆ ที่ได้รับการยอมรับ[ 12 ]ความกังวลที่ตัดข้ามอาจตัดกันเอง ซึ่งต้องใช้กลไกการแก้ไขบางอย่าง เช่น การจัดลำดับ[ 12 ]อันที่จริง แง่มุมต่างๆ สามารถนำไปใช้กับตัวเองได้ ซึ่งนำไปสู่ปัญหาต่างๆ เช่นปรากฏการณ์คนโกหก[ 14 ]

ข้อวิจารณ์ทางเทคนิครวมถึงการกำหนดปริมาณของ pointcuts (ซึ่งกำหนดตำแหน่งที่ดำเนินการคำแนะนำ) ว่า "มีความอ่อนไหวอย่างมากต่อการเปลี่ยนแปลงในโปรแกรม" ซึ่งเป็นที่รู้จักกันในชื่อปัญหา pointcut ที่เปราะบาง [ 12 ] ปัญหาเกี่ยวกับ pointcuts ถือว่าแก้ไขไม่ได้ หากแทนที่การกำหนดปริมาณของ pointcuts ด้วยคำอธิบายประกอบที่ชัดเจน จะได้การเขียนโปรแกรมเชิงคุณลักษณะแทน ซึ่งเป็นเพียงการเรียกใช้ซับรูทีนที่ชัดเจนและประสบปัญหาเดียวกันคือปัญหาการกระจัดกระจาย ซึ่ง AOP ได้รับการออกแบบมาเพื่อแก้ไข[ 12 ]

การนำไปใช้

ภาษาโปรแกรมหลาย ภาษา ได้นำ AOP มาใช้แล้ว ไม่ว่าจะภายในภาษาเองหรือในรูปแบบของไลบรารี ภายนอก ซึ่งรวมถึง:

ดูเพิ่มเติม

หมายเหตุและเอกสารอ้างอิง

  1. ^ Kiczales, G. ; Lamping, J.; Mendhekar, A.; Maeda, C.; Lopes, C.; Loingtier, JM; Irwin, J. (1997). การเขียนโปรแกรมเชิงแง่มุม (PDF) . ECOOP'97. รายงานการประชุม European Conference on Object-Oriented Programming ครั้งที่ 11 . Lecture Notes in Computer Science (LNCS). เล่มที่ 1241. หน้า  220– 242. CiteSeerX  10.1.1.115.8660 . doi : 10.1007/BFb0053381 . ISBN 3-540-63089-9จัดเก็บในรูปแบบไฟล์ PDFจากต้นฉบับเมื่อวันที่ 12 มกราคม 2559
  2. ^ "การเขียนโปรแกรมเชิงวัตถุแบบปรับตัวได้: แนวทางของเดเมเตอร์พร้อมรูปแบบการแพร่กระจาย"คาร์ล ลีบเฮอร์ 1996 ISBN 0-534-94602-Xนำเสนอเวอร์ชันที่ปรับปรุงมาอย่างดีของสิ่งเดียวกันโดยพื้นฐาน (ต่อมา Lieberherr ตระหนักถึงเรื่องนี้และปรับเปลี่ยนแนวทางของเขา)
  3. ^ Don Box; Chris Sells ( 4 พฤศจิกายน 2002). Essential.NET: The common language runtime . Addison-Wesley Professional. หน้า  206. ISBN 978-0-201-73411-9สืบค้นข้อมูลเมื่อ วัน ที่4 ตุลาคม 2554
  4. ^ Roman, Ed; Sriganesh, Rima Patel; Brose, Gerald (1 มกราคม 2005). Mastering Enterprise JavaBeans . John Wiley and Sons. หน้า 285. ISBN 978-0-7645-8492-3สืบค้นข้อมูลเมื่อ วัน ที่4 ตุลาคม 2554
  5. ^ "gnu.org" . โครงการ GNU. เก็บถาวรจากต้นฉบับเมื่อวันที่ 24 ธันวาคม 2017 . เรียกดูเมื่อวันที่ 5 พฤษภาคม 2018 .
  6. ^ "สำเนาที่เก็บถาวร" (PDF)เก็บถาวรจากต้นฉบับ(PDF)เมื่อวันที่ 8 ตุลาคม 2548 เรียกดูเมื่อวันที่ 19 มิถุนายน 2548{{cite web}}: CS1 maint: archived copy as title ( link )
  7. ^บี. เดอ วิน, บี. แวนฮอท และ บี. เดอ เดคเกอร์. "การรักษาความปลอดภัยผ่านการเขียนโปรแกรมเชิงแง่มุม" ในความก้าวหน้าในการรักษาความปลอดภัยเครือข่ายและระบบกระจาย (2002)
  8. ^ T. Pasquier, J. Bacon และ B. Shand. "FlowR: การเขียนโปรแกรมเชิงแง่มุมเพื่อควบคุมการไหลของข้อมูลใน Ruby" ใน ACM Proceedings of the 13th international conference on Modularity (Aspect Oriented Software Development) (2014).
  9. ^ Edsger Dijkstra , Notes on Structured Programmingเก็บถาวรเมื่อ 2006-10-12 ที่ Wayback Machine , หน้า 1-2
  10. ^ a b c d Constantinides, Constantinos; Skotiniotis, Therapon; Störzer, Maximilian (กันยายน 2004). AOP ถือว่าเป็นอันตราย (PDF) . การประชุมเชิงปฏิบัติการเชิงโต้ตอบของยุโรปเกี่ยวกับแง่มุมต่างๆ ในซอฟต์แวร์ (EIWAS). เบอร์ลิน ประเทศเยอรมนี. เก็บถาวร(PDF)จากต้นฉบับเมื่อวันที่ 23 มีนาคม 2016 . สืบค้นเมื่อ5 พฤษภาคม 2018 .
  11. ^ C2:มาจาก
  12. ^ a b c d e Steimann, F. (2006). "ความสำเร็จที่ขัดแย้งกันของการเขียนโปรแกรมเชิงแง่มุม" ACM SIGPLAN Notices . 41 (10): 481– 497. CiteSeerX 10.1.1.457.2210 . doi : 10.1145/1167515.1167514 . ( สไลด์ชุด ที่ 2 เก็บถาวรเมื่อวันที่ 4 มีนาคม 2016 ที่Wayback Machine , สไลด์ชุดที่ 2 เก็บถาวรเมื่อวันที่ 23 กันยายน 2015 ที่Wayback Machine , บทคัดย่อเก็บถาวรเมื่อวันที่ 24 กันยายน 2015 ที่Wayback Machine ), Friedrich Steimann, Gary T. Leavens, OOPSLA 2006
  13. ^ "การให้เหตุผลแบบโมดูลาร์เพิ่มเติมสำหรับโปรแกรมเชิงแง่มุม" . เก็บถาวรจากต้นฉบับเมื่อวันที่ 12 สิงหาคม 2558 . เรียกดูเมื่อวันที่ 11 สิงหาคม 2558 .
  14. ^ "AOP และความขัดแย้งของคนโกหก" (PDF) . fernuni-hagen.de . เก็บถาวร(PDF)จากต้นฉบับเมื่อวันที่ 9 สิงหาคม 2017 . เรียกดูเมื่อวันที่ 5 พฤษภาคม 2018 .
  15. ^จำนวนมาก: Afterthought เก็บถาวรเมื่อ 2016-03-15 ที่ Wayback Machine , LOOM.NET เก็บถาวรเมื่อ 2008-08-27 ที่ Wayback Machine , Enterprise Library 3.0 Policy Injection Application Block เก็บถาวรเมื่อ 2007-01-19 ที่ Wayback Machine , AspectDNG เก็บถาวรเมื่อ 2004-09-29 ที่ Wayback Machine , DynamicProxy เก็บถาวรเมื่อ 2015-12-05 ที่ Wayback Machine , Compose* เก็บถาวรเมื่อ 2005-08-21 ที่ Wikiwix, PostSharp เก็บถาวร เมื่อ 2016-05-03 ที่ Wayback Machine , Seasar.NET เก็บถาวรเมื่อ 2006-07-25 ที่ Wayback Machine , DotSpect (.SPECT) เก็บถาวรเมื่อ 2006-03-31 ที่ Wayback Machine , Spring.NET เก็บถาวรเมื่อ 2006-04-02 ที่ Wayback Machine (ซึ่งเป็นส่วนหนึ่งของฟังก์ชันการทำงาน), Wicca และ Phx.Morph ถูกเก็บถาวรเมื่อวันที่ 7 ธันวาคม 2006 ที่ Wayback Machine , SetPoint ถูกเก็บถาวรเมื่อวันที่ 7 ตุลาคม 2008 ที่ Wayback Machine
  16. ^ "ยินดีต้อนรับสู่ as3-commons-bytecode" . as3commons.org . เก็บถาวรจากต้นฉบับเมื่อวันที่ 3 ตุลาคม 2014 . เรียกดูเมื่อวันที่ 5 พฤษภาคม 2018 .
  17. ^ "เหตุผลของ Ada2012" (PDF) . adacore.com . เก็บถาวร(PDF)จากต้นฉบับเมื่อวันที่ 18 เมษายน 2016 . เรียกดูเมื่อวันที่ 5 พฤษภาคม 2018 .
  18. ^ "ฟังก์ชันฮุก" . autohotkey.com . สืบค้นเมื่อ 5 พฤษภาคม 2018 .{{cite web}}: CS1 maint: บริการเก็บถาวรที่เลิกใช้แล้ว ( ลิงก์ )
  19. ^หลายรายการ: AspectC++ , FeatureC++ , AspectC เก็บถาวรเมื่อ 2006-08-21 ที่ Wayback Machine , AspeCt-oriented C เก็บถาวรเมื่อ 2008-11-20 ที่ Wayback Machine , Aspicere
  20. ^ "Cobble" . vub.ac.be . สืบค้นเมื่อ5 พฤษภาคม 2018 .
  21. ^ "AspectCocoa" . neu.edu . เก็บถาวรจากต้นฉบับเมื่อวันที่ 26 ตุลาคม 2550 . เรียกดูเมื่อวันที่ 5 พฤษภาคม 2561 .
  22. ^ "ColdSpring Framework: ยินดีต้อนรับ" 5 พฤศจิกายน 2005. เก็บถาวรจากต้นฉบับเมื่อ 5 พฤศจิกายน 2005. เรียกดูเมื่อ5 พฤษภาคม 2018 .{{cite web}}: CS1 maint: bot: สถานะ URL เดิมไม่ทราบ ( ลิงก์ )
  23. ^ "โครงการ Closer: AspectL" . เก็บถาวรจากต้นฉบับเมื่อวันที่ 23 กุมภาพันธ์ 2011 . เรียกดูเมื่อวันที่ 11 สิงหาคม 2015 .
  24. ^ "infra – Frameworks Integrados para Delphi – Google Project Hosting" . เก็บถาวรจากต้นฉบับเมื่อวันที่ 9 กันยายน 2015 . เรียกดูเมื่อวันที่ 11 สิงหาคม 2015 .
  25. ^ "meaop – MeSDK: MeObjects, MeRTTI, MeAOP – Delphi AOP (Aspect Oriented Programming), MeRemote, MeService... – Google Project Hosting" . เก็บถาวรจากต้นฉบับเมื่อวันที่ 10 กันยายน 2015 . เรียกดูเมื่อวันที่ 11 สิงหาคม 2015 .
  26. ^ "Google Project Hosting" . เก็บถาวรจากต้นฉบับเมื่อวันที่ 25 ธันวาคม 2014 . เรียกดูเมื่อวันที่ 11 สิงหาคม 2015 .
  27. ^ "RemObjects Cirrus" . codegear.com . เก็บถาวรจากต้นฉบับเมื่อวันที่ 23 มกราคม 2012 . เรียกดูเมื่อวันที่ 5 พฤษภาคม 2018 .
  28. ^ "ฟังก์ชันคำแนะนำของ Emacs"โครงการ GNU เก็บถาวรจากต้นฉบับเมื่อวันที่ 24 ตุลาคม 2011 เรียกดูเมื่อวันที่ 5 พฤษภาคม 2018
  29. ^ Monadsช่วยให้สามารถเปลี่ยนแปลงความหมายของโปรแกรมได้โดยการเปลี่ยนประเภทของโปรแกรมโดยไม่ต้องแก้ไขโค้ด: De Meuter, Wolfgang (1997). "Monads As a theoretical basis for AOP". International Workshop on Aspect-Oriented Programming at ECOOP : 25. CiteSeerX 10.1.1.25.8262 . Tabareau, Nicolas; Figueroa, Ismael; Tanter, Éric (มีนาคม 2013). "การฝังแบบโมนาดิกที่มีประเภทของแง่มุม" . รายงานการประชุมนานาชาติประจำปีครั้งที่ 12 ว่าด้วยการพัฒนาซอฟต์แวร์เชิงแง่มุม (PDF) . Aosd '13. หน้า  171– 184. doi : 10.1145/2451436.2451457 . ISBN 9781450317665. S2CID  27256161 .คลาสประเภทช่วยให้สามารถเพิ่มความสามารถเพิ่มเติมให้กับประเภทได้: Sulzmann, Martin; Wang, Meng (มีนาคม 2007). " การเขียนโปรแกรมเชิงแง่มุมด้วยคลาสประเภท" รายงานการประชุมเชิงปฏิบัติการครั้งที่ 6 เรื่องพื้นฐานของภาษาเชิงแง่มุม (PDF)หน้า  65–74 . doi : 10.1145/1233833.1233842 . ISBN 978-1595936615. S2CID  3253858 ..
  30. ^ตัวอย่างอื่นๆ อีกมากมาย: CaesarJ เก็บถาวรเมื่อ 2008-12-19 ที่ Wayback Machine , Compose* เก็บถาวรเมื่อ 2005-08-21 ที่ Wikiwix, Dynaop เก็บถาวรเมื่อ 2007-07-24 ที่ Wayback Machine , JAC เก็บถาวรเมื่อ 2004-06-19 ที่ Wayback Machine , Google Guice (เป็นส่วนหนึ่งของฟังก์ชันการทำงาน), Javassist เก็บถาวร เมื่อ 2004-09-01 ที่ Wayback Machine , JAsCo (และ AWED) เก็บถาวร เมื่อ 2005-04-11 ที่ Wayback Machine , JAML เก็บถาวรเมื่อ 2005-04-15 ที่, JBoss AOP เก็บถาวรเมื่อ 2006-10-17 ที่ Wayback Machine , LogicAJ เก็บถาวรเมื่อ 2006-05-04 ที่ Wayback Machine , Object Teams เก็บถาวร 31 สิงหาคม 2548 ที่ Wayback Machine , PROSE เก็บถาวรเมื่อ 24 มกราคม 2550 ที่ Wayback Machine ,คอมไพเลอร์ AspectBench สำหรับ AspectJ (abc) เก็บถาวรเมื่อ 16 ธันวาคม 2557 ที่ Wayback Machine ,เฟรมเวิร์ก Spring (เป็นส่วนหนึ่งของฟังก์ชันการทำงาน), Seasar ,โครงการ JMangler เก็บถาวรเมื่อ 28 ตุลาคม 2548 ที่ Wayback Machine , InjectJ เก็บถาวรเมื่อ 5 เมษายน 2548 ที่ Wayback Machine , GluonJ เก็บถาวรเมื่อ 6 กุมภาพันธ์ 2550 ที่ Wayback Machine , Steamloom เก็บถาวรเมื่อ 18 สิงหาคม 2550 ที่ Wayback Machine
  31. ^หลายรายการ: Advisable เก็บถาวรเมื่อ 2008-07-04 ที่ Wayback Machine , Ajaxpect เก็บถาวรเมื่อ 2016-07-09 ที่ Wayback Machine , jQuery AOP Plugin เก็บถาวรเมื่อ 2008-01-13 ที่ Wayback Machine , Aspectes เก็บถาวรเมื่อ 2006-05-08 ที่ Wikiwix, AspectJS เก็บ ถาวรเมื่อ 2008-12-16 ที่ Wayback Machine , Cerny.js เก็บถาวรเมื่อ 2007-06-27 ที่ Wayback Machine , Dojo Toolkit เก็บถาวรเมื่อ 2006-02-21 ที่ Wayback Machine , Humax Web Framework เก็บถาวรเมื่อ 2008-12-09 ที่ Wayback Machine , Joose เก็บถาวรเมื่อ 2015-03-18 ที่ Wayback Machine , Prototype – Prototype Function#wrap เก็บถาวรเมื่อ 2009-05-05 ที่Wayback Machine YUI 3 (Y.Do) ถูกเก็บถาวรเมื่อวันที่ 25 มกราคม 2011 ที่ Wayback Machine
  32. ^ใช้การสนับสนุนในตัวสำหรับหมวดหมู่ (ซึ่งช่วยให้สามารถห่อหุ้มโค้ดด้านแง่มุมได้) และการเขียนโปรแกรมแบบขับเคลื่อนด้วยเหตุการณ์ (ซึ่งช่วยให้สามารถกำหนด ตัวจัดการ เหตุการณ์ก่อนและหลังได้)
  33. ^ "AspectLua" . เก็บถาวรจากต้นฉบับเมื่อวันที่ 17 กรกฎาคม 2015 . เรียกดูเมื่อวันที่ 11 สิงหาคม 2015 .
  34. ^ "MAKAO, re(verse)-engineering build systems" . สืบค้นเมื่อ11 สิงหาคม 2558 .{{cite web}}: CS1 maint: บริการเก็บถาวรที่เลิกใช้แล้ว ( ลิงก์ )
  35. ^ "McLab" . เก็บถาวรจากต้นฉบับเมื่อวันที่ 24 กันยายน 2015 . เรียกดูเมื่อวันที่ 11 สิงหาคม 2015 .
  36. ^ "AspectML – งานวิจัยเกี่ยวกับภาษาการเขียนโปรแกรมเชิงฟังก์ชันแบบเน้นแง่มุม"เก็บถาวรจากต้นฉบับเมื่อวันที่ 5 ธันวาคม 2010 เรียกดูเมื่อวันที่ 11 สิงหาคม 2015
  37. ↑ "nemerle/README.md ที่ master · rsdn/nemerle " GitHub . สืบค้นเมื่อ22 มีนาคม 2561 .
  38. ^ Adam Kennedy. "Aspect – Aspect-Oriented Programming (AOP) for Perl – metacpan.org" . เก็บถาวรจากต้นฉบับเมื่อวันที่ 31 สิงหาคม 2013 . เรียกดูเมื่อวันที่ 11 สิงหาคม 2015 .
  39. ^หลายรายการ: PHP-AOP (AOP.io) เก็บถาวรเมื่อ 2014-08-18 ที่ Wikiwix, Go! AOP framework เก็บถาวรเมื่อ 2013-03-01 ที่ Wayback Machine , PHPaspect เก็บถาวร เมื่อ 2016-08-22 ที่ Wayback Machine , Seasar.PHP เก็บถาวรเมื่อ 2005-12-26 ที่ Wayback Machine , PHP-AOP , Flow เก็บถาวรเมื่อ 2018-01-04 ที่ Wayback Machine , AOP PECL Extension เก็บถาวรเมื่อ 2017-04-11 ที่ Wayback Machine
  40. ^ "การเขียน โปรแกรมเชิงแง่มุมใน Prolog" bigzaphod.org 14 ธันวาคม 2005 เก็บถาวรจากต้นฉบับเมื่อ 3 มีนาคม 2012 เรียกดูเมื่อ5 พฤษภาคม 2018
  41. ^หลายรายการ: PEAK เก็บถาวรเมื่อ 2005-04-09 ที่ Wayback Machine , Aspyct AOP , Lightweight Python AOP เก็บถาวรเมื่อ 2004-10-09 ที่ Wayback Machine ,โมดูล aspect ของ Logilab เก็บถาวรเมื่อ 2005-03-09 ที่ Wayback Machine , Pythius เก็บถาวรเมื่อ 2005-04-08 ที่ Wayback Machine ,โมดูล AOP ของ Spring Python เก็บถาวรเมื่อ 2016-03-04 ที่ Wayback Machine ,โมดูล AOP ของ Pytilities เก็บถาวรเมื่อ 2011-08-25 ที่ Wayback Machine , aspectlib เก็บถาวรเมื่อ 2014-11-05 ที่ Wayback Machine
  42. ^ "คลังแพ็กเกจ PLAneT : PLAneT > dutchyn > aspectscheme.plt"เก็บถาวรจากต้นฉบับเมื่อวันที่ 5 กันยายน 2015 เรียกดูเมื่อวันที่ 11 สิงหาคม 2015
  43. ^ "AspectR – การเขียนโปรแกรมเชิงแง่มุมอย่างง่ายใน Ruby"เก็บถาวรจากต้นฉบับเมื่อวันที่ 12 สิงหาคม 2558 เรียกดูเมื่อวันที่ 11 สิงหาคม 2558
  44. ^ดีน แวมป์เลอร์. "บ้าน" . เก็บถาวรจากต้นฉบับเมื่อวันที่ 26 ตุลาคม 2550 . เรียกดูเมื่อวันที่ 11 สิงหาคม 2558 .
  45. ^ "gcao/aspector" . GitHub . เก็บถาวรจากต้นฉบับเมื่อวันที่ 4 มกราคม 2015 . เรียกดูเมื่อวันที่ 11 สิงหาคม 2015 .
  46. ^ "AspectS" . tu-ilmenau.de . เก็บถาวรจากต้นฉบับเมื่อวันที่ 6 มกราคม 2549 . เรียกดูเมื่อวันที่ 5 พฤษภาคม 2561 .
  47. ^ "MetaclassTalk: การสะท้อนและการเขียนโปรแกรมเชิงเมตาใน Smalltalk" . เก็บถาวรจากต้นฉบับเมื่อวันที่ 29 กรกฎาคม 2015 . เรียกดูเมื่อวันที่ 11 สิงหาคม 2015 .
  48. ^ "WEAVR" . iit.edu . เก็บถาวรจากต้นฉบับเมื่อวันที่ 12 ธันวาคม 2008 . เรียกดูเมื่อวันที่ 5 พฤษภาคม 2018 .
  49. ^ "aspectxml – เครื่องมือ ประมวลผล XML แบบเชิงแง่มุม (AXLE) – Google Project Hosting"เก็บถาวรจากต้นฉบับเมื่อวันที่ 12 กันยายน 2015 เรียกดูเมื่อวันที่ 11 สิงหาคม 2015

อ่านเพิ่มเติม

  • Kiczales, G. ; Lamping, J.; Mendhekar, A.; Maeda, C.; Lopes, C.; Loingtier, JM; Irwin, J. (1997). การเขียนโปรแกรมเชิงแง่มุม (PDF) . ECOOP'97. รายงานการประชุม European Conference on Object-Oriented Programming ครั้งที่ 11 . Lecture Notes in Computer Science (LNCS). เล่มที่ 1241. หน้า  220–242 . CiteSeerX  10.1.1.115.8660 . doi : 10.1007/BFb0053381 . ISBN 3-540-63089-9.เอกสารฉบับนี้โดยทั่วไปถือเป็นเอกสารอ้างอิงที่เชื่อถือได้สำหรับ AOP
  • Robert E. Filman; Tzilla Elrad; Siobhán Clarke ; Mehmet Aksit (2004). การพัฒนาซอฟต์แวร์เชิงแง่มุม (Aspect-Oriented Software Development) . Addison-Wesley. ISBN 978-0-321-21976-3.
  • Renaud Pawlak, Lionel Seinturier และ Jean-Philippe Retaillé (2005). พื้นฐานของ AOP สำหรับการพัฒนา J2EE . Apress. ISBN 978-1-59059-507-7.
  • Laddad, Ramnivas (2003). AspectJ in Action: Practical Aspect-Oriented Programming . Manning. ISBN 978-1-930110-93-9.
  • Jacobson, Ivar ; Pan-Wei Ng (2005). การพัฒนาซอฟต์แวร์เชิงแง่มุมด้วยกรณีการใช้งาน Addison-Wesley. ISBN 978-0-321-26888-4.
  • การพัฒนาซอฟต์แวร์เชิงแง่มุมและ PHP, ดมิทรี เชโก, 2006
  • Siobhán Clarke & Elisa Baniassad (2005). การวิเคราะห์และการออกแบบเชิงแง่มุม: แนวทางการใช้ธีม . Addison-Wesley. ISBN 978-0-321-24674-5.
  • Raghu Yedduladoddi (2009). การพัฒนาซอฟต์แวร์เชิงแง่มุม: แนวทางในการสร้างแบบจำลองการออกแบบ UML VDM. ISBN 978-3-639-12084-4.
  • "การเขียนโปรแกรมเชิงวัตถุแบบปรับตัวได้โดยใช้การปรับแต่งตามกราฟ" – Lieberherr, Silva-Lepe และคณะ – 1994
  • Zambrano Polo y La Borda, Arturo Federico (5 มิถุนายน 2013). "การจัดการปฏิสัมพันธ์ของแง่มุมต่างๆ ในบริบทอุตสาหกรรม: ประสบการณ์ ปัญหา และแนวทางแก้ไข" : 159. doi : 10.35537/10915/35861 . สืบค้นเมื่อ30 พฤษภาคม 2014 .{{cite journal}}: การอ้างอิงวารสารต้องใช้|journal=( ความช่วยเหลือ )
  • วิเจสุริยา, วิราช ไบรอัน (30 สิงหาคม 2559) การพัฒนาเชิงแง่มุม (Aspect Oriented Development), เอกสารประกอบการบรรยาย, คณะวิทยาการคอมพิวเตอร์ มหาวิทยาลัยโคลัมโบ ประเทศศรีลังกา
  • Groves, Matthew D. (2013). AOP ใน .NET . Manning. ISBN 9781617291142.
  • รายชื่อเครื่องมือ AOPใน .NET Framework โดยEric Bodden
  • การพัฒนาซอฟต์แวร์เชิงแง่มุม (Aspect-Oriented Software Development ) การประชุมประจำปีเกี่ยวกับ AOP
  • คู่มือการเขียนโปรแกรม AspectJ
  • AspectBench Compiler สำหรับ AspectJซึ่งเป็นการใช้งาน AspectJ ในภาษา Java อีกรูปแบบหนึ่ง
  • บทความชุดจาก IBM developerWorks เกี่ยวกับ AOP
  • ลัดดา, รามนิวาส (18 มกราคม พ.ศ. 2545). "ฉันต้องการ AOP! ตอนที่ 1 " ชวาเวิลด์ สืบค้นเมื่อ20 กรกฎาคม 2020 .บทความชุดละเอียดเกี่ยวกับพื้นฐานของการเขียนโปรแกรมเชิงแง่มุม (Aspect-Oriented Programming) และ AspectJ
  • การเขียน โปรแกรมเชิงแง่มุม (Aspect-Oriented Programming) คืออะไร?บทนำโดย RemObjects Taco
  • ตัวสร้างลักษณะข้อจำกัด-ข้อกำหนด
  • การเขียนโปรแกรมเชิงแง่มุมเทียบกับการเขียนโปรแกรมเชิงวัตถุ: ควรใช้เทคนิคใด เมื่อใด? (เก็บถาวรเมื่อวันที่ 15 เมษายน 2021 ที่Wayback Machine)
  • Gregor Kiczales ศาสตราจารย์ด้านวิทยาการคอมพิวเตอร์ อธิบาย AOP (Artificial Programming)ในวิดีโอความยาว 57 นาที
  • การเขียนโปรแกรมเชิงแง่มุมในภาษา COBOL เก็บถาวรเมื่อวันที่ 17 ธันวาคม 2008 ที่Wayback Machine
  • การเขียนโปรแกรมเชิงแง่มุมในภาษา Java ด้วย Spring Framework
  • วิกิที่รวบรวมข้อมูลเกี่ยวกับวิธีการ AOP บน .NET
  • แง่มุมเบื้องต้นสำหรับการสร้างแบบจำลองกระบวนการทางธุรกิจ (ภาษาเชิงแง่มุมสำหรับ BPMN)
  • บทนำเกี่ยวกับ Spring AOP และ AspectJ
  • หลักสูตรระดับบัณฑิตศึกษา AOSD ที่มหาวิทยาลัย Bilkent
  • บทนำสู่ AOP – พอดแคสต์วิทยุวิศวกรรมซอฟต์แวร์ ตอนที่ 106
  • การใช้งาน Objective-C ของ AOP โดย Szilveszter Molnar
  • การเขียนโปรแกรมเชิงแง่มุมสำหรับ iOS และ OS X โดย Manuel Gebele
  • เฟรมเวิร์ก MVVM ของ DevExpress: บทนำเกี่ยวกับ POCO ViewModels
ดึงข้อมูลมาจาก " https://en.wikipedia.org/w/index.php?title=Aspect-oriented_programming&oldid=1354988385 "

สรุปเนื้อหา

ข้อมูลสำคัญจากบทความ

ข้อมูลสำคัญเกี่ยวกับ การเขียนโปรแกรมเชิงแง่มุม

ในด้านวิทยาการคอมพิวเตอร์การเขียนโปรแกรมเชิงแง่มุม (Aspect-Oriented ProgrammingหรือAOP )...

ประวัติศาสตร์

AOP มีต้นกำเนิดโดยตรงหลายประการ: [ 1 ] การสะท้อน และโปรโตคอล เมตาออบ เจ็กต์ การเขียนโปรแกรมเชิงหัวข้อ ตัวกรององค์ประกอบ และการเขียนโปรแกรมแบบปรับตัว [ 2 ]

แรงจูงใจและแนวคิดพื้นฐาน

โดยทั่วไปแล้ว โค้ดส่วนต่างๆ มักจะ กระจัดกระจาย หรือ พันกัน ทำให้เข้าใจและบำรุงรักษาได้ยาก การกระจัดกระจายเกิดจากฟังก์ชัน (เช่น การบันทึกข้อมูล) กระจายอยู่ทั่วฟังก์ชันที่ไม่เกี่ยวข้องกันหลายๆ ฟังก์ชัน ซึ่งอาจใช้ ฟังก์ชัน นั้น...

แบบจำลองจุดเชื่อมต่อ

ส่วนประกอบที่เกี่ยวข้องกับคำแนะนำในภาษาเชิงแง่มุมจะกำหนดแบบจำลองจุดเชื่อมต่อ (Join Point Model: JPM) JPM กำหนดสิ่งต่อไปนี้สามประการ: