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

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


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


1388/07/14
خلاصه مقاله
متن کامل مقاله

به ترتيب خروجي‌ها دقت كنيد. در PC1 نحوه مشخص كردن آرگومان ورودي متد و استفاده از آن را مشاهده مي‌كنيد. در PC2 مطابق تعريف تمام پيغام‌هاي Logging همان‌طور كه در كد pcAspect2 تعريف شده بود، بعد از اجراي تمام متدها چاپ شده است.
در PC3 نحوه استفاده از شيء كلاس مبدأ را مشاهده مي‌كنيد. در ضمن كد متد SecurityChecking در كلاس Dataاصلاً اجرا نشده است، زيرا ما Advice‌اي را كه بايد درباره اين متد اجرا مي‌شد، around در نظر گرفته‌ايم و همان‌طور كه در بالا ذكر شد Adviceهاي نوع around كلاً اجراي عادي join point را متوقف مي‌كنند.
احتمالاً با بررسي اين كد، متد كار Adviceها و point-cutها تا حدود زيادي براي شما روشن شده‌است. البته پياده‌سازي‌هاي اين مفهوم ريزه‌كاري‌هاي بسيار پيچيده‌تري نيز دارند كه در اين مقاله نمي‌گنجد.

Inter-type Declaration

Inter-type Declaration امكان جالبي است كه به برنامه‌نويس اجازه مي‌دهد ساختار elementهاي برنامه را در صورت اجرا شدن يك Aspect تغيير دهد، اما تغيير ساختار به چه معنا است؟
- اضافه كردن متد، Constructor يا Field به ديگر Typeهاي برنامه (كلاس يا Aspectهاي ديگر)
- اضافه كردن يا تغيير اينترفيس‌ها و كلاس‌هاي والد تعيين شده براي Typeهاي ديگر
- تغيير حالت exceptionها از checked به unchecked
- ‌اضافه كردن warningهاي دلخواه و... .
در حقيقت، با استفاده از اين توانايي يك Aspect مي‌تواند به‌طور كامل وظيفه تعريف، نگهداري و اجراي elementهاي مورد استفاده خود را بر عهده بگيرد و اين موضوع باعث مي‌شود تا تمام موضوعات مربوط به Aspectنويس در همان فايل aspect خلاصه شود.
نوشتن كدي كه از Inter-type Declaration عموماً چيز جديدي در بر ندارد و در بيشتر موارد مانند روش كلاسيك كد نوشتن ما است. به‌عنوان مثال، كد زير به ترتيب يك Field و يك متد براي كلاس AirPlane تعريف مي‌كند.



قطعه كد زير نيز يك‌ Constructor دو Argumentي براي كلاس AirPlane تعريف مي‌كند.



كد زير نيز كلاس والد كلاس AirPlane را كلاس  SomethingFly تعيين مي‌كند.



چگونه اين‌ها را اجرا كنيم؟

اجراي يك برنامه نوشته شده تحت AOP در AspectJ با اجراي يك برنامه معمولي جاوا چندان تفاوتي ندارد. ابتدا نحوه اجراي يك برنامه را كه براي Weaving از تكنيك Compile-time استفاده مي‌كند، نشان مي‌دهيم.
به‌طور كلي براي كامپايل كردن اين برنامه‌ها، AspectJ دستور ajc را در نظر گرفته است. ساده‌ترين نوع كامپايل به صورت زير است.



براي اجراي برنامه نيز نبايد مشكلي داشته باشيم. زيرا تركيب ‌(Weaving) بين Aspect و كد اصلي انجام شده است و ما هم‌اكنون يك فايل class. كامل در اختيار داريم. پس مي‌توانيم به سادگي آن را اجرا كنيم.



مدل Load-time

اكنون سعي مي كنيم با ذكر يك مثال، نحوه  اجراي يك برنامه به صورت Load-time و اثرات آن را مشاهده كنيم.
كد ارائه‌شده در بخش <يك كد تركيبي> در قسمت قبل را در نظر بگيريد. فرض كنيد مي‌خواهيم يك Aspect ديگر به نام «pcAspect3» داشته‌‌باشيم. «pcAspect3.java» به صورت زير در نظر گرفته مي‌شود:



