________________________________________بسيار ي از افراد معتقدند، علوم كامپيوتر آن قدرها هم كه بهنظر مي آيد، سريع پيشرفت نميكند. آنها معتقدند، در بسياري از شاخهها كار تقريباً تمام شدهاست و كارهاي جديد فقط در حد پيشرفتهاي جزئي انجام ميگيرد. در حقيقت، بعضي از موضوعهاي مطرح شده توسط اين گروه بدبين، تا حدودي به واقعيت نزديك است. بسياري از پايههاي علوم كامپيوتر شكل گرفته است و به نظر ميآيد تغيير آنها، دستكم به اين زوديها امكانپذير نيست. در بعضي از شاخهها يك فناوري آنچنان جاي پايش را محكم كردهاست كه حتي تصور وجود روشي ديگر كمي سخت به نظر ميرسد.اما كامپيوتريها مردم جالبي هستند. شايد آنها خيلي پركار نباشند، اما هميشه ايدههاي جديد و خلاقانه راهي براي نفوذ به درون دنيايشان پيدا ميكنند. شايد در بسياري از زمينهها، كار شما به مطالعه كارهاي كلاسيك انجام شده محدود شود، اما هميشه جادههاي جديدي وجود دارد.گريگور كيزالس (GregorKiczales)، بيشتر وقت خود را در آزمايشگاه پارك (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 جايي است كه ديگر مدل شيءگرا جواب كارآمدي به ما نميدهد.
علاقه مندی ها (Bookmarks)