13 فوریه سال 2002 میلادی، مایکروسافت نسخه ابتدایی .Net را روانه بازار کرد. شاید از همان ابتدا و با توجه با ساختار و معماری کم نقص لایه ای آن می شد حس زد که این پلت فرم، پایه بخش بزرگی از نرم افزارهای کاربردی تولید شده در جهان خواهد شد و شاید بسیاری از برنامه نویسان .Net هم اکنون نیز معتقد باشند که بهترین گزینه برای طراحی نرم افزارهای کاربردی تحت ویندوز همین پلت فرم است. من هم به عنوان کسی که از سال 2004 به طور جدی برنامه نویسی بر پایه این کتابخانه بزرگ را آغاز کردم کم و بیش با این مسئله موافق هستم اما بارها شده است که در شرایط خاصی با خود گفته ام "اینجا را نمی خواهم تحت .Net بنویسم! چکار کنم؟!"
بی شک .Net یکی از قوی ترین و غنی ترین کتابخانه های برنامه نویسی در جهان است که در دسترس عموم برنامه نویسان قرار دارد. تقریبا هر کاری که بخواهید در یک نرم افزار کاربردی تحت ویندوز انجام دهید، توسط آن ممکن است و نیازی نیست که ذهن خود را درگیر جزئیات دست و پا گیر کنید. برای انجام هر کاری تنها باید 2-3 لایه آخر کلاسهای نرم افزار را طراحی کنید و ده ها لایه پشت آن را مایکروسافت برایتان نوشته است! کلاسهای بسیار زیادی در دسترستان قرار دارد به طوری که گاهی برای انجام یک کار و نوشتن بخشی از نرم افزار چندین کلاس مختلف وجود دارند که بسته به نوع نیاز نرم افزار و بسته به سطح دسترسی که می خواهید به منابع سیستم و لایه های پایین تر داشته باشید، می توانید یکی از آنها را انتخاب کنید. البته اگر این شانس را داشته باشید که همه این راهها را بشناسید. صرف نظر از برخی کلاسها و فضا های نام پیشرفته تر که کمی اصول مهندسی نرم افزار را زیر سوال می برند (برای نمونه Reflection) و از نظر من از این جهت انتقاداتی به آنها وارد است، به طور کلی معماری .Net این اصول را به خوبی رعایت کرده است. اگر از Visual Studio .Net استفاده کنید، برای یافتن کلاسهای مورد نظر خود از بین این هزاران کلاس موجود، Object Browser گزینه خوبی است و اگر جواب نگرفتید، MSDN!
اما برای مثال این وضعیت را تصور کنید:
قسمتی از برنامه ای را می نویسید، تست می کنید، به خوبی کار می کند فقط کمی کند است. به کد خود نگاه می کنید و کمی الگوریتم را دستکاری می کنید، بهبود چندانی به چشم نمی خورد. دیگر چیزی برای دستکاری وجود ندارد ولی هنوز مشخص نیست که چرا کند است! از Profiler استفاده می کنید و با کمال تعجب می بینید که دلیل اصلی کندی، الگوریتمی است که مایکروسافت در متدی که برای مثال در کلاس ساختمان داده خاصی بکار گرفته است. شاید در ابتدا عصبانی شوید ولی با کمی فکر کردن به این نتیجه می رسید که طراحان آن شاید راه دیگری جز نوشتن کد به این شکل نداشتند. مثلا یک الگوریتم درج ساده در یک لیست مرتب شده (Sorted List) را در نظر بگیرید. با درج هر عنصر جدید الگوریتم مرتب سازی لیست یک بار اجرا می شود و شاید رویدادی (Event) هم به اصطلاح راه اندازی (Trigger) شود. شاید طراحان این کلاس به دلیل دید کلی و عمومی که به آن داشته اند و به دلیل موارد استفاده گوناگونی که برای آن می دیدند راه دیگری برای طراحی آن نداشتند اما به هر حال در مورد خاص شما این مسئله باعث کندی نرم افزار شده است. البته برای این مثال خاص و مواردی از این دست مهندسین راه حلی به نام درج گروهی یا همان متد (.AddRange) را در نظر گرفته اند که به ازای درج یک آرایه بزرگ از عناصر عمل مرتب سازی تنها یک بار انجام می شود اما اولا این راه حل همه این مشکل را برطرف نمی کند و ثانیا این تنها مشکل نیست!
گاهی مسئله به نوع دیگری خود نمایی می کند. دسترسی های سخت و گاهی عجیب به برخی متدها برای انجام کاری خاص. البته شاید این جمله درستی نباشد، شاید بهتر باشد بگوییم وجود راه حلهای عجیب برای انجام کاری خاص! این مسئله با تعجب فراوان گاهاً به مرور زمان و ظهور تکنولوژی های جدید در قالب .Net پیچیده تر هم می شود. مثلا در WPF برای دسترسی به یک سلول از یک DataGrid کمی دردسر خواهید داشت. کاری که پیش از آن و برای برنامه های مبتنی بر Windows Forms بسیار راحت تر بود. البته شاید این مسئله را بتوان به همان دلیل کلی نگری که پیشتر ذکر کردم، توجیه کرد زیرا اساساً توانایی های DataGrid در WPF تغییرات زیادی کرده است اما بهر حال دردسر، دردسر است!
مشکلاتی از این دست در .Net کم نیستند اما تا جایی که به نوشتن برنامه های کاربردی (Application) مرتبط می شود، چندان مهم هم نیستند. مشکل اساسی، اقلاً برای خود من این است که گاهی از فکر کردن زیاد به این مشکلات و راه های ممکن برای حل و گاهاً دور زدن آنها آنقدر خسته می شوم که به شدت تحریک می شوم تا با سریعترین و شاید غیر اصولی ترین روش ممکن از شر آنها خلاص شوم که این مسئله شاید در نوشتن برنامه های کوچک زیاد مهم نباشد اما برای نوشتن برنامه های بزرگ قطعا مشکل زا خواهد بود. این نکته را می دانم که هیچ چیز نمی تواند بهانه ای برای غیر اصولی نوشتن کد آنهم با وجود آگاهی از این مسئله باشد اما واقعا گاهی هیچ راه دیگری وجود ندارد، شاید هم من راه دیگری پیدا نمی کنم و یا همانطور که گفتم حوصله جستجوی بیشتر را ندارم و می دانم که این مسئله تنها مختص من نیست!
یک مثال کوچک این است که گاهی مجبور به استفاده از کلاسهای فضای نام Reflection و Reflection.Emitمی شوم که برخی از آنها واقعا از نظر اصول مهندسی نرم افزار غیر استاندارد هستند، اما انگار طراحان .Net می دانستند که باید راه فراری برای برخی مشکلات احتمالی در آن می گذاشتند که Reflection و زیر مجموعه های آن یکی از آنهاهستند که البته در عین حال همین فضاهای نام کلاسهایی هم در خود دارند که به نظر من جزئی از زیبایی های .Net هستند.
با وجود این همه به نظر من .Net آنقدر امکانات در اختیار می گذارد و آنقدر راهها را کوتاهتر می کند که این مشکلات حتی اگر شما را مجبور به تفکر و کمی کد نویسی بیشتر از انتظار کنند، ارزشش را دارد. اما همیشه وجود امکان کمی برنامه نویسی سطح پایین تر هم خوب است.
در پست آینده از دنیای .Net فاصله می گیریم و کمی به دنیای زیبای کد نویسی سیستمی خواهیم رفت...
با تشکر
هیچ نظری موجود نیست:
ارسال یک نظر