براي اضافه كردن aspect2 به پروژه مي‌توان دو كار انجام داد:
1- مانند قبل عمل مي‌كنيم و سه فايل data و pcAspect2 و pcAspect3 را با يكديگر كامپايل مي‌كنيم. عمليات Weaving به صورت Compile-time انجام مي‌شود و با اجراي كلاس Data نتيجه موردنظر را دريافت مي‌كنيم.
2- از ‌load-time Weaving استفاده كنيم (براي تعريف load-time Weaving به كادر Aspect Weaver مراجعه كنيد).
اصولاً در بعضي موارد ممكن است كامپايل كردن دوباره تمام پروژه بسيار هزينه‌بر باشد. با استفاده از load-time weaving نيازي به كامپايل كردن دوباره هيچ‌كدام از فايل‌هاي قبلي نيست. بلكه ما فقط كلاس فايل جديدمان را به بقيه فايل‌ها اضافه مي‌كنيم، سپس با اجراي دوباره پروژه تمام تغييرات لازم خود به خود، اعمال مي‌شود.

اما انجام اين كار به چه شكل است؟
همان‌طور كه ذكر شد ما بايد به نحوي بعد از كامپايل فايل اصلي يك Aspect را به آن معرفي كنيم.
اين اعلام به وسيله META-INF/aop.xml (فايل aop.xml درون دايركتوري META-INF) انجام مي‌گيرد. فايل aop.xml  مي‌تواند به روش‌هاي مختلفي ايجاد شود. استفاده از دستور زير به هنگام كامپايل فايل اوليه يك زير دايركتوري در دايركتوري فعلي، META-INF/aop.xml را ايجاد مي‌كند.



اين كار (ساخت فايل aop.xml) به صورت دستي نيز مي‌تواند انجام شود. اكنون بايد كد جديد خود را به قسمت اصلي برنامه اضافه كنيم. براي اين كار ابتدا كد جديد را به همان روش هميشگي كامپايل مي‌كنيم.



اعلان Aspectها در فايل aop.xml بسيار ساده است. فقط كافي است aop.xml را به صورت زير اصلاح كنيم.



اكنون با اجراي Data هر دو Aspect در پروژه اثر مي‌كنند. توجه كنيد كه در اينجا ديگر نمي‌توانيد از جاوا براي اجراي Data استفاده كنيد، زيرا در اينجا عمليات Weaving در هنگام Load شدن كلاس‌ها و بعد از اجرا انجام مي‌شود. پس بايد از دستور مخصوص اجرا به‌صورت Load-time Weaving استفاده كنيد.
اين دستور aj5) aj براي Java5) است.





و اما بعد...

