มาถึงช่วงท้ายเกม แต่ฉันให้สิ่งนี้กับนักพัฒนาในภายหลังที่อาจสะดุดกับคำถามนี้
ฉันขอแนะนำอย่างยิ่งให้ต่อต้าน AOP หากใบสมัครของคุณขึ้นอยู่กับการทำงานอย่างถูกต้อง ด้านการทำงานเช่นนี้:
- คำแนะนำ (พฤติกรรมเพิ่มเติม) ถูกนำไปใช้
- เข้าร่วมคะแนน (สถานที่ที่สามารถแนบรหัสพิเศษเช่นวิธีการเริ่มต้นหรือสิ้นสุดหรือเมื่อมีการเรียกเหตุการณ์)
- ... โดยที่pointcut (รูปแบบที่ตรวจจับว่ารูปแบบจุดเชื่อมต่อที่กำหนด) ตรงกันหรือไม่
สำหรับใครก็ตามที่ใช้คอมพิวเตอร์เป็นเวลานานความจริงที่ว่ารูปแบบการใช้อาจเป็นสิ่งที่ต้องพิจารณาอย่างใกล้ชิด ดังนั้นนี่คือตัวอย่างของ Pointcut ที่ตรงกับวิธีการตั้งชื่อsetโดยไม่คำนึงถึงข้อโต้แย้ง:
call(* set(..))
นั่นเป็นจุดตัดที่ค่อนข้างเป็นธรรมและควรชัดเจนว่าควรจัดการกับเรื่องนี้ด้วยความระมัดระวัง (ไม่ต้องใช้ปุน) เพราะคุณกำลังใช้คำแนะนำกับสิ่งต่าง ๆ
หรือขอให้คำแนะนำกับทุกสิ่งโดยไม่คำนึงถึงชื่อหรือลายเซ็น!
execution(* *(..))
เห็นได้ชัดว่าเราควรระวังเพราะมีพลังมากมายที่นี่ แต่นี่ไม่ใช่การโต้แย้งในแง่มุม - มันเป็นข้อโต้แย้งที่ควรระวังเพราะมีพลังมากมายที่นี่และการจับคู่รูปแบบสามารถไปได้อย่างง่ายดาย (แค่กดเครื่องมือค้นหาที่คุณชื่นชอบ ข้อผิดพลาด aop และสนุก)
ดังนั้นนี่คือสิ่งที่ดูเหมือนว่าจุดตัดที่ค่อนข้างปลอดภัย:
pointcut setter(): target(Point) &&
( call(void setX(int)) ||
call(void setY(int)) );
ซึ่งจะให้คำแนะนำอย่างชัดเจนหากพบวิธีการตั้งชื่อsetXหรือsetYบนPointวัตถุ วิธีการนั้นสามารถรับได้intและจะต้องเป็นvoidเท่านั้น ดูปลอดภัยทีเดียวใช่มั้ย ดีว่าปลอดภัยหากวิธีการเหล่านั้นมีอยู่และคุณได้ใช้คำแนะนำที่ถูกต้อง ถ้าไม่เลวเกินไป มันล้มเหลวอย่างเงียบ ๆ
เพื่อให้เป็นตัวอย่างเพื่อนกำลังพยายามแก้ไขข้อบกพร่องของแอปพลิเคชัน Java ที่ทุกคนอยู่ในช่วงเวลาที่ดีมันจะส่งคืนข้อมูลที่ไม่ถูกต้อง มันเป็นความล้มเหลวไม่บ่อยนักและไม่ปรากฏว่ามีความสัมพันธ์กับเหตุการณ์หรือข้อมูลใดโดยเฉพาะ มันเป็นจุดบกพร่องของเกลียวสิ่งที่ยากต่อการทดสอบหรือตรวจจับ เมื่อปรากฎว่าพวกเขากำลังใช้วิธีต่าง ๆ เพื่อล็อควิธีการและทำให้พวกเขา "ปลอดภัยเธรด" แต่โปรแกรมเมอร์เปลี่ยนชื่อวิธีการและ pointcut ไม่ตรงกับมันจึงก่อให้เกิดความแตกแยกเงียบของแอพลิเคชัน
ดังนั้นฉันจึงบอกคนอื่นว่าถ้าพวกเขาต้องใช้ AOP เพื่อรักษาลักษณะเช่นข้อยกเว้น: ในระบบที่ออกแบบมาอย่างดีและหากไม่มีอะไรผิดพลาดพวกเขาสามารถลบออกได้และซอฟต์แวร์ยังคงทำงานได้อย่างถูกต้อง อย่างไรก็ตามหากฟังก์ชันการทำงานของโปรแกรมขึ้นอยู่กับ AOP คุณจะสามารถแนะนำโปรแกรมที่ไม่มีการรับประกันได้
ดังนั้นการบันทึกการดีบักและการติดตามจึงเป็นตัวอย่างที่ดีของพฤติกรรมที่สมบูรณ์แบบสำหรับแง่มุม แต่ความปลอดภัย? Nope ปลอดภัยไหม? Nope
สำหรับทางเลือกที่มีประสิทธิภาพเพื่อ AOP ดูลักษณะ แทนที่จะรวมเข้ากับภาษาพวกเขาจะถูกรวมเข้ากับมันโดยตรงไม่จำเป็นต้องมี IDE "ลักษณะนิสัย" (แม้ว่าจะสามารถช่วยได้) และมีความล้มเหลวในการรวบรวมเวลาหากวิธีการที่คุณต้องการไม่มีอยู่ ลักษณะการทำงานมีความสะอาดกว่ามากในการจัดการกับการแยกความกังวลเนื่องจากปัญหานั้นถูกกำหนดไว้ตั้งแต่ต้น ฉันใช้มันอย่างกว้างขวางและพวกเขาก็ยอดเยี่ยม