Aspect Oriented Programming הוא buzzword חדש (יחסית). לפוסט הזה שתי מטרות עיקריות:

1. אני אציין מה שאני יודע בנושא (אקבל תיקונים בכיף...)

2. אשמח לקבל פידבקים ולקחים מאנשים שהתנסו בעניין...

אז:

1- AOP - (aspect oriented programming הוא קונספט חדש בתכנות שבא עם מבנים בשפה (keywords) , כלים (קומפיילר, דיבגר), ולא מעט hype. הוא לא מחליף את הOOP (object oriented programming) אלא מרחיב אותו. יש כיום כלי AOP לJava ודוט נט (ואולי לעוד). למעשה ע"מ לעבוד עם AOP כותבים קוד בשפה הרגילה שעובדים בה , מוסיפים שימוש במבנים בשמורים של AOP, מקמפלים בקומפיילר AOP ונוצר קוד (נניח Java byte code או קוד MSIL) שמורץ ע"י סביבת ההרצה הרגילה.

הרעיון הבסיסי הוא: ביחד עם המחלקות הרגילות, מגדירים פיסות קוד שמוזרקות במקומות שונים בתוכנית המזוהים באמצעים שונים (למשל ביטויים רגולריים). כך למעשה אוכפים code pratices ויש גמישות רבה שיכולה לשמש לassertions, logging, security checks, exception handling וכדומה.

עוד פרטים - http://en.wikipedia.org/wiki/Aspect-oriented_programming

אני אישית אוהב את הקונספט הדקלרטיבי (מזכיר לי קצת את הכיף שהיה לי עם פרולוג), אבל לדעתי המימוש שלו ב-java עדיין לא מספיק טוב (עושה למשל בעיות ב-hot code replacement).

הקונספט עצמו מעניין. זו פעם ראשונה שנתקלתי בו.

ממה שהספקתי לקרוא שם, הדבר שהכי הציק לי היה הרעיון שניתן להגדיר שינויים על פונקציות בהתבסס על שמן. נכון שבעולם אידיאלי, כולם עוקבים אחרי הקונבנציות, ועובדים כמו שצריך, וכו' וכו'. בעולם המציאות, תמיד יהיו מהנדסים שלא עוקבים אחרי הקונבנציות במדויק, או שמות ש"במקרה" נופלים לקטגוריה שלא תוכננה להם, קוד שהגיע מבחוץ וכן הלאה.  

בעצם, מה שהגישה הזו עושה הוא סוג של "מאקרו-על". וזה אומר שקריאות הקוד עלולה להשתבש מאוד. עם זאת, אני מניח שתחת הקפדה נכונה זה יכול להיות מעניין.

דווקא החוזק (התיאורטי) של זה הוא שאפשר לאכוף coding guidelines.

למשל: נניח שקובעים בע"פ שמאזור מסוים של הקוד לא ניגשים לאיזור אחר, אבל אי אפשר לאכוף את זה במנגנונים הקיימים של הרשאות וכו'. אז ניתן להגדיר הזרקת קוד שתגרום לזריקת exception או אפילו כשלון קומפילציה אם זה נעשה. אפשר גם לאכוף conventions על שמות של classes וmethods בשיטה זו. כמובן שיש צורך לדעת מהו המבנה הבסיסי של הקוד (כמו איפה יושבים הקבצים ומהו תחום האחריות של כל קטע קוד), אבל זה נראה לי מומלץ בכל מקרה, מסיבות שלא קשורות כלל לAOP ( לשם סדר טוב, מבנה ברור שמפתח חדש יכול לצלול לתוכו ומתכנת ותיק יכול לדבג גם קטע קוד שהוא לא כתב , וכו').

.

ליאור,

כלים לאכיפת קונבנציות קיימים כבר שנים רבות (זוכר אחד מ-2000 בערך). לכתוב קוד שבודק קונבנציות כך שיזרוק Exceptions בזמן ריצה, נראה לי דרך פחות נכונה מאשר לעבור על הקוד עם כלי ניתוח אחת לזמן מה (לפני delivery או לפני build, למשל).

לגבי אכיפת חוקי הרשאות שהשפה ה"טבעית" אינה מאפשרת - זה דווקא נשמע יישום מעניין. אכן, זוהי בעייה שנתקלים בה לעתים, כאשר רוצים שדיזיין מסויים לא ייפגע בתהליך האבולוציה של הקוד בידי מתכנת שאינו מכיר את הקונספט הכללי. יכול להיות שזה באמת נותן מענה.

יש לך (או למישהו שאתה מכיר) נסיון בדבר הזה?

miqe -

עוד לא הכרתי מקום שעובד עם AOP. אני אישית מכיר את הנושא מקורס באוניבריסיטה וקריאה כללית.