اما سرنوشت AOP به كجا مي‌انجامد؟ در طول ساليان اخير ايده‌هاي مختلفي براي ايجاد يك پارادايم برتر ارائه شده‌است، اما همچنان مدل شيءگرا، به‌عنوان يك 4Silver Bullet براي عرصه پارادايم‌ها باقي مانده و سال‌ها است كه محبوب‌ترين شيوه توليد نرم‌افزار است.
AOP در تقابل با برنامه‌نويسي شيءگرا قرار نمي‌گيرد، اما همچنان عده‌اي با ترديد به توليد كيزالس و گروهش مي‌نگرند و استفاده از آن در مقياس وسيع را نيازمند تحقيق و بررسي بيشتري مي‌دانند. در اين ميان، عده‌اي پا را از اين نيز فراتر مي‌گذارند و AOP را ايده‌اي ناكارآمد در عمل و غيرقابل استفاده براي پروژه‌هاي بزرگ مي‌نامند. البته در مقابل اين دسته، افرادي نيز وجود دارند كه AOP را انقلابي در زمينه پارادايم‌هاي برنامه‌نويسي معرفي و استفاده از آن را به شدت پيشنهاد مي‌كنند.5
اما از اين افراطي‌گري‌ها چيزي نصيب مهندسان نرم‌افزار نمي‌شود. هر نظري كه درباره AOP داشته باشيد، خواه طرفدار پر و پا قرص، خواه مخالف شديد يا يك آدم بي‌طرف، در تمام موارد چيزي كه وجود دارد اين است: AOP فقط يك پارادايم برنامه‌نويسي است.
قرار نيست با AOP مشكلاتي را حل كنيد كه قبلاً نمي‌توانستيد آن را حل كنيد يا به بيان ديگر قرار نيست اين پارادايم براي شما نرم‌افزارهايي بسازد كه قبلاً نمي‌توانستيد آن‌ها را بسازيد.
رايان گالبِك درباره اين موضوع مي‌گويد: «مطرح كردن اين واقعيت كه شما مي‌توانيد همچنان با OOP سر كنيد و Cross-Cutting Concernها را با آن پياده‌سازي كنيد، چيزي را عوض نمي‌كند. زيرا بر اساس تز چرچ/تورينگ6 شما مي‌توانيد تمام مباحث موجود در مدل شيءگرا را در قالب زبان‌هاي رويه‌اي يا حتي كد اسمبلي پياده‌سازي كنيد. توانايي اصلي‌اي كه AOP براي شما به ارمغان مي‌آورد Modularization بهتر است نه قدرت بيشتر!»
صحبت‌هاي گالبِك را مي‌توان به تمام پارادايم‌هاي برنامه‌نويسي تعميم داد. پارادايم‌هاي برنامه‌نويسي براي ما ناممكن را ممكن نمي‌كنند (يا برعكس). بلكه فقط كمك مي‌كنند تا هزينه توليد و نگهداري يك پروژه براي شما كاهش يابد.
جدا از تمام اين‌ها، بحث‌هاي انتقادي اصولي نيز درباره AOP و نحوه Modularization آن وجود دارد كه قابل تعمق است. اصولا ًدر يك سيستم AOP-based به يك برنامه‌نويس قدرت بسياري داده مي‌شود كه اين موضوع مي‌تواند علاوه بر اثرات مفيد، مشكلاتي را نيز براي سيستم ايجاد كند.
توانايي ايجاد تغييرات كلي در سيستم توسط برنامه‌نويسي كه مسئوليت نوشتن كدهاي مربوط به يك Aspect را برعهده دارد مي‌تواند اثرات زيان‌باري روي كارايي كل سيستم شما بگذارد. Andres Hejlsberg معمار زبان #‌C، با وجود اين كه ايده AOP را ايده‌اي قابل تقدير و مستعد بررسي و تحقيق بيشتر مي‌داند، اما نگراني‌اش را از بابت قدرت زياد برنامه‌نويس، پنهان نمي‌كند:
«من هنوز نگراني‌هاي اساسي درباره Aspectهايي كه قدرت استدلال شما درباره كد خودتان را دچار مشكل مي‌كند، دارم. دليل بروز اين نگراني به اين موضوع برمي‌گردد كه افراد مي‌توانند به هر بخش كد شما كه مي‌خواهند، چيزهايي بيافزايند. بله به هر بخش كد و اين مي‌تواند باعث ايجاد يك 7Side effect شود. اين كار شما استدلال در مورد كدتان را بسيار مشكل مي‌كند».
در حقيقت، بيشتر نگراني‌ها درباره AOP به دو موضوع پيچيده بودن استدلال و تأثيرات ناخواسته زيان‌بار نويسنده Aspect برمي‌گردد. هرچند كه ابداع‌كنندگان AOP ادعا مي‌كنند كه با استفاده از AOP و به دليل تجمع كل جريان كاري Cross-Cutting Concernها در يك فايل، توانايي استدلال در مورد كد بالا مي‌رود، اما بايد پذيرفت كه اشكالات مطرح شده كاملاً قابل وقوع است و بايد درباره آن تصميماتي اتخاذ شود.
علاوه بر اشكالاتي كه ممكن است از طرف برنامه‌نويسي كه Aspectها را مي‌نويسد پيش آيد، برنامه‌نويس بخش اصلي نيز ممكن است با تغيير join pointهاي پيش‌بيني شده (مثلاً با تغيير نام آن‌ها) باعث ايجاد مشكلاتي شود كه برنامه‌نويس Aspect از آن بي‌خبر است.
اين دسته از نگراني‌ها درباره عدم هماهنگي بين برنامه‌نويسان بخش‌هاي مختلف و توانايي اثرگذاري بالا در يك سيستم، دغدغه  اصلي مهندسان نرم‌افزاري است كه به AOP مي‌انديشند. تمام اين موارد، اين واقعيت را بيشتر نمايان مي‌سازد؛ برنامه‌نويساني كه از AOP استفاده مي‌كنند بايد از تمام پتانسيل‌هاي آن اطلاع كامل داشته باشند تا بتوانند برنامه‌هايي به دور از مشكلاتي كه در بالا ذكر شد، ايجاد كنند.

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

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

  دانشنامه فایر فاکس
  مفهوم نرم‌افزار آزاد
  طبقه‌بندی نرم‌افزارهای آزاد و غیرآزاد
  معماری و ساختار كلی 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