تولید محتوای برنامه نویسی در یوتوب و همزمان ترکیه سرپرست تیم توسعه هستم
کپسولهسازی با مدل متاهل در مهندسی نرم افزار.
امروز تصمیم گرفتم بخش دیگری از نوشتههایم را در پیرامون فلسفه در مهندسی نرمافزار رو با شما به اشتراک بگذارم.
از نظر من یکی از بزرگترین مشکلات زبانهای برنامه نویسی چه در برنامه نویسی فانکشنال چه در شیگرا، نبود کپسولهسازی قابل قبول هست.
نرمافزار ذاتا قابل تغییر هست و بیشتر مشکلات از تغییر به وجود میآید.
از همان روزهایی که شیگرا و فانشکنال طراحی شدند، هر کدام در تلاش بودند تغییر در نرمافزار را به صورت امن انجام بدهند تا باگهای ناگهانی رخ ندهد، این شد سطوح دسترسی مثل پابلیک یا پرایوت رو طراحی کردند.
مدتی زیادی هست در حال نوشتن یکسری راهحل در جهت بهبود این موضوع هستم.
Married Acess Modifire
در دنیای واقعی چه در اشیا و چه در جانداران ما بحث تاهل رو داریم، در این نوشته در مورد وراثت در مدل تاهل رو نمیخام به دست بگیرم و درآینده در مورد اونم صحبت خواهم کرد.
اگر یه انسان متاهل رو در نظر بگیرد او دیگر نمیتواند در اختیار دیگران باشد، مقاله عضو بودن یه شخص به یک کمپانی رو هم تاهل میداند، وقتی کارمندی استخدام شرکتی میشود دیگر اجازه فعالیت در دیگر شرکتهارو ندارد، ماشین خریداری شده در اختیار یک شخص هست و... تاهل رابطه خیلی نزدیکی با افزایش امنیت و کیفیت دارد.
همانطور که یکی از اساسیترین مفاهیم در دنیای واقعی متاهل بودن هست، میتوان از این کانسپت در دنیای توسعه الگو گرفت و یکسری کامپوننت یا فانکشن یا فیلدهارو به صورت متاهل تعریف کرد تا همیشه در اختیار یک وظیفه باشد.
در دنیای صنعت هم اگر دقت کنیم، یک کلید همسر یک قفل هست، گاها برای جلوگیری از استفاده اشتباه کاربران، طوری طراحی میکنیم که امکان جاگیری غلط ممکن نباشد، حتی مصرف کننده بخواهد اشتباه وصل بکند، این اتفاق رخ نده مانند طراحی پریزها یا سوکتها.
به نظر شما اگر یک فانکشن، کامپوننت، کلاس یا متغییر متاهل باشد و در طول حیات توسعه تنها بتواند یک همسر اختیار کند چه آوردههایی میتواند داشته باشد؟ یعنی وقتی برای اولین بار از سمت کسی استفاده شد برای دیگران امکان استفاده شدنش ممکن نباشد و کامپایلر اجازه استفاده به دیگر اجزارو رو ندهد؟
به نظر میاد روند کپسولهسازی و تغییر ناپذیری رو بتونه اصلاح بکنه و در راستای این، افزایش کوهیژن و کاهش وابستگی رو خواهیم داشت.
دیگر مثل قبل هر کسی نمیتونه فانکشن، کامپوننت یا متغیرهای متاهل رو دستکاری بکنه و اینم باعث میشه به سمت مرکزی شدن حرکت کنم.
فکر کنید من یه کامپوننت کنترل استثنا نوشتم و سطح دسترسی رو از نوع متاهل انتخاب کردم، اینجا در کل سیستم امکان استفاده از چنین مکانیزمی رو فقط و تنها فقط برای یه کامپوننت، فانکشن یا متغییر رو میده، دیگر مثل سابق برنامه نویس نمیتونه همه جا ازش استفاده بکنه و مجبور هست طراحی رو طوری انجام بده که جاهایی که نیاز داره رو از اون کلوگاه رد کنه، چیزی که در برنامه نویسی آسپکتگرا و کراس کاتینک کونسورن دنبالشیم.
فکر کنید نیازمند کار با دیتابیس هستم و میام اونو متاهل انتخاب میکنیم، دیگه نیازی به استفاده از آنتی پترن سینگلتون نخواهد بود.
نیازمند یه متغیر هستم برای کنترل یه وضعیتی و میخام اون متغییر تنها از سمت یه فانکشن قابل تغییر باشه، در عین حال سراسری هم باشه، اینجا میتونیم اون متغیر رو متاهل تعریف کنیم و خیالمون راحت هست، چون در طول حیاتش کسی نمیتونه تغییرش بده،در صورت نیاز از فانکشنی که اونو استفاده میکنه درخواست تغییر باید بدهند. در حالت عادی با پرایوت کردن سطح دسترسی برای بیرون، این کار ممکن هست ولی در این مدل آوردههای دیگری رو هم خواهیم داشت.
یه نیم نگاهی که میکنیم میبینم کلی آورده دارد، اگر زبانهای برنامه نویسی چنین امکانی بدهند، میتونه توی توسعه نرمافزار کمک بزرگی به ما بکنه، همچنین توی طراحی معماری میتونه خیلی کمک کننده باشه و طراحیهارو خیلی قابل درکتر و توسعه پذیرتر بکنه.
سطح دسترسی متاهل میتونه مفهوم تک وظیفگی رو به صورت کامل ارضا کنه و مارو نزدیک بکنه به کپسوله سازی صددرصد، اگر مشکل تک وظیفهگی حل بشه کیفیت کد به صورت چشمگیری بالا خواهد رفت.
- امنیت کد بالا خواهد بود چون تغییرات از یکجا انجام میشود.
- دیباگ کردن راحت خواهد بود چون همه چیز به سمت مرکزی شدن حرکت میکند.
- توسعه راحتر خواهد بود چون امکان دستکاری کامپوننتهای اصلی و تغییرش از طرف دیگران ممکن نخواهد بود.
- نیازی به آنتیپترن سینگلتون نخواهد بود.
- شاهد افزایش پرفورمنس خواهیم بود، چرا که مسیر حرکت دیتا معلوم بوده و یک فلو دارد.
- خواه ناخواه سیستم به سمت طراحی دیفنسیو حرکت خواهد کرد.
- به دلیل اجبار در مرکزی شدن اجزای اصلی، حجم کد کاهش پیدا میکنه و از تکرار کد جلوگیری میکنه.
- بحث غیرقابل تغییر بودن در فانکشنال پروگرمینگ رو به صورت جدی بهبود خواهد داد.
- بحث کپسوله سازی در شیگرا رو به صورت جدی بهبود خواهد.
- از استفاده نادرست توسط توسعه دهنده جلوگیری کرده و باعث کاهش باگ میشود، اینم باعث افزایش کیفیت سیستم شده و توسعه پذیری رو بالا میبره.
- توسعه سیستمهای مالتیترد راحتر خواهد بود چون اشتراک منابع تحت کنترل و مرکزی هست.
کلاس DataAccessObject تنها یک فانکشن پابلیک دارد IsConnect و اینو میتونید از هر جایی صدا بزنید استفاده کنید.
فانکشن GetByQuery رو کلاس QueryReposotory استفاده کرده و غیر اون دیگه کسی نمیتونه استفاده بکنه.
متد Add -Update-Remove رو هم کلاس CommandReposotory استفاد میکنه و کس دیگری نمیتونه استفاده بکنه.
کلاس GenericRepository خواسته دوباره از فانکشن ها استفاده بکنه ولی اجازه نداده و گفته فانکشن ها در دسترس نیستن و فقط به IsConnect اجازه داده که استفاده بکنه.
در متد main هم اگر دقت کنید به همشون اجازه دسترسی نمیده و کپسوله سازی رو تونسته خیلی راحت ارضا بکنه و از اشتباه دولوپر جلو گیری بکنه و یه کد امن و مرکزی رو بهمون میسر بکنه. حالا دولوپر های دیگه هم بخان با دیتابیس کار بکنن حتی اگرم بخان نمیتونن از آبجکت DataAccessObject استفاده بکنن.
حق کپیرایت این مقاله و مدل متاهل متعلق به علی محمودی هست و هرگونه استفاده از تصاویر،متن،مقاله،ایده بدون اجازه ناشر غیر قانونی میباشد.
مطلبی دیگر از این انتشارات
در تجارت بینالملل Out Sourcing Goods یا Offshore Out Sourcing چگونه تولیدات را مقرون به صرفه می کند؟
مطلبی دیگر از این انتشارات
آشنایی با Heap و مقایسه آن در یک شبیه سازی
مطلبی دیگر از این انتشارات
چه باید کرد؟ بخش دوم، ضمیر ناخودآگاه