ارتباط با ما تماس با ما پيگيري قطعه ورود به سـين Introduction سرير سرويس صفحه اصلي
 
   
 
 
مقالات
جستجو برای:  

آشنايي با برنامه‌نويسي جنبه‌گرا (Aspect-Oriented) (بخش اول)


امتیازدهی به این مقاله:


1388/07/13
خلاصه مقاله
شايد قبلاً نام AOP (سرنام Aspect Oriented Programming) را شنيده باشيد. بسياري از ما اولين بار كه اين نام را شنيديم با تصور اين كه AOP نيز يكي از آن پارادايم‌هايي است كه هر چند سال يكبار براي جايگزيني برنامه‌نويسي شيء‌گرا مطرح مي‌شوند، بي‌تفاوت آن را كنار گذاشتيم. اما داستان AOP، طولاني‌تر از اين حرف‌ها است. زمان آن رسيده كه كمي خاك شيوه برنامه‌نويسي خود را بگيريد. مكاشفات جذابي وجود دارد... .
متن کامل مقاله



بسياري از افراد معتقدند، علوم كامپيوتر آن قدرها هم كه به‌نظر مي آيد، سريع پيشرفت نمي‌كند. آن‌ها معتقدند، در بسياري از شاخه‌ها كار تقريباً تمام شده‌است و كارهاي جديد فقط در حد پيشرفت‌هاي جزئي انجام مي‌گيرد. در حقيقت، بعضي از موضوع‌هاي مطرح شده توسط اين گروه بدبين، تا حدودي به واقعيت نزديك است.
بسياري از پايه‌هاي علوم كامپيوتر شكل گرفته است و به نظر ميآيد تغيير آن‌ها، دست‌كم به اين زودي‌ها امكان‌پذير نيست. در بعضي از شاخه‌ها يك فناوري آن‌چنان جاي پايش را محكم كرده‌است كه حتي تصور وجود روشي ديگر كمي سخت به نظر مي‌رسد.
اما كامپيوتري‌ها مردم جالبي هستند. شايد آن‌ها خيلي پركار نباشند، اما هميشه ايده‌هاي جديد و خلاقانه راهي براي نفوذ به درون دنيايشان پيدا مي‌كنند. شايد در بسياري از زمينه‌ها، كار شما به مطالعه كارهاي كلاسيك انجام شده محدود شود، اما هميشه جاده‌هاي جديدي وجود دارد.
گريگور كيزالس (Gregor Kiczales)، بيشتر وقت خود را در آزمايشگاه پارك (PARC) كه مبدأ شروع بسياري از خلاقيت‌هاي بزرگ حوزه علوم كامپيوتر بوده، گذرانده است. محيط صنعتي - آكادميك آزمايشگاه علاوه بر دل‌مشغولي‌هاي آكادميك، كيزالس را به مسائل و مشكلات حوزه نرم‌افزار در دنياي واقعي آشنا ساخته است.
در حقيقت، يكي از همين مشكلات (Cross-cutting Concern) بود كه منجر به ارائه مدل AOP توسط اين پروفسور دانشگاه UBC و همكارانش در زيراكس پارك شد. مدلي كه به تحركات زيادي در حوزه  نرم‌افزار منجر شد تا جايي كه Daniel Sabbah، معاون بخش استراتژي‌هاي نرم‌افزاري شركت آي‌بي‌ام درباره آن مي‌گويد: «زمان توسعه نرم‌افزارها به وسيله مفهوم Aspect-Oriented فرا رسيده‌است. صنعت نرم‌افزار به آن نياز دارد و آي‌بي‌ام در حال حاضر از آن استفاده مي‌كند.»
اولين ارائه  رسمي از اين موضوع به سال 1997 برمي‌گردد. البته، اطلاعات تاريخي درباره AOP بسيار اندك است و ما از روند كار چيز زيادي نمي‌دانيم. كيزالس خود در پاسخ به پرسش نگارنده پيرامون تاريخچه و روند شكل‌گيري AOP مي‌گويد: «متأسفانه هيچ تاريخ مدوني براي AOP وجود ندارد.»
در اين مقاله سعي كرده‌ايم معرفي مناسبي از اين پارادايم جديد برنامه‌نويسي ارائه دهيم.

چرا از پارادايم استفاده مي‌كنيم؟

توماس كوهن، پارادايم را اين‌گونه تعريف مي‌كند: «پارادايم در نتيجه فعاليت‌هاي اجتماعي ظاهر مي‌شود كه در آن مردم ايده‌هايشان را توسعه مي‌دهند و قواعد و مثا‌ل‌هايي مي‌سازند كه اين ايده‌ها را بيان كند.1» اين شايد يكي از رسمي‌ترين تعريف‌هايي باشد كه در سراسر عمرتان براي پارادايم مي‌شنويد. اما اين جمله زيبا براي يك برنامه‌نويس چه معنايي دارد؟
كامپيوترهاي اوليه توسط كدهاي باينري برنامه‌ريزي مي‌شدند و برنامه‌نويس، با ارسال دنباله‌اي از صفر و يك ها به پردازنده مركزي به‌طور مستقيم براي آن كامپيوتر برنامه‌نويسي مي‌كرد. با گذشت زمان، زبان‌هايي با سطوح بالاتر عرضه شدند.
اسمبلي، C و جاوا نمونه‌اي از زبان‌هاي نسل‌هاي مختلف هستند. با معرفي هر نسل، نحوه نوشتن برنامه و نگرش به مفاهيم نيز در آن تغيير مي‌يافت. ارائه شيوه‌هاي جديد توليد نرم‌افزار به اميد ايجاد راه‌هاي بهتر براي طراحي و پياده‌سازي يك برنامه، هنوز نيز ادامه دارد.
روش پايه‌اي برنامه‌نويسي را كه در بالا بيان شد، پارادايم برنامه‌نويسي مي‌نامند. در حقيقت، پارادايم‌ها چهارچوب كلي معماري يك برنامه و نحوه ارتباط اجزاي آن با يكديگر را مشخص مي‌كنند. با ذكر مثال‌هايي از پارادايم‌هاي مختلف، مفهوم را روشن‌تر مي‌كنيم.
شايد برنامه‌نويسي رويه‌اي (Procedural Programming) اولين پارادايم مطرح‌شده براي زبان‌هاي برنامه‌نويسي است. در اين پارادايم، اعمال، مرحله به مرحله توسط فراخواني رويه‌هايي كه براي انجام كارهاي مختلف نوشته مي‌شوند، انجام مي‌گيرند. اين مدل با مشخص كردن ترتيبي براي فراخواني رويه‌ها يكي‌يكي آن‌ها را اجرا مي‌كند و با اتمام كار هر كدام رويه بعدي اجرا مي‌شود.
در حقيقت، برنامه‌نويسي رويه‌اي، ادامه  ايده كلي‌تري  به‌نام برنامه‌نويسي امري (Imperative Programming)  است. به‌طور ساده استراتژي اين مدل برنامه‌نويسي به اين صورت است كه تعدادي دستور وجود دارند كه بايد توسط كامپيوتر اجرا شوند. زبان‌هاي امري دقيقاً مانند اسمشان عمل مي‌كنند: اول اين كار را انجام بده، بعد آن را و... .
برنامه‌نويسي شيءگرا نيز در بيشتر مواقع مثالي از مدل امري است، زيرا در آن‌جا نيز روش كار برنامه عموماً به صورت اجراي سلسله‌اي از دستورها است. اگرچه معمولاً برنامه‌نويسي شيءگرا به صورت يك مدل جداگانه مورد بررسي قرار مي‌گيرد.
در مقابل مدل برنامه‌نويسي امري، مدل اعلاني (Declarative) قرار دارد. در اين مدل تمركز روي ماهيت چيزها است نه نحوه كاركرد آن‌ها. در مدل اعلاني آن‌چه اهميت دارد، توصيف اين است كه يك جزء برنامه چگونه است، نه اين‌كه چگونه ساخته مي‌شود. اگر برنامه خود را به دو قسمت منطق و كنترل تقسيم كنيد، در مدل اعلاني شما منطق برنامه خود را در اختيار مي‌گيريد و نگران آن‌چه در بخش كنترل اتفاق مي‌افتد، نيستيد. مثال بارز اين‌گونه زبان‌ها، HTML است2.
با توجه به نزديك بودن ساختار مدل اعلاني به ساختار رياضيات، اثبات درستي يك برنامه در اين مدل راحت‌تر انجام مي‌گيرد. به همين دليل، مدل اعلاني در نوشتن برنامه‌هايي كه بايد درستي آن‌ها به صورت يك حكم رياضي ثابت شود، كاربرد فراواني دارد.
عموماً زبان‌هاي مدل امري در محيط‌هاي كاري از محبوبيت بيشتري برخوردارند، اما نمي‌توان از تأثير مدل اعلاني در ساخت برنامه‌هاي علمي (به خصوص رياضي) به سادگي گذشت.
اين معرفي بسيار كوتاه از پارادايم‌ها فقط براي اين بود كه بدانيم آن‌ها واقعاً يكي نيستند! هر پارادايم، يك سبك برنامه‌نويسي و از آن مهم‌تر يك سبك نگرش را به دنبال دارد كه مي‌تواند تعاريف و اصول يك برنامه‌نويس را دگرگون سازد. پارادايم‌ها قطعاً به وجود نيامده‌اند كه معجزه كنند، بلكه قرار است كار را براي برنامه‌نويسان راحت‌تر سازند.
Aspect-Oriented Programming نيز، كه در واقع در ادامه مدل OOP عرضه شد، يك پارادايم برنامه‌نويسي است كه در ادامه به معرفي آن مي‌پردازيم.

وقتي OOP جواب‌گو نيست‌...

سناريوي زير را در نظر بگيريد:
فرض كنيد شما مسئول طراحي وب‌سايت براي يك شركت فروش آنلاين لباس شده‌ايد. اين سايت، مانند بيشتر سايت‌هاي دنيا دو بخش دارد: بخش نخست براي مشتريان كه مي‌توانند در آن اجناس را مشاهده كنند و آن‌ها را بخرند. بخش دوم نيز براي انجام كارهاي اداري خود شركت است كه فقط كارمندان خاصي به آن دسترسي دارند.
به‌عنوان مثال، اضافه كردن اقلامي به فروشگاه آنلاين يا بررسي كردن حساب بعضي از مشتري‌ها. شما و گروه برنامه‌نويسي با تلاشي قابل ستايش سايتي بسيار جامع و زيبا طراحي مي‌كنيد و آن را به شركت ارائه مي‌دهيد. اما روزي كه براي دريافت حق‌الزحمه خود مي‌رويد، متوجه مي‌شويد كه همه از دست شما عصباني هستند.
كارمندان نمي‌توانند البسه جديد را وارد فهرست فروشگاه كنند، كاربران سايت در حال افزايش اعتبار حساب كاربري خود به صورت دستي هستند! ايميل كاربران با فرمت اشتباه ذخيره شده است، پيگيري فروش روز‌هاي قبل در مواردي دچار مشكل مي‌شود و... . مشكل چيست؟
با افزايش پيچيدگي در يك برنامه نحوه كنترل شما روي روند رشد آن نيز دشوارتر مي‌شود. با اين كه ممكن است در بسياري از قسمت‌هاي برنامه كارهايي شبيه به هم انجام دهيد، اما جا انداختن يكي از اين كارها در هر يك از قسمت‌ها مي‌تواند كارايي كل برنامه شما را زير سؤال ببرد.
به مثال امنيت سايت فروش لباس باز مي‌گرديم. شما متوجه مي‌شويد با توجه به پيچيده شدن معماري سايت، بسياري از كارهاي ضروري را از قلم انداخته‌ايد.
در بسياري از جاها فراموش شده كه قبل از فراخواني روش‌هاي امن (Secure) هويت كاربر مشخص شود تا فرد غيرمسئول نتواند به اطلاعات محرمانه دسترسي داشته باشد. در بسياري از قسمت‌ها ورودي‌هاي اشتباهي كه كاربران به صورت دستي به سيستم مي‌دهند، تأييد اعتبار (Validate) نمي‌شوند و اين باعث بروز سردرگمي در سيستم مي‌شود.
در ضمن در بعضي از روش‌ها با توجه به زياد بودن كارهاي حاشيه‌اي (مانند ثبت كردن عمليات يك سيستم (Logging)، تراكنش‌هاي پايگاه‌داده و مديريت خطاها فراخواني روش‌هاي بعضي كارها از قلم افتاده‌است. در نتيجه سايت كاملاً كارايي خود را از دست داده و عملاً به يك سيستم خراب تبديل شده‌است.
از تمام اين موارد بدتر اين‌كه مشكلات شما به اينجا ختم نمي‌شود. وقتي درصدد اصلاح كدها بربياييد، مي‌بينيد اين‌كار خيلي دشوارتر از آن است كه تصور مي‌كرديد، زيرا كد هر قسمت آميخته‌اي از روند كاري اصلي برنامه (Business Logic) و كارهاي حاشيه‌اي مانند بررسي كردن امنيت و Logging و ... است.
جداسازي كد به صورتي كه بتوانيم بخش‌هاي مختلف را مورد بررسي قرار دهيم، كار بسيار مشكلي است و اين‌كار شما و گروه طراحي را دشوارتر از قبل مي‌كند.
مشكل سايت قسمت بالا مشكل تمام سيستم‌هاي شيءگرا است. به كارهاي مذكور كه براي تمام قسمت‌هاي سايت يكسان هستند، Cross-Cutting Concern گفته مي‌شود. در حقيقت، Cross-Cutting Concern ،Concernهايي هستند كه در چندين قسمت سيستم مورد توجه قرار مي‌گيرند (به‌عنوان نمونه، در مثال بالا بررسي امنيت و تراكنش‌هاي پايگاه‌داده و عمليات Logging).
اين Concernها معمولاً نمي‌توانند در يك ماجول به‌طور كامل  كپسوله شوند. همان‌طور كه در مثال مذكور مي‌بينيد، بايد چندين فراخواني هر كدام از آن‌ها را در سيستم‌هاي امنيتي بالا قرار دهيم تا بتوانند آن‌ها را به قسمت برقراري امنيت متصل كنند. Cross-Cutting Concern جايي است كه ديگر مدل شيءگرا جواب كارآمدي به ما نمي‌دهد.

AOP؛ تولد يك مفهوم‌

در 1997 گريگور كيزالس و گروهش در زيراكس پارك مفهومي را معرفي كردند كه Aspect Oriented Programming يا به اختصار AOP ناميده مي‌شود. نام اوليه اين پروژه تجزيه و سرهم كردن (Decomposition & Weaving) بود، اما بعدها به AOP تغيير نام داد.
كيزالس درباره اين موضوع مي‌گويد: «اين نظر يكي از اعضاي گروه بود كه به درستي اشاره كرد تلفظ اين نام بسيار سخت است و در ضمن به نظر كمي زيادي 3Nerdy است.»
AOP، در حقيقت به‌عنوان يك مكمل براي برنامه‌نويسي شيءگرا عرضه شد تا ضعف‌هايي را كه در قسمت قبل به اختصار به آن اشاره كرديم پوشش دهد. كار اصلي AOP كار كردن با Cross-Cutting Concernها است. اما بياييد دقيق‌تر به مفهوم AOP بپردازيم.
شما براي نوشتن يك برنامه علاوه بر منطق كاري برنامه خود (كه جريان اصلي برنامه است)، بايد به‌طور هم‌زمان نگران بسياري از كارهاي حاشيه‌اي ديگر نيز باشيد. سؤال‌هايي از قبيل: «اگر يك قسمت از برنامه مطابق پيش‌بيني كار نكرد، چه كنم؟» يا «چگونه امنيت را به برنامه‌ام تزريق كنم؟» يا حتي «چگونه مديريت حافظه را انجام دهم؟»، سؤالاتي هستند كه هر برنامه‌نويس در طول يك پروژه بارها از خود مي‌پرسد. اما چگونه بايد با اين Concernها كنار آمد؟
شايد به ذهن همه ما اين فكر خطور كرده باشد كه چه خوب بود اگر كارهاي حاشيه‌اي و كد اصلي در دو فرآيند كاملاً جدا توليد مي‌شدند تا علاوه بر افزايش Modularization، بتوانيم نگراني‌هاي خود را تقسيم كنيم. در حقيقت اين ايده، فكر اصلي پشت سر AOP است.
البته انجام كارهاي حاشيه‌اي در پشت صحنه ايده‌اي قديمي‌تر از AOP است. به‌عنوان مثال، مي‌توانيد انجام مديريت حافظه و Garbage Collection توسط JVM در زبان جاوا را در نظر بگيريد. شما مي‌توانيد كد خود را بدون نگراني درباره مسائل مربوط به دو مورد ذكرشده در بالا بنويسيد، زيرا جاوا خود با آن‌ها كنار مي‌آيد.
انجام جداگانه كد و كارها باعث افزايش modularization مي‌شود و همه برنامه‌نويسان مي‌دانند كه اين افزايش مي‌تواند چه‌قدر دنيا را زيبا كند!
جان هانت مي‌گويد: «من هنوز مي‌توانم خودم را جلوي سورس كد يك برنامه تصور كنم در حالي‌كه سعي مي‌كنم منطق كاري پايه‌اي آن را از بقيه چيزهاي دور و برش مجزا سازم.» شايد شما هم در غم  او شريك باشيد. درك سازوكار اصلي كاركرد يك برنامه، موضوع بسيار مهمي است كه معمولاً بسيار سخت انجام مي‌گيرد.
زيرا تمام كد اصلي برنامه با جزئيات حاشيه‌اي (البته نه لزوماً از نوع پيش‌پا افتاده) مخلوط شده‌است كه علاوه بر مشغول ساختن ذهن كدنويس و كند كردن فرآيند عيب‌يابي، باعث مي‌شود تا درك روند كاري اصلي كد نيز براي كسي كه سعي در فهم آن دارد، بسيار مشكل شود.
اما راه حل گروه كيزالس براي اين موضوع چه بود؟ چيزي كه آن‌ها عرضه كردند مي‌توانست Cross-Cutting Concernها را به صورت يك ماجول جداگانه مورد بحث قرار دهد. ماجولي كه علاوه بر عمليات اصلي كه بايد انجام دهد، در برگيرنده شرط اجراي اين Concernها نيز است.
بگذاريد با ذكر يك مثال موضوع را مشخص كنيم. به همان بحث امنيت باز مي‌گرديم. در مدل شيء‌گرا راه‌حل ما ساختن يك كلاس (يا يك روش در يك كلاس) براي بررسي بحث دسترسي كاربر موردنظر بود. پس از ساخت يك ماجول براي بررسي، با اضافه كردن عبارت‌هاي فراخواني آن در قسمت‌هاي مختلف برنامه، كار را تكميل مي‌كنيم.
در حقيقت، روند كاري در مدل شيء‌گرا در دو جا دنبال مي‌شود. يكي كلاس يا روشي كه براي بحث امنيت نوشته‌ايم،‌ يكي هم مكان‌هاي فراخواني آن از كد اصلي برنامه.
اما راه‌حل AOP متفاوت است. در AOP دو مكان قبلي (ماجول امنيت و مكان فراخواني) تقريباً با يكديگر تركيب مي‌شوند. به اين ترتيب كه شما كد مربوط به Concern (در مثال ما چك كردن امنيت) را در يك ماجول جداگانه قرار مي‌دهيد و سپس در همان ماجول شرط‌هاي فراخواني اين كد را ذكر مي‌كنيد (به‌عنوان مثال، درباره بحث موردنظر ما بايد بررسي هويت در مواردي انجام شود كه يك روش امن فراخواني مي‌شود).
به اين ترتيب، تمام روند كاري Cross-cutting Concernها از سازوكار اصلي برنامه مجزا مي‌شوند. كاملاً مشخص است كه اين جدايي مي‌تواند چه مزيت‌هايي را براي سيستم به ارمغان بياورد. به‌عنوان مثال، مي‌توان اين دو بخش كد (كد اصلي و Cross-cutting Concernها) را به دو گروه مختلف برنامه‌نويسي واگذار كرد يا حتي درباره خود Cross-cutting Concernها مي‌توان هر بخش را به خبره  آن كار سپرد. مثلاً بخش بررسي كردن امنيت به متخصصان امنيت يا بخش تراكنش‌هاي پايگاه‌داده به متخصصان آن.
شايد باز هم اصرار كنيد كه تمام اين كارها با مدل شيءگرا نيز قابل دسترس بود (بحث كامل‌تري درباره اين مقايسه در بخش آخر مقاله آمده است). البته درست مي‌گوييد! اما توجه داشته باشيد كه در يك مدل شيء‌گرا برنامه‌نويس بايد از نكات زير آگاهي داشته باشد:
1- برنامه‌نويس بايد از وجود چنين كلاس‌هايي كه براي هماهنگ كردن اين Cross-cutting Concernها ساخته شده است، خبر داشته باشد.
2- بايد Specification دقيق آن كلاس را بداند تا بتواند از آن استفاده كند.
3- بايد بداند دستور مربوط به فراخواني روش‌هاي آن كلاس را كجاي كد اصلي قرار دهد.
در تمام اين سه مرحله امكان رخ دادن خطا وجود دارد. به خصوص در قسمت آخر كه فراموشي برنامه‌نويس براي فراخواني تمام روش‌هاي لازم از شايع ترين اشتباه‌ها است. اما با استفاده از AOP، با توجه به جدا شدن دغدغه‌هاي برنامه‌نويسان اين دو بخش چنين مشكلاتي اصولاً مطرح نمي‌شوند (البته مشكلات ديگري مطرح مي‌شوند كه چند نمونه از آن‌ها در قسمت آخر مقاله مطرح مي‌شود).
با استفاده از AOP مي‌توانيم بدون تغيير كد اصلي، Concernهايي به آن اضافه كنيم كه رفتارهاي سيستم را تقويت كند. در بخش بعد به بررسي مفاهيم اصلي AOP مي‌پردازيم.

اين يك AOP است...

چه چيزي مُهر AOP را روي يك سيستم مي‌زند؟ مسلماً معيار طراحي يك سيستم براساس AOP، اين نيست كه سازنده آن اين‌گونه بگويد.
اين موضوع كه آيا يك پروژه از AOP استفاده مي‌كند يا خير، به مكانيزم كاري آن پروژه و ماهيت نيازهاي آن بستگي دارد. به‌عنوان مثال، كل عمليات مربوط به پرينت كردن يك سند را در نظر بگيريد. شما ممكن است در قسمت‌هاي مختلفي از برنامه خود عمليات پرينت كردن را نياز داشته باشيد. به اين ترتيب، بايد بارها روش‌هاي مربوط به آن را فراخواني كنيد. ممكن است با توجه به اين تعاريف شما پرينت را به صورت يك Concern در نظر بگيريد. اما آيا اين طراحي يك طراحي منطقي است؟
در تعريف Concernهايي كه در AOP مورد توجه قرار مي‌گيرند يك نكته فرعي وجود دارد و آن اين است: اين Concernها معمولاً به صورت يك ماجول جداگانه (در مدل هاي قبل از AOP) دسته‌بندي نمي‌شوند. اين تعريف جواب سؤال بالا را مشخص مي‌كند.
در مثال بالا روش‌هاي مربوط به عمليات پرينت كردن براي برنامه‌نويس كاملاً مشخص است و مطرح كردن اين نكته كه او ممكن است فراموش كند كه آن‌ها را فراخواني كند تا حدودي خنده‌دار به نظر مي‌آيد. پس چندان منطقي نيست كه پرينت كردن را به وسيله AOP پياده‌سازي كنيم.
عدم استفاده از AOP در مثال بالا بديهي بود، اما ايده پشت اين مطلب را مشخص مي‌كند. AOP بايد در مواردي به كار گرفته شود كه به آن نياز است. وقتي مكانيزمي كه وجود AOP را مي‌طلبد، موجود نيست مي‌توانيم خيلي راحت از پارادايم هاي ديگر استفاده كنيم. پس بايد قبل از استفاده از AOP نيازهاي يك سيستم را كاملاً تحليل كنيم تا لزوم يا عدم لزوم به كارگيري آن را مشخص سازيم.
در ادبيات AOP، تعاريفي رسمي‌تر از مفاهيم اوليه آن وجود دارد كه موارد استفاده AOP را روشن‌تر مي‌كند.

Quantification يا تعيين عناصر
Quantification ايده‌اي است كه در آن يك برنامه‌نويس مي‌تواند با نوشتن يك سري عبارت در قالب يك واحد و به صورت مجزا از بقيه سيستم، بسياري از جاهاي غيرمحلي برنامه را تحت‌تأثير قرار دهد. درباره AspectهاQuantification مي‌تواند به اين صورت معني شود كه توانايي Aspectها براي اثرگذاري در نقاط مختلف يك برنامه است.

Obliviousness يا فراموش‌كاري‌
Obliviousness بيانگر اين ايده است كه يك برنامه اطلاعي از اين كه يك Aspect كي و كجا اجرا مي‌شود، ندارد. نتيجه اين‌كه شما نمي‌توانيد با نگاه كردن به كد بگوييد كدام Aspect اجرا مي‌شود و اين باعث ارتقاي مفهوم جدا‌سازي مي‌شود.

تعريف Filman-Friedman
دو مفهوم ذكر شده در بالا (تعيين عناصر و فراموش‌كاري) از ديدگاه تعريف Filman-Friedman دو مفهوم لازم‌الاجرا در زمينه طراحي برنامه‌هاي Aspect Oriented هستند. در حقيقت، با توجه به اين تعريف هر طراحي بايد شامل هر دو ايده به‌طور كامل باشد.
هرچند خيلي‌ها اين دو تعريف را بسيار سخت‌گيرانه مي‌دانند، زيرا برنامه‌هاي بسياري با طراحي AOP وجود دارند كه تنها به خاطر جلوگيري از اختلا‌ط دو كد، يكي از آن‌ها Aspect محسوب مي‌شود كه اين طراحي لزوماً نقاط مختلف برنامه را مورد هدف قرار نمي‌دهد (مثال رعايت نشدن تعيين عناصر). همچنين در بعضي مواقع، برنامه‌نويسان AOP محل فراخواني Aspect را با علا‌متي خاص مشخص مي‌سازند (مثال رعايت نشدن فراموشكاري)

منبع : www.shabakeh-mag.com

ارسال کننده : غزاله پویان
تعداد بازدید از این صفحه: 9415
 
مقالات وابسته

  دانشنامه فایر فاکس
  مفهوم نرم‌افزار آزاد
  طبقه‌بندی نرم‌افزارهای آزاد و غیرآزاد
  معماری و ساختار كلی RUP
  آشنايي با برنامه‌نويسي جنبه‌گرا (Aspect-Oriented) (بخش اول)
  آشنايي با برنامه‌نويسي جنبه‌گرا (Aspect-Oriented) (بخش دوم)
  آشنايي با برنامه‌نويسي جنبه‌گرا (Aspect-Oriented) (بخش سوم)
  نگاهي به مجموعه نرم‌افزار KOffice 2.0
  نگاهی نزدیک تر به Windows Live Essentials 2011
  بررسی Windows phone 7؛ ویندوز موبایل به ایستگاه هفتم رسید!

 
لينک هاي خبرخوان (فيد ها)
News Rss اخبار
News Rss مقالات
News Rss محصولات
نسخه چاپی
 
درخواست عضويت در خبرنامه
با وارد کردن ايميل خود در اين قسمت مي توانيد مشترک خبرنامه ما شده هر روز اخبار ما در ايميل خود مطالعه نماييد.
Delivered by FeedBurner
 
 
ارتباط با ما پيگيري قطعه پيوند ها سرير سرويس

تمام حقوق مادي و معنوي اين سايت متعلق به شرکت سرير سرويس است
Copyright©2005-2012, Sarir Service Company. Power By: Sarir Service Co