VIP همه چیز درباره برنامه نویسی

[☾♔TALAYEH_A♔☽]

آشنایی با یو ام ال


ما برای طراحی نرم‌افزار نیاز به یکسری چارت و نمودار داریم که برای این منظور از چیزی تحت عنوان Unified Modeling Language که به اختصار UML (یو ام ال) خوانده می‌شود استفاده خواهیم کرد. اگرچه که واژه ی Language را در نام این یو ام ال می بینیم، اما این در حالی است که یو ام ال یک زبان برنامه نویسی نیست بلکه نمودی عینی از یک طرح نرم‌افزار است که با استفاده از آن، چارتی که بخش‌های مختلف یک سیستم شیء گرا را تشکیل می‌دهند نشان خواهیم داد.

برای روشن شدن ساختار یو ام ال، مجدد به حساب بانکی که پیش از این مورد بررسی قرار دادیم باز می گردیم. گفتیم که کلاسی داریم تحت عنوان BankAccount که در آن یکسری Attribute داریم تحت عناوین accountNumber و accountType. علاوه بر این، کلاس ما دارای یکسری Behavior است که از آن جمله می‌توان به ()open و ()close و ()withdraw اشاره کرد. یو ام ال چنین کلاسی به صورت زیر خواهد بود:

به چنین تصویری اصطلاحاً UML Class Diagram گفته می شود. همان‌طور که در تصویر فوق مشخص است، کلاس اصلی به همراه Attribute و Behavior هایش نمایش داده شده است. علاوه بر این، کلاسی تحت عنوان SavingAccount داریم که از کلاس BankAccount ارث بری می‌کند و این در حالی است که نسبت به کلاس والد، یک Attribute تحت عنوان interestRate بیشتر دارد. در طراحی یو ام ال، زمانی که بخواهیم نشان دهیم که یک کلاس از کلاس دیگری ارث می بری می کند، این کار را با استفاده از فلش از سمت کلاس فرزند به طرف کلاس والد نشان خواهیم داد.

در ردیف اول، نام کلاس می‌آید که معمولاً نامگذاری کلاس در برنامه نویسی شیء گرا به صورت مفرد است. به عبارت دیگر، به جای نام BankAccounts از نامی همچون BankAccount استفاده می کنیم. علاوه بر این، نحوه ی نامگذاری می بایست به این شکل باشد که حرف اول هر کلمه از نام کلاس به صورت بزرگ نوشته شود.

در ردیف دوم هم Attribute های کلاس مد نظر را می نویسیم و در نهایت هم در ردیف آخر لیست Behavior ها -یا بهتر بگوییم متدهای- کلاس مد نظر را می نویسیم. توجه داشته باشیم که در نامگذاری متدهای یک کلاس، همواره می بایست از یک فعل استفاده کرد. همان‌طور که در تصویر فوق مشاهده می شود، کلیه ی متدهای کلاس BankAccount فعل هستند؛ فعل open به معنی «باز کردن»، فعل close به معنی «بستن» و فعل withdraw به معنی «گرفتن پول از حساب». علاوه بر این، متدها دارای یک جفت پرانتز هستند که وظیفه ی این پرانتزها این است که اگر متدی نیاز به پارامتر ورودی بود، آن پارامترها -یا آرگومان ها- را می‌توان داخل پرانتزها نوشت (به طور کلی، منظور از پارامتر ورودی، دیتای اولیه است که متد مد نظر ما برای آن که وظیفه‌اش را به درستی انجام دهد، نیاز به آن خواهد داشت.)

به خاطر داشته باشید
برای نامگذاری کلاس ها در زبان های برنامه نویسی شیء گرا از سبک نامگذاری PascalCase استفاده می شود. به عبارت دیگر، حرف اول از هر کلمه از نام کلاس به صورت بزرگ نوشته شود مثل BankAccount. علاوه بر این، برای نامگذاری Attribute ها و Method ها از سبکی تحت عنوان camelCase استفاده می کنیم که در آن حرف اول نام به صورت کوچک نوشته شود اما از کلمه ی دوم به بعد، حرف اول هر کلمه بزرگ نوشته شود مثل interestRate.
در طراحی یو ام ال ها، می‌توان پا را کمی از این هم فراتر گذاشت و اطلاعات بیشتری را در نمودار گنجاند:

همان‌طور که در تصویر فوق مشاهده می کنید، کلاسی داریم تحت عنوان Product که حاوی یکسری Attribute است

تحت عناوین isActive, name و itemNumber. ما در یو ام ال این امکان را خواهیم داشت تا نوع یک Attribute را نیز تعریف کنیم. برای مثال، برای name نوع استرینگ را در نظر گرفته‌ایم به این صورت که پس از name علامت : را قرار داده سپس کلیدواژه ی String را نوشته ایم. حال اگر این Attribute دارای مقدار اولیه نیز باشد، می‌توان یک علامت = قرار داده و داخل علامت های دابل کوتیشن نامی برای آن همچون New Product در نظر گرفت. Attribute دوم isActive نام دارد که نوعش بولین است. به عبارت دیگر، این Attribute یا می‌تواند true باشد یا false و در نهایت به itemNumber می‌رسیم که نوع آن داده‌ای است از جنس عدد صحیح.

در قسمت متدهای این کلاس، می‌بینیم که کلاس Product ما دارای چهار متد مختلف است که اولین آن‌ها getName نام دارد. این متد هیچ گونه پارامتر ورودی ندارد چرا که داخل پرانتزهای مقابل آن خالی است اما می‌بینیم که پس از نام متد یک علامت : قرار گرفته سپس کلیدواژه ی String نوشته شده است. این بدان معنا است که خروجی این متد داده‌ای از جنس استرینگ است. متد دوم setActive است که دارای یک پارامتر یا آرگومان ورودی از جنس بولین است. متد سوم getProductDetails نام دارد که خروجی آن داده‌ای است از جنس استرینگ و در نهایت به متدی تحت عنوان formatProductDetails می‌رسیم که خروجی این متد هم استرینگ است.

علاوه بر این، در کنار نام Attribute ها و Method ها علامت های – را + می بینیم. این علایم Visibility یا «قابلیت روئیت» ویژگی‌های این کلاس را مشخص می کنند. به طور مثال، Attribute های name, isActive و itemNumber صرفاً از داخل این کلاس قابل روئیت هستند و سایر ابجکت ها به آن‌ها دسترسی نخواهند داشت (این قابلیت، به اصل Encapsulation برنامه نویسی شیء گرایی بر می گردد.)

از میان متدها نیز، متدهای setActive, getName و getProductDetails دارای علامت + هستند و این بدان معنا است که این متدها هم از داخل این کلاس و هم توسط سایر آبجکت ها قابل روئیت اند اما متد formatProductDetails دارای علامت – است و این بدان معنا است که این متد صرفاً از داخل این کلاس قابل روئیت است.

در نهایت به Note یا «یادداشت» می رسیم. گاهی اوقات نیاز داریم تا برای درک بهتر یو ام ال، از یادداشت‌هایی استفاده کنیم که نحوه ی به کارگیری از یادداشت‌ها نیز به همین صورتی است که در تصویر فوق مشاهده می شود.

پس از این که فرا گرفتیم به چه شکل می‌توان یو ام ال کلاس مد نظر را طراحی کنیم، حال نوبت به تبدیل یو ام ال به کدهای واقعی می رسد که در آموزش بعد با این مبحث آشنا خواهیم شد اما پیش از آن، نیاز است تا با یکسری ابزارهای طراحی یو ام ال نیز آشنا شویم. بسیاری از برنامه نویسان هستند که با استفاده از قلم و کاغذ، وایت برد و چیزهایی از این دست اقدام به طراحی یو ام ال، فلوچارت و نمودارهای مورد نیاز خود می‌کنند اما این در حالی است که یکسری ابزارهای مفید نیز به بازار عرضه شده‌اند که با استفاده از آن ها، با سرعت و دقت بیشتری می‌توان اقدام به طراحی یو ام ال کرد که در ادامه با برخی از پرکاربردترین آن‌ها آشنا خواهیم شد.

Visio
مایکروسافت ویزیو نرم افزاری از خانواده ی مایکروسافت آفیس است که برای طراحی نمودار، یو ام ال و … ساخته شده است و تحت سیستم عامل ویندوز کار می کند. این نرم‌افزار برای اولین بار در سال 1992 توسط شرکتی تحت عنوان Shapeware به بازار عرضه شد که در سال 2000 توسط شرکت بزرگ نرم افزاری مایکروسافت خریداری شد.

OmniGraffle
این نرم‌افزار که برای سیستم عامل مکینتاش طرحی شده است، برای طراحی و ساخت هر نوع گرافیکی من جمله یو ام ال مورد استفاده قرار می گیرد. از جمله قابلیت‌های این نرم‌افزار می‌توان به طیف گسترده ای از تمپلیت های از پیش طراحی شده ی این نرم افزار که کار توسعه‌دهنده را ساده‌تر و سریع‌تر می‌سازند اشاره کرد.

gliffy.com
gliffy یک نرم‌افزار نمودارکشی بر پایه ی رایانش ابری است که در سال 2005 توسط دو مهندس توسعه یافت که به منظور طراحی نمودارهای یو ام ال، پلان خانه، فلوچارت و … مورد استفاده قرار می گیرد. نکته‌ای که در مورد این نرم‌افزار تحت وب می‌توان اشاره کرد این است که کاربران به سادگی می‌توانند در هر لحظه‌ای که تمایل داشته باشند طرح های خود را با سایر کاربران به اشتراک بگذارند. گلیفی در مرورگرهای گوگل کروم، فایرفاکس، سافاری و اینترنت اکسپلورر نسخه ی 9 به بالا ساپورت می شود.

creately.com
creately هم یک ابزار آنلاین دیگر برای طراحی یو ام ال است که به گفته ی خود این سایت، بیش از 50 نوع نمودار مختلف با قابلیت‌های متفاوتی می‌توان توسط این ابزار طراحی کرد. علاوه بر این، امکان همکاری با سایر دوستان به صورت آنلاین نیز وجود خواهد داشت. پالت های رنگ این ابزار دست توسعه‌دهنده را باز خواهند گذاشت تا بتواند از رنگ‌ها و طرح های مختلف در طراحی یو ام ال استفاده کند. علاوه بر این، از creately می‌توان هم به صورت آنلاین و هم آفلاین، تحت دسکتاپ یا تحت وب استفاده نمود.

lucidchart.com
Lucidchart نیز یک ابزار آنلاین برای طراحی یو ام ال است. از جمله قابلیت‌های این نرم‌افزار آنلاین می‌توان به سازگاری آن با Google Apps و نرم‌افزار Visio مایکروسافت اشاره کرد.

پلاگین های طراحی شده برای IDEها
محیط های یکپارچه ی توسعه ی نرم افزاری (IDE) همچون اکلیپس نیز دارای یکسری پلاگین هستند که با نصب آن ها، می‌توان امکان کشیدن یو ام ال از داخل نرم‌افزار را به دست آورد. برای مثال، پلاگینی همچون UML Designer یک ابزار گرافیکی است که در صورت استفاده از آن، امکان طراحی انواع یو ام ال را از داخل نرم افزار Eclipse خواهیم داشت. لازم به ذکر است که این پلاگین رایگان و اپن سورس بوده و برای استفاده از آن نیاز به پرداخت هیچ گونه هزینه ای نیست.

ArgoUML
ArgoUML با استفاده از زبان برنامه نویسی جاوا نوشته شده است اما تحت هر پلتفرمی که جاوا را ساپورت کند، قابل اجرا است. این نرم‌افزار اپن سورس بوده و برای استفاده از آن نیاز به هیچ گونه هزینه ای نیست. این نرم‌افزار از اکثر ساختارهای UML رایج پشتیبانی می کند.

Dia
Dia یک نرم‌افزار چند منظوره ی اپن سورس و رایگان است که برای طراحی فلوچارت، یو ام ال، مدار و … مورد استفاده قرار می گیرد. این نرم‌افزار روی پلتفرم های گنو/لینوکس، مکینتاش و ویندوز قابل اجرا است که تحت مجوز GPL به بازار عرضه شده است.

 

[☾♔TALAYEH_A♔☽]

تبدل یو ام ال به یک کلاس واقعی

هر آنچه که تا این مرحله از کار فرا گرفته ایم بیشتر تئوریک بوده تا عملی. در این آموزش قصد داریم تا مفاهیم شیء گرایی، اصول ساخت کلاس و آبجکت و همچنین طراحی یو ام ال که تا این مرحله فرا گرفتیم را به صورت عملی تبدیل به کدهای واقعی با استفاده از یک زبان شیء گرا همچون جاوا نماییم. برای شروع، یو ام ال کلاسی تحت عنوان Spaceship به معنی «سفینه» را در نظر می‌گیریم که برای ساخت یک بازی جنگی مورد استفاده قرار خواهد گرفت:

این کلاس از دو Attribute تحت نام های name و shieldStrength برخوردار است که name قابل روئیت هم از داخل این کلاس و هم توسط سایر آبجکت ها است که نوع آن هم از جنس استرینگ است. Attribute دوم از جنس عدد صحیح است و با توجه به این که علامت – در کنار نامش قرار گرفته، این بدان معنا است که این Attribute صرفاً از داخل این کلاس قابل روئیت می باشد. name محلی برای ذخیره سازی نام سفینه است. shieldStrength هم که به معنی «میزان قدرت محافظ سفینه» است، محلی برای ذخیره سازی داده ای از جنس عدد صحیح است که با تغییر این داده، می‌توان توان محافظتی سفینه را کم یا زیاد کرد.

در بخش متدها نیز دو متد تحت عناوین ()fire و ()reduceSheilds داریم که داده ی خروجی متد اول داده ای از جنس استرینگ است یا بهتر بگوییم متد اول داده از از جنس استرینگ را return می‌کند یا «باز می گرداند» و متد دوم هم برای این که وظیفه‌اش را انجام دهد، نیاز به یک داده ی ورودی از جنس عدد صحیح یا Integer دارد و این در حالی است که این متد هیچ چیزی را return نخواهد کرد. لازم به ذکر است که هر دوی این متدها قابل روئیت هم از داخل این کلاس و هم توسط سایر آبجکت ها می باشند. سورس کد یو ام ال فوق در زبان برنامه نویسی جاوا به صورت زیر خواهد بود:

public class Spaceship {

public String name;
private int shieldStrength;

public String fire() {
return "Boom!";
}

public void reduceShields(int amount) {
shieldStrength -= amount;
}
}
همان‌طور که در کد فوق ملاحظه می شود، برای ساخت کلاس از کلیدواژگان public class استفاده نموده سپس نام کلاس که در اینجا Spaceship است را قرار داده ایم و مقابل آن یک جفت علامت { } قرار داده ایم. هر آنچه که مابین علامت های { } قرار گیرد، از این پس متعلق به کلاس Spaceship خواهد بود.

سپس اقدام به ساخت Attribute ها کرده‌ایم که پیش از این هم گفتیم که نوع Attribute یی تحت عنوان name استرینگ است و این در حالی است که این Attribute قرار است تا از همه جای برنامه قابل روئیت باشد. پس ابتدا کلیدواژه ی public که معادل علامت + در یو ام ال است را نوشته، سپس نوع آن را با نوشتن String مشخص می‌کنیم و در نهایت نامی برای آن در نظر می‌گیریم که در این مثال name است. پس از تعریف کردن یک نام، حال نوبت به ایجاد shieldStrength می‌رسد که از جنس عدد صحیح است پس از Data Type یا «نوع داده» ای از جنس int یا «عدد صحیح» استفاده کرده و از آنجا که در یو ام ال علامت – مقابل این Attribute قرار گرفته بود، در زبان برنامه نویسی جاوا برای ایجاد این محدودیت روئیت از کلیدواژه ای تحت عنوان private استفاده می کنیم.

حال نوبت به نوشتن متدهای این کلاس می رسد. با توجه به این که متد ()fire قرار است تا از هر جای برنامه قابل روئیت باشد، ابتدا کلیدواژه ی public را نوشته سپس نوع این متد را مشخص می‌کنیم که استرینگ است و پس از آن نامی همچون fire به معنی «آتش زدن» در نظر می‌گیریم و پس از علامت های () یک جفت علامت { } قرار می‌دهیم که کلیه ی کدهای مربوط به این متد، داخل علامت های { } قرار خواهند گرفت. با توجه به این که متد ()fire در یو ام ال دارای هیچ گونه پارامتر ورودی نبود، داخل پرانتزهای متد fire را خالی می گذاریم. در یو ام ال مشخص کرده بودیم که این متد می بایست داده‌ای از جنس استرینگ را return کند. برای این منظور، داخل علامت های { } کلیدواژه ی return را نوشته و مقابل آن استرینگی تحت عنوان "!Boom" را داخل علامت های دابل کوتیشن قرار می‌دهیم چرا که در یو ام ال گفتیم این متد می بایست داده‌ای از جنس استرینگ را باز گرداند.

در ادامه ی کار، نوبت به تعریف کردن متد دوم تحت عنوان reduceSheild می رسد. این متد قرار است از همه جای برنامه قابل روئیت باشد پس ابتدا کلیدواژه ی public را نوشته سپس از آن جا که این متد قرار نیست تا هیچ نتیجه‌ای را باز گرداند، پس کلیدواژه ی void را نوشته سپس نام متد را می نویسیم. پیش از این در طراحی یو ام ال گفتیم که این متد ابتدا به ساکن برای اجرا نیاز به یک پارامتر ورودی از جنس عدد صحیح دارد. پس ابتدا نوع این پارامتر را از طریق کلیدواژه ی int مشخص کرده سپس نامی همچون amount به معنی «مقدار» برای آن در نظر می گیریم. علامت های { } را قرار داده و داخل آن ها صرفاً یک دستور بیشتر نمی‌نویسیم که عبارت است از مساوی قرار دادن مقدار amount با متغیر shieldStrength با این توضیح که در هر بار اجرای این متد، به خاطر وجود علامت – قبل از علامت = یک واحد از مقدار shieldStrength کم خواهد شد.

در این مرحله از آموزش، موفق شده‌ایم تا یک یو ام ال را به یک کلاس واقعی در زبان محبوب جاوا مبدل سازیم. همان‌طور که پیش از این توضیح دادیم، کلاس‌ها چیزهایی مفهومی و انتزاعی هستند و تا زمانی که یک آبجکت یا بهتر بگوییم «نمونه ای» از روی آن‌ها ایجاد نکنیم، این کلاس وجود خارجی نخواهد داشت. در بسیاری از زبان‌های برنامه نویسی شیء گرا همچون جاوا، پی اچ پی، سی شارپ، سی پلاس پلاس و …، از کلیدواژه ی new به معنی «جدید» برای ساخت آبجکتی از روی یک کلاس استفاده می شود. پیش از این که با نحوه ی ساخت آبجکت ها از روی یک کلاس همچون کلاس Spaceship آشنا شویم، نیاز است تا با مفهوم Constructor (کانستراکتور) در زبان‌های برنامه نویسی شیء گرا آشنا شویم.

به طور کلی، کانستراکتور یک نوع خاصی از متدها در زبان‌های برنامه نویسی شیء گرا است که داخل کلاس‌ها نوشته می‌شود تا با استفاده از آن بتوان یک آبجکت ساخت و این در حالی است که به محض ساختن یک آبجکت از روی کلاسی خاص، کانستراکتور به صورت خودکار Call یا «فراخوانی» می شود.

حال ممکن است این سؤال برای برنامه نویسان مبتدی پیش بیاید که آیا نوشتن کانستراکتور در کلاس‌ها اجباری است؟ و آیا بدون برخورداری از کانستراکتور، نمی‌توان آبجکت ساخت؟ در پاسخ به سؤال اول بایستی گفت که خیر، برای استفاده از کانستراکتور هیچ اجباری در کار نیست و در پاسخ به سؤال دوم هم بایستی گفت آری، بدون کانستراکتور هم می‌توان آبجکت ساخت. اما کانستراکتورها در زبان‌های برنامه نویسی شیء گرا ابداع شده‌اند تا کار برنامه نویس را ساده‌تر کنند! برای روشن‌تر شدن این مسأله، به کلاس Spaceship باز می گردیم. برای ساخت یک آبجکت از روی این کلاس در زبان جاوا، کدهای زیر را می‌توان نوشت:

Spaceship shahab = new Spaceship();
همان‌طور که در کد فوق مشاهده می شود، برای ساخت یک آبجکت یا «شیء» از روی کلاسی خاص در زبان برنامه نویسی جاوا، ابتدا نام کلاس را نوشته سپس نامی همچون «شهاب» برای آن در نظر می‌گیریم یک علامت = قرار داده، کلیدواژه ی new را نوشته سپس نام کلاس مد نظر را به صورت ()Spaceship می نویسیم و در نهایت یک علامت ; قرار می‌دهیم تا Statement یا «دستور» ما تکمیل شود.

به نظر شما آبجکتی که هم‌اکنون ساختیم چه وضعیتی دارا است؟ به عبارت دیگر، Attribute های name و shieldStrength که در کلاس تعریف کردیم، در آبجکت shahab دارای چه مقادیر اولیه‌ای هستند؟ در پاسخ به این سؤال بایستی گفت که این Attribute ها تهی هستند. در واقع، این شیء وجود خارجی دارد اما این در حالی است که توخالی می باشد.

Cosntructor (کانستراکتور به معنی تحت الفظی سازنده) در چنین شرایطی به داد برنامه نویسان می آید. در واقع، ما با استفاده از کانستراکتورها خواهیم توانست به محض ایجاد یک شیء جدید، آن را به صورت خودکار مقدار دهی کنیم تا وضعیت آبجکت ما از حالت تهی خارج گشته و آبجکت ساخته شده را بتوان به سادگی مورد استفاده قرار داد. در واقع، کانستراکتورها این تضمین را ایجاد می‌کنند که به محض ساخت آبجکتی از روی یک کلاس خاص، Attribute های آن کلاس با مقادیر مناسب پر خواهند شد. برای ساخت کانستراکتور در زبانی همچون جاوا، صرفاً نیاز است تا متدی هم نام با کلاس مد نظر ایجاد کرده و Attribute ها را در آن مقدار دهی کرد:

public class Spaceship {

public String name;
private int shieldStrength;

public Spaceship() {
name = "Shahab";
shieldStrength = 100;
}
}
همان‌طور که در کد فوق ملاحظه می شود، متدی از جنس public با نام Spaceship نوشته و در آن مقداری همچون "Shahab" را برای name و مقدار 100 را برای shieldStrength در نظر گرفته ایم. حال اگر همچون مراحل قبل، اقدام به ساخت یک آبجکت جدید از روی کلاس Spaceship نماییم، این آبجکت به هیچ وجه تهی نبوده و این آبجکت را می‌توان مورد استفاده قرار داد چرا که کانستراکتور که این وظیفه را داشت تا به محض ساخت یک آبجکت از روی کلاس Spaceship به صورت خودکار اجرا شود، اجرا گردیده و دستورات داخلش که همان مقدار دهی Attribute های name و shieldStrength بوده را به درستی انجام داده است. به عبارت دیگر، از این پس، آبجکت ما که shahab بود، مقدار Attribute مرتبط با name آن مقداری همچون Shahab داشته و میزان قدرت محافظتی آن برابر با 100 است. در یو ام ال، اگر در بخش متدها دیدید که متدی هم نام با کلاس مد نظر نوشته شده است، آن متد کانستراکتور است:

توجه داشته باشیم که کانستراکتورها می‌توانند پارامتر ورودی نیز بگیرند. برای مثال، کد زیر را در نظر بگیرید:

public class Spaceship {

public String name;
private int shieldStrength;

public Spaceship(String objectName) {
name = objectName;
shieldStrength = 200;
}
}
در سورس کد فوق، کانستراکتور این کلاس یک پارامتر ورودی از جنس String می گیرد که objectName نام دارد. داخل این کانستراکتور، مقدار name را برابر با objectName قرار داده ایم. حال به صورت زیر می بایست از روی کلاس Spaceship یک آبجکت جدید بسازیم:

Spaceship shahab = new Spaceship("Shahab 3");
در واقع، به محض ساخت یک آبجکت جدید از روی کلاس Spaceship، کانستراکتور فرا خوانده می شود اما از آن جا که این کانستراکتور دارای پارامتر ورودی است، در حین ساخت کلاس می بایست این پارامتر ورودی را به کلاس ()Spaceship پاس دهیم. در این مثال، یک پارامتر ورودی همچون Shahab 3 را در نظر گرفته ایم. از این پس، شیء ساخته شده از روی کلاس Spaceship دارای نام شهاب 3 بوده و توان محافظتی آن برابر با 200 است. در یو ام ال هم کانستراکتورهایی که پارامتر ورودی می گیرند را به صورت زیر نمایش خواهیم داد:

اکنون که با مفهوم Constructor ها در برنامه نویسی شیء گرایی آشنا شدیم، نیاز است تا با نقطه ی مقابل آن ها یعنی Destructor (دیستراکتور به معنی مخرب) نیز آشنا شویم. وقتی که ما آبجکت یا آبجکت هایی از روی یک کلاس خاص ایجاد می کنیم، این آبجکت ها منجر به مصرف منابع سیستمی می شوند و این در حالی است که اگر سیستم ما با کمبود منابع -مثلا حافظه ی رم- رو به رو شود، در اجرای برنامه اختلال خواهد شد. در اینجا است که نقش دیستراکتورها دوچندان می شود. در واقع، ما با استفاده از دیستراکتورها خواهیم توانست آبجکت هایی که ایجاد کرده ایم اما دیگر به آن ها نیازی نداریم را اصطلاحا Destruct کرده یا «از بین ببریم»!

 

[☾♔TALAYEH_A♔☽]

وراثت در زبان‌های برنامه نویسی شیء گرا

یکی از چهار اصلی بنیادین OOP یا «برنامه نویسی شیء گرایی» وراثت بود که پیش از این با آن آشنا شدیم. حتی اگر شما با استفاده از یک زبان برنامه نویسی شیء گرا هیچ کلاسی نسازید و هیچ کلاسی از کلاس دیگری ارث بری نکند، باز هم شما در حال استفاده از مفهومی تحت عنوان Inheritance یا «وراثت» خواهید بود! در واقع، در بسیاری از زبان‌های برنامه نویسی شیء گرا، همواره شما در حال استفاده از اصل وراثت هستید. حقیقت امر این است که وراثت در برنامه نویسی شیء گرایی آن‌قدر هم که به نظر می‌رسد پیچیده نیست. چند لحظه‌ای برنامه نویسی، کلاس، متد، آبجکت و … را فراموش کرده و جملات زیر را مرور کنیم:
- ماشین یک نوع وسیله ی نقلیه است.
- اتوبوس یک نوع وسیله ی نقلیه است.
- روباه یک نوع حیوان است.
- اسب یک نوع حیوان است.
-حساب جاری یک نوع حساب بانکی است.
- حساب پس انداز یک نوع حساب بانکی است.

حال کمی هم می‌توان مسأله را پیچیده‌تر کرد به این صورت که:
- پراید یک نوع ماشین است که یک نوع وسیله ی نقلیه است.
- پژو یک نوع ماشین است که یک نوع وسیله ی نقلیه است.

قضیه را از این هم پیچیده‌تر می‌توان کرد:
- شیانلو یک نوع سگ است که یک نوع پستاندار است که یک نوع حیوان است.
- بولداگ یک نوع سگ است که یک نوع پستاندار است که یک نوع حیوان است.

با این توضیحات به نظر می‌رسد که اکنون وراثت در برنامه نویسی را بهتر متوجه شویم. برای مثال، یکی از جملات فوق را تفسیر می کنیم. در نمونه ی آخر، بولداگ یکسری از ویژگی هایش را از سگ به ارث می برد و سگ هم دارای یکسری ویژگی های موجودی به نام پستاندار است و پستاندار هم خصوصیاتش را از چیزی تحت عنوان حیوان به ارث بـرده است. به طور خلاصه، همان‌طور که قبلاً هم توضیح دادیم زمانی که یک کلاس تمامی یا برخی از قابلیت هایش را از کلاس دیگری بگیرد، این کلاس اصطلاحاً از کلاس دیگر ارث بری می کند. در یو ام ال، ارث بری را به صورت زیر نمایش خواهیم داد:

همان‌طور که در تصویر فوق مشخص است، در طراحی یو ام ال کلاس‌های فرزند با یک فلش به طرف کلاس والد مشخص می شوند. به عبارت دیگر، فلش از سمت کلاسی که از کلاس اصلی ارث بری می‌کند کشیده می شود. در چنین شرایطی، کلاس‌های InvestmentAccount و SavingAccount و CurrentAccount تمامی ویژگی‌های کلاس BankAccount را به ارث خواهند برد.
پیش از این هم توضیح دادیم که بسیاری از زبان‌های برنامه نویسی شیء گرا این امکان را به برنامه نویس می‌دهند تا در صورت نیاز، تمامی یا برخی از ویژگی‌های کلاس والد را اصطلاحاً Override کند و یا ویژگی‌های جدیدی به کلاس فرزند اضافه کند که کلاس والد فاقد آن‌ها است.

public class SavingAccount extends BankAccount {

}
همان‌طور که در کد فوق ملاحظه می شود، در زبان برنامه نویسی جاوا برای این که کلاس SavingAccount از کلاس BankAccount ارث بری کند، می بایست از کلیدواژه ای تحت عنوان extends استفاده نماییم. کلیدواژه ی extends به معنی «توسعه یافتن از» می‌باشد و چنانچه بخواهیم کد فوق را به زبان فارسی ترجمه کنیم، با معادلی همچون «کلاسی قابل روئیت از همه جای برنامه تحت عنوان حساب پس انداز از حسابی به نام حساب بانکی ارث بری می کند»!

 

[☾♔TALAYEH_A♔☽]

آشنایی با مفهوم اینترفیس

در زبان‌های برنامه نویسی شیء گرا، در کنار مفهوم وراثت، می بایست با مفهوم دیگری تحت عنوان اینترفیس نیز آشنا شویم که بسیار پر کاربرد است. باتوجه به این که واژه ی اینترفیس در دنیای کامپیوتر و آی تی دارای معانی مختلفی است و کاربردهای فراوانی نیز دارد، ممکن است برنامه نویسان مبتدی در درک مفهوم آن کمی دچار سردرگمی شوند. به طور مثال، ما چیزی داریم تحت عنوان User Interface که به همان رابط کاربری نرم‌افزار یا اپلیکیشن که کاربران با آن تعامل می‌کنند اطلاق می‌شود اما در برنامه نویسی شیء گرایی، اینترفیس به نوعی از کلاس‌ها گفته می‌شود که هیچ گونه عملکردی نداشته و صرفاً برای ذخیره سازی تعدادی متد مورد استفاده قرار می گیرند:

public interface Vehicle {

void startEngine();
}
همان‌طور که در کد فوق ملاحظه می شود، در زبان برنامه نویسی جاوا به جای کلیدواژه ی class از کلیدواژه ی interface استفاده شده سپس نامی همچون Vehicle به معنی «وسیله ی نقلیه» برای آن در نظر گرفته ایم (همچون نام کلاس ها، نام اینترفیس ها نیز می بایست با حرف بزرگ شروع شوند.) سپس یک متد داخل آن قرار داده‌ایم تحت عنوان ()startEngine که دارای هیچ گونه Functionality یا «عملکردی» نمی باشد. در واقع، ما اصلاً اجازه نداریم تا برای متدهای قرار گرفته داخل اینترفیس عملکردی تعریف کنیم.

حال ممکن است این سؤال برای شما پیش بیاید که با توجه به این که اینترفیس ها هیچ گونه عملکردی ندارند، فایده ساخت یک اینترفیس چیست؟ در‌ واقع زمانی که ما از اینترفیس ها استفاده می کنیم، گویی به برنامه ی خود قول می‌دهیم که حتماً در کلاسی که از آن اینترفیس خاص استفاده می شود، از کلیه ی متدهای قرار گرفته داخل آن اینترفیس استفاده خواهیم کرد. برای روشن‌تر شدن این مطلب، ابتدا مثالی از اینترفیس ها در زبان برنامه نویسی جاوا می زنیم:

class Car implements Vehicle {

public void startEngine() {
return "Start!";
}
}
همان‌طور که در کد فوق ملاحظه می شود، ابتدا کلیدواژه ی class را نوشته سپس نام کلاس که Car است را نوشته ایم. برای آن که کلاس ما بتواند از اینترفیسی تحت عنوان Vehicle تبعیت کند، از کلیدواژه ای تحت عنوان implements استفاده نموده و در نهایت هم نام اینترفیس که در اینجا Vehicle است را آورده ایم. از آنجا که قول داده‌ایم تا در این کلاس حتماً متدی تحت عنوان ()startEngine داشته باشیم، پس چنین کلاسی را تعریف کرده که خروجی آن، return کردن استرینگی تحت عنوان !Start است. برای نشان دادن اینترفیس ها در یو ام ال نیز از ساختار زیر می توان استفاده نمود:

همان طور که در تصویر فوق مشخص است، برای نمایش دادن اینترفیس ها در یو ام ال، از کلیدواژه ی Interface داخل علامت های « » استفاده کرده سپس نام اینترفیس را پایین آن می نویسیم و کلاسی هم که از آن اینترفیس تبعیت می کند را با علامت پیکان از سمت کلاس به اینترفیس مشخص می سازیم.

 

[☾♔TALAYEH_A♔☽]

آشنایی با مفهومی تحت عنوان دیزاین پترن در برنامه نویسی شیء گرایی


در دنیای برنامه نویسی شیء گرایی، کمتر برنامه نویسی که حرفه‌ای باشد را می‌توان یافت که با چیزی تحت عنوان Design Patterns (دیزاین پترن یا الگوهای طراحی) آشنا نباشد. به طور خلاصه، منظور از دیزاین پترن راه کارهایی اصولی و در عین تست شده است که در پاسخ به چالش هایی ایجاد شده‌اند که در توسعه ی نرم‌افزار با آن‌ها مواجه خواهیم شد. از یک بعد دیگر، دیزاین پترن ها را می‌توان به عنوان یکسری Best Practices نیز در نظر گرفت.

به خاطر داشته باشید
در برنامه نویسی یا به طور کلی هر مهارتی، Best Practices به یکسری اصول و قوانینی گفته می‌شود که توسط جامعه ی گسترده ای از کاربران حرفه‌ای مورد استفاده قرار می‌گیرد و همین مسأله منجر گشته تا به صورت یک قانون کلی نانوشته درآیند که توصیه می‌شود افراد مبتدی نیز از این قوانین تبعیت کنند. برای روشن شدن این مسأله مثالی می زنیم. یک Best Practice در نامگذاری کلاس‌ها این است که آن‌ها را به صورت PascalCase بنویسیم. به عبارت دیگر، حرف اول کلیه ی کلمات در نام کلاس به صورت بزرگ نوشته شود. توجه داشته باشیم که اگر از این قانون تبعیت نکنیم هیچ مشکلی به وجود نمی‌آید اما بهتر آن است که نامگذاری های ما به این شکل باشند.
در حقیقت، دیزاین پترن ها به برنامه نویس کمک می‌کنند تا به بهترین شکل ممکن ساختار برنامه ی خود را بچینند تا بتوانند بهترین نتیجه را دریافت کنند. توجه داشته باشیم که دیزاین پترن ها اصلا در جزئیات یک نرم‌ افزار دخالتی نمی‌کنند و این در حالی است که یک دید کلی به برنامه نویس می دهند.

برای روشن شدن این مسأله مثالی می زنیم. فرض کنیم که در برنامه ی خود یک کلاس داریم که از روی آن چند آبجکت ساخته ایم. ما نیاز داریم که اگر یکی از این آبجکت ها دستخوش تغییر شد، سایر آبجکت ها به این تغییر پی ببرند و بالتبع رفتار متفاوتی از خود نشان دهند. برای انجام این کار، راه کارهای بسیاری وجود دارد اما از میان آن‌ها یک راه‌کار -یا بهتر بگوییم یک دیزاین پترن- است که تست شده و قابل اعتماد است و با خیال راحت می‌توان آن استایل برنامه نویسی را مورد استفاده قرار داد که Observer Design Pattern نام دارد.

مثال دیگری می زنیم. فرض کنیم که یک آبجکت توسط یکسری آبجکت دیگر دستخوش تغییر می‌شود اما ما نیاز داریم تا تغییر آخر را اصطلاحاً Undo یا «لغو» کنیم. در اینجا هم می‌توان روش‌های بسیار متنوعی را برای انجام این کار در نظر گرفت اما روش یا دیزاین پترنی که توصیه می‌شود Memento Design Pattern نام دارد که تست شده است و همان نتیجه‌ای که ما می‌خواهیم را در اختیارمان قرار می دهد.

در واقع، دیزاین پترن ها پاسخ‌ به چالش هایی همچون آنچه در بالا به آن‌ها اشاره شد می‌باشند که در توسعه ی هر نوع نرم افزاری -از تحت وب گرفته تا اپلیکیشن موبایل و نرم افزارهای دسکتاپ و حتی طراحی بازی‌های کامپیوتری- می‌توانند به داد برنامه نویسان برسند. جالب است بدانیم که رواج دیزاین پترن ها با انتشار کتابی تحت همین عنوان در اواسط دهه ی 1990 به بازار صورت گرفت:

در این کتاب، 23 دیزاین پترن که در سه گروه مختلف تقسیم‌بندی شده‌اند مورد بررسی قرار که عبارتند از:

Creational Patterns
Abstract Factory
Builder
Factory Method
Prototype
Singleton

این دیزاین پترن ها زمانی به کار می‌آیند که بخواهیم از روی کلاسی اقدام به ساخت آبجکت کنیم.

Structural Patterns
Adapter
Bridge
Composite
Decorator
Facade
Flyweight
Proxy

این دیزاین پترن ها برای ساخت کلاس‌ها مورد استفاده قرار می گیرند. به عبارت دیگر، به نوعی با مبحث وراثت درگیر هستند به این شکل که چگونه می‌توان کلاسی هایی نوشت که هم راحت‌تر و هم اثربخش تر بتوان از آن‌ها ارث بری کرد.

Behavioral Patterns
Chain of Responsibility
Command
Interpreter
Iterator
Mediator
Memento
Observer
State
Strategy
Template Method
Visitor

این دیزاین پترن ها هم زمانی مورد استفاده قرار می‌گیرند که بخواهیم ارتباط مابین آبجکت ها را هندل کنیم.

توجه داشته باشیم که مبحث دیزاین پترن ها بسیار مبحث پیچیده و سطح بالایی است که بدون شک بسیاری از برنامه نویسانی که برچسب حرفه‌ای روی خودشان می‌زنند نیز با آن‌ها به صورت کامل و جامع آشنایی ندارند! و بالتبع برای درک بهتر آن ها، نیاز به یک دوره ی آموزشی اختصاصی است اما با توجه به این که این دوره مقدماتی بوده و برای دانشجویانی طراحی شده است که تازه قدم به دنیای برنامه نویسی گذاشته اند، یکی از رایج ترین آن‌ها -سینگلتون- را در قالب مثال‌هایی ساده در آموزش‌ بعد بیان خواهیم کرد (برای آشنایی با نحوهٔ پیاده‌سازی برخی از الگوهای طراحی رایج، می‌توانید به دورهٔ آشنایی با الگوهای طراحی در سکان آکادمی مراجعه نمایید.)

دانلود رمان و کتاب های جدید

 

[☾♔TALAYEH_A♔☽]

آشنایی با دیزاین پترنی تحت عنوان سینگلتون

برای این که متوجه شویم Singleton Design Pattern برای حل چه مشکلی طراحی شده است، ابتدا سناریویی تعریف می کنیم. ما کلاسی نوشته‌ایم و می‌دانیم که آبجکت های متعددی ممکن است از روی این کلاس ساخته شود اما اگر بخواهیم به برنامه ی خود دستور دهیم که صرفاً یک آبجکت از روی کلاس مد نظرمان ساخته شود چه؟ به عبارت دیگر، این کلاس را محدود کنیم به یک شیء!

ممکن است این سؤال برای شما پیش بیاد که فایده ی این کار چیست؟ در پاسخ به این سؤال بایستی گفت که در بسیاری مواقع در کدنویسی، برای ما مواقعی پیش می‌آید که صرفاً به یک شیء از روی یک کلاس نیاز داریم مثلاً زمان هایی که یک کلاس داریم که مسئول نمایش صفحه ی اصلی اپلیکیشن است و ما صرفاً به یک صفحه ی اصلی بیشتر نیاز نخواهیم داشت پس چرا باید اجازه ی ساخت بیش از یک شیء از روی کلاس مسئول این کار را بدهیم؟ در واقع، وجود امکان ساخت بیش از یک شیء از روی این کلاس نه تنها ضرورتی ندارد حتی ممکن است منجر به بروز مشکل نیز گردد.

حال ممکن است شما با خود بگویید که ما بدون آن که کلاس مد نظر را محدود کنیم، می‌توانیم خودمان یا سایر برنامه نویسان تیم را محدود به ساخت صرفاً یک آبجکت از روی این کلاس کنیم. در پاسخ به چنین رویکردی بایستی گفت درست است که چنین کاری امکان‌پذیر است، اما تضمینی برای عدم نقض آن وجود ندارد و ممکن است یکی از اعضای تیم توسعه ی نرم‌افزار به اشتباه اقدام به ساخت بیش از یک آبجکت از روی این کلاس نماید پس Best Practice آن است که از دیزاین پترنی که برای این کار طراحی شده است -سینگلتون- برای ساخت این کلاس استفاده نماییم.

دیزاین پترن سینگلتون این تضمین را ایجاد می‌کند که ما صرفاً یک آبجکت از روی یک کلاس خواهیم داشت و صرفاً یک راه برای دسترسی به آن آبجکت در سرتاسر نرم‌افزار وجود دارد. توجه داشته باشیم که این دیزاین پترن در زبان‌های برنامه نویسی شیء گرای مختلف، به روش‌های مختلفی پیاده‌سازی می‌شود لذا بسته به نوع زبانی که می‌خواهیم یاد بگیریم، می بایست از استایل خاصی برای پیاده‌سازی سینگلتون استفاده نماییم. به طور مثال، در این آموزش روش پیاده‌سازی سینگلتون در زبان برنامه نویسی جاوا را مورد بررسی قرار خواهیم داد:

public class MySingleton {

public myMethod() {

}
}
پیش از هر چیز، ابتدا یک کلاس می‌سازیم مثلاً تحت عنوان MySingleton. این کلاس می‌تواند حاوی Attribute ها و Method های مختلفی باشد به همان صورتی که تاکنون مورد استفاده قرار داده ایم. به طور مثال، متدی تحت عنوان ()myMethod در آن ایجاد کرده‌ایم که مثلاً قرار است کار خاصی انجام دهد. با توجه به این که روش ایجاد این کلاس هیچ فرقی با روش معمولی ایجاد یک کلاس‌ در زبان برنامه نویسی جاوا نمی کند، پس بالتبع خواهیم توانست ده‌ها آبجکت از روی این کلاس بسازیم و این در حالی است که می بایست جلوی این کار را بگیریم. برای این منظور، کلاس خود را به صورت زیر تغییر خواهیم داد:

public class MySingleton {

private MySingleton { }

public myMethod() {

}
}
همان‌طور که در کد فوق مشاهده می شود، یک کانستراکتور از جنس private (خصوصی یا محدود) داخل کلاس مان ایجاد کرده‌ایم که بدان معنا است که هیچ کسی از خارج از این کلاس قادر به ساخت آبجکتی از روی آن نخواهد بود و فقط خودمان آن هم از داخل این کلاس می‌توانیم از رویش آبجتی بسازیم. حال ممکن است این سؤال پیش بیاد که با ایجاد این محدودیت اعمال شده توسط کانستراکتور، ما چگونه خواهیم توانست یک شیء‌ از روی این کلاس ایجاد کنیم؟ در پاسخ به این سوال، می بایست دو کار انجام داد:

public class MySingleton {

private static MySingleton __me = null;

private MySingleton { }

public myMethod() {

}
}
همان‌طور که در کد فوق ملاحظه می شود، متغیری از جنس private و static تحت عنوان me__ ساخته‌ایم که به منظور ظرفی برای نگهداری آبجکت کلاس MySingleton می‌باشد و مقدار اولیه ی آن را برابر با null یا «تهی» قرار داده‌ایم (توجه داشته باشیم که نام me__ کاملاً دلخواه است.) در ادامه، نیاز به ساخت یک متد جدید داریم و اینجا است که دیزاین پترن سینگلتون عملی خواهد شد:

public class MySingleton {

private static MySingleton __me = null;

private MySingleton { }

public static MySingleton getInstance()
{
if (__me == null) {
__me = new MySingleton();
}
return MySingleton;
}

public myMethod() {

}
}
همان‌طور که در کد فوق ملاحظه می شود، متدی تحت عنوان getInstance ساخته‌ایم -البته هر نام دیگری نیز می‌توان انتخاب کرد- که از جنس static است. به عبارت دیگر، فقط از داخل این کلاس می‌توان آن را فراخوانی کرد. داخل این متد، یک دستور شرطی قرار دارد که داخل پرانتزهای دستور شرطی if چک کرده‌ایم که اگر متغیر me__ تهی بود (برای مقایسه کردن دو چیز در اکثر زبان‌های برنامه نویسی، از دو علامت == پشت سر هم استفاده می شود)، دستور داخل این شرط اجرا شود که عبارت است از مقداردهی کردن متغیر me__ با نمونه‌ای از روی کانستراکتور و در نهایت هم این آبجکت را اصطلاحاً return خواهیم کرد یا بهتر بگوییم «به عنوان خروجی این متد در نظر خواهیم گرفت». حال اگر بخواهیم یک شیء از روی این کلاس بسازیم، به صورت زیر عمل خواهیم کرد:

MySingleton single = MySingleton.getInstance();
توجه داشته باشیم که تا وقتی که برنامه نیازی به آبجکتی از روی این کلاس نداشته باشد، آن آبجکت ساخته نخواهد شد اما به محض نیاز به این آبجکت، یکی ساخته شده اما اجازه ی ساخته شدن بیش یک بار داده نخواهد شد و در صورتی که در آینده بخش دیگری از نرم‌افزار نیاز به آبجکتی از روی این کلاس داشته باشد، آبجکت از پیش ساخته شده حاضر و آماده در اختیارش قرار خواهد گرفت! از این پس، به سادگی قادر خواهیم بود تا به متدهای کلاسی که این آبجکت از روی آن ساخته شده است دسترسی پیدا کنیم:

single.myMethod();

دانلود رمان و کتاب های جدید

 

[☾♔TALAYEH_A♔☽]

آشنایی با برخی قوانین برنامه نویسی

برنامه نویسی پر است از قوانین نوشته و نانوشته ای که بسیاری از برنامه نویسان حرفه‌ای سراسر دنیا از آن‌ها تبعیت می کنند. وقتی که ما شروع به یادگیری یک زبان برنامه نویسی می کنیم، پیش از هر چیز با قوانین خاص آن زبان آشنا می‌شویم و یاد می‌گیریم که با آن زبان خاص چه کارهایی را می‌شود انجام داد و چه کارهایی را نمی توان!

توجه داشته باشیم که یادگیری قوانین مختص هر زبان در مقایسه با سایر قوانین حاکم بر زبان‌های برنامه نویسی و اصول توسعه ی نرم‌افزار بسیار آسان است چرا که در صورت عدم تبعیت از این قوانین -مثلا قرار دادن عدد در ابتدای نام متغیر در یک زبان برنامه نویسی که برای نامگذاری متغیرها اجازه نداریم از عدد به عنوان کاراکتر اول استفاده کنیم- منجر به Crash (کرش یا منهدم شدن) برنامه می شود.

اما در برنامه نویسی شیء گرایی همه چیز به همین شفافی نیست. به طور مثال، اگر در برنامه‌ای که با یک زبان شیء گرا نوشته شده ما اقدام به ایجاد چندین کلاس متفاوت کنیم که چیزی در حدود 90 درصد آن‌ها کار مشابهی را انجام می دهند، ما با هیچ مشکلی مواجه نخواهیم شد اگرچه که این کار بر خلاف اصول برنامه نویسی شیء گرایی است.

برای این منظور، یکسری Guidelines یا «راه کارهایی» برای استفاده ی اصولی از مفاهیم برنامه نویسی شیء گرایی وجود دارد که با پیروی از آن ها، این تضمین را می‌توانیم ایجاد کنیم که برنامه هایمان ساختار یافته، اصولی، قابل دیباگ کردن، قابل توسعه و از همه مهم‌تر حرفه‌ای هستند.

توجه داشته باشیم راه کارهایی که در آموزش‌های بعد ارائه خواهند شد هیچ ربطی با دیزاین پترن ها ندارد. در واقع، دیزان پترن ها راه کارهایی برای یک موقعیت خاص در برنامه نویسی شیء گرایی هستند اما راه کارهای مد نظر ما چیزهایی کلی هستند و یک دید همه جانبه در ارتباط با برنامه نویسی شیء گرایی به ما خواهند داد.

برای مثال، قانون DRY را می‌توان در نظر گرفت که مخفف واژگان Don`t Repeat Yourself به معنی «هرگز کار تکراری نکنید!» است. اگر در کدنویسی مواقعی برای ما پیش می‌آید که قطعه کدی را از جایی در سورس کد کپی کرده سپس در جای دیگر دقیقاً همان قطعه کد را پیست می کنیم، بر اساس قانون DRY این کار کاملاً اشتباه است. در چنین مواقعی ما به سادگی می‌توانیم کدهای این چنین را در قالب متدهای مختلفی ایجاد کرده و هر کجا که به آن کد نیاز داشتیم، متد مد نظر را Call یا «فراخوانی» کنیم. علاوه بر این، اگر در آینده بخواهیم در قطعه کد خاصی تغییری ایجاد کنیم، صرفاً نیاز خواهیم داشت تا این تغییر را در یک جا اعمال کرده که در نتیجه تغییر مد نظر ما در هر کجایی که آن متد را فراخوانی کرده باشیم اعمال خواهد شد.

به عنوان مثالی دیگر، قانون YAGNI که مخفف واژگان You Ain`t Gonna Need It به معنی «بعید به نظر می رسه که در آینده بهش نیاز داشته باشی!» است. برای برنامه نویسان -به‌ خصوص برای برنامه نویسان مبتدی- بسیار پیش می‌آید که دوست دارند برنامه‌هایی که می‌نویسند کامل و جامع باشند و جالب است بدانیم که در برخی مواقع برنامه نویسان دچار وسواس فکری می‌شوند به این شکل که می‌خواهند در برنامه ی مد نظرشان تمامی ایده‌هایی که دارند اعمال شوند. راحت بگوییم که این سیاست در توسعه ی نرم‌افزار کاری بس اشتباه است! اگر شما با خود فکر می‌کنید که مثلاً فلان قابلیت در آینده ممکن است به کار آید، می بایست دست نگه دارید. صرفاً روی قابلیت‌های کلیدی نرم‌افزار تمرکز کنید و در صورتی که در آینده نیاز به قابلیت جدیدی داشتید، در زمان مناسب آن قابلیت را خواهید افزود.

گاهی اوقات،‌ سورس کدی که نوشته‌ایم به درستی کار می‌کند اما یک جای کار می لنگد که گویی همه چیز به درستی در جای خودش قرار نگرفته است. به طور مثال، متدهای طولانی را می‌توان در نظر گرفت. گفته می‌شود یک متد خوب متدی است که از آغاز تا پایان آن بدون اسکرول کردن سورس کد در صفحه نمایش قابل روئیت باشد. شاید چنین چیزی کمی اغراق آمیز باشد و نتوان متدهایی که کارهای خاصی انجام می‌دهند را به این کوتاهی نوشت اما در اینجا منظور اصلی این است که تا حد ممکن می بایست از نوشتن متدهای طولانی خودداری کرده و متدهای طولانی را به چندین متد کوچک تقسیم‌ بندی کنیم که در این صورت خوانایی سورس کد از یک سو و همچنین دیباگ کردن برنامه در صورت نیاز از سوی دیگر به مراتب راحت‌تر صورت خواهد گرفت.

به عنوان مثالی دیگر، می‌توان به نامگذاری های خیلی کوتاه و یا خیلی بلند اشاره کرد. تحت هیچ عنوان متغیری را تحت عنوان مثلاً i نامگذاری نکنید چرا که در مرور سورس کد در آینده توسط خودمان و یا سایر توسعه دهندگان دچار سردرگمی خواهیم شد. نام های بسیار طولانی نیز مشکل زا هستند. به طور مثال نامی همچون noOfStudentsInEachClassOfUniversity به معنی «تعداد دانشجویان در هر کلاس دانشگاه» را می‌توان خیلی ساده‌تر و به صورت studentsNo به معنی «تعداد دانشجویان» نوشت.

مسأله ی دیگری که می بایست به آن اشاره کرد، Comment گذاری است. به طور کلی، کامنت ها توضیحاتی هستند که از دید کامپایلرها، مفسرها و همچنین کاربران نرم‌افزار پنهان بوده و صرفاً در معرض دید توسعه دهنده ی نرم‌افزار قرار می‌گیرند تا با ماهیت بخش‌های مختلف نرم‌افزار آشنا شده و بداند که هر بخش چه کاری انجام می دهد. گفته می‌شود کد خوب کدی است که آنقدر تمیز نوشته شده باشد و همه چیز آن شفاف باشد که نیازی به کامنت نداشته باشد و خود کد گویای عملکردش باشد اما به هر حال امروزه کامنت گذاری در سورس کد به عنوان یک Best Practice در آمد و لاجرم ما هم می بایست از این قانون تبعیت کنیم. گاهی اوقات برنامه نویسان مبتدی را می‌بینیم که دچار وسواس کامنت نویسی می‌شوند به طوری که تعداد کامنت های ایشان در سورس کد به مراتب بیشتر از کدهای اصلی برنامه است:

// This creates a variable called box & sets it to zero
int box = 0;
همان‌طور که در مثال فوق می بینیم، ما یک متغیر ایجاد کرده‌ایم تحت عنوان box به معنی «بسته» اما کامنتی که برای آن با مضمون «این متغیری است تحت عنوان جعبه که دارای مقدار اولیه ی صفر است» در نظر گرفته‌ایم که در حقیقت نوشتن این کامنت اصلاً ضرورتی ندارد و صرفا منجر به شلوغ شدن سورس کد می شود. در ضمن، اگر کامنت هایی در سورس کد خود بنویسیم که به معنای واقعی کلمه ارزشمند نباشند، وقتی در آینده توسعه دهنده ی دیگری به سورس کد ما نگاه کند، با توجه به این که کامنت ها در برخی جاهای برنامه واقعا غیرضروری و اضافی هستند، این ایماژ برایش ایجاد می شود که گویی تمامی کامنت های نوشته شده به این شکل هستند و این احتمال نیز وجود دارد که دیگر به هیچ وجه به کامنت ها -حتی آن هایی که به خوبی و درستی نوشته شده اند- توجهی نکند!

به عنوان مثال آخر، می‌توان کلاس‌هایی را مثال زد که به قول معروف «همه فن حریف» هستند. این کلاس‌ها آنقدر قابلیت و عملکرد برایشان در نظر گرفته شده که در جای جای سورس کد، رد و نشانی از آن‌ها می یابیم که اتخاذ چنین سیاستی نیز اشتباه است. در واقع، هر کلاس در برنامه نویسی شیء گرایی قرار است یک کار خاص را انجام دهد. پس چنین کلاس‌هایی را می بایست به چندین کلاس تخصصی و مجزا از یکدیگر با یکسری متدهای کاربردی برای هر کدام بازنویسی کرده و هر کجا که نیاز بودم، از آن‌ها استفاده نماییم.

آنچه در بالا بدان اشاره شد، صرفاً Guideline هایی بودند که هم در برنامه نویسی سنتی و هم در برنامه نویسی شیء گرایی می بایست مد نظر داشت اما همان‌طور که قبلاً هم گفتیم، در OOP نیاز به یکسری قوانین سخت گیرانه تری داریم تا این تضمین ایجاد شود که ما به درستی اصول شیء گرایی را به کار گرفته‌ایم که در آموزش‌های بعد با این قوانین بیشتر آشنا خواهیم شد.

دانلود رمان و کتاب های جدید

 

[☾♔TALAYEH_A♔☽]

آشنایی با قوانین پنج‌گانهٔ SOLID


SOLID دربرگیرندهٔ اصولی در برنامه‌نویسی شییٔ‌گرایی است که در اوایل سال 2000 توسط مهندسی به نام Robert Martin ابداع شد که تحت عنوان Uncle Bob یا «عمو باب» نیز شناخته می‌شود. وقتی این اصول به درستی در کنار یکدیگر به کار گرفته شوند، این امکان را به برنامه‌نویس یا توسعه‌دهنده می‌دهند تا با سهولت بیشتری دست به توسعهٔ نرم‌افزار بزند مضاف بر اینکه به‌کارگیریِ این اصول امکانی را به برنامه‌نویسان خواهد داد تا با رویکردی چابک به توسعهٔ نرم‌افزارهای خود پرداخته، از مرتکب شدن اشتباهات کوچک جلوگیری کنند و در صورت نیاز هم به سادگی اقدام به بازنویسی کدهای خود کنند (در فصل آینده، با مفهوم برنامه‌نویسی چابک بیشتر آشنا خواهیم شد.) به طور کلی، SOLID مخفف اصطلاحات زیر است:

- Single Responsibility Principle
- Open/Closed Principle
- Liskov Substitution Principle
- Interface Segregation Principle
- Dependency Inversion Principle

Single Responsibility Principle
این قانون که به طور خلاصه SRP نیز نامیده می‌شود، حاکی از آن است که یک کلاس باید صرفاً یک وظیفه بیشتر نداشته باشد که در این صورت، کلاس‌ها فقط و فقط به خاطر ایجاد تغییر در وظیفه‌ای که انجام می‌دهند دستخوش تغییر خواهند شد نه چیز دیگر! کلاس‌ها می‌توانند فیچرهای مختلفی داشته باشند اما تمامی آن‌ها باید مربوط به یک حوزه بوده و مرتبط به هم باشند که در نهایت با محترم شمردن چنین قانونی، برنامه‌نویسان دیگر قادر نخواهند بود تا کلاس‌های اصطلاحاً همه‌فن‌حریف بنویسند.

Open-Closed Principle
هر کلاسی باید برای توسعه یافتن قابلیت‌هایش اصطلاحاً Open بوده و دست برنامه‌نویس برای افزودن فیچرهای جدید به آن باز باشد اما اگر وی خواست تا تغییری در کلاس ایجاد کند، چنین امکان باید Closed بوده و او اجازهٔ چنین کاری را نداشته باشد. فرض کنیم نرم‌افزاری نوشته‌ایم که دارای چندین کلاس مختلف است و نیازهای اپلیکیشن‌مان را مرتفع می‌سازند اما به جایی رسیده‌ایم که نیاز داریم قابلیت‌های جدید به برنامهٔ خود بیفزاییم. بر اساس این قانون، دست‌مان برای تغییر یا بهتر بگوییم افزودن فیچرهای جدید به کلاس مد نظر باز است در حالی که این قابلیت‌های جدید باید در قالب افزودن کدهای جدید صورت پذیرد نه ریفکتور کردن و تغییر کدهای قبلی!

برای روشن‌تر شدن این مسأله مثالی می‌زنیم. پیش از این با مفهوم وراثت در برنامه‌نویسی آشنا شدیم. فرض کنیم کلاسی داریم تحت عنوان BankAccount که دو کلاس دیگر تحت عناوین SavingAccount و InverstmentAccount از آن ارث‌بری می‌کنند و قصد داریم کلاس جدیدی تحت عنوان CurrentAccount ایجاد کنیم که از BankAccount ارث‌بری می‌کند اما این کلاس جدید دارای یکسری قابلیت‌هایی است که در کلاس والد دیده نشده‌اند که در چنین شرایطی به جای آنکه قابلیت‌های مد نظر جدید را به کلاس والد بیفزاییم، نیاز خود را از طریق افزودن قابلیت‌های جدید در همان کلاس فرزند عملی می‌کنیم. به عبارتی، هرگز دست به تغییر کدهای موجود نزده و قانون Open/Closed را هم به رسمیت شناخته‌ایم به طوری که کلاس مد نظرمان برای توسعه باز است اما برای اِعمال هر گونه تغییری بسته است.

Liskov Substitution Principle
این اصل حاکی از آن است که کلاس‌های فرزند باید آن‌قدر کامل و جامع از کلاس والد خود ارث‌بری کرده باشند که به سادگی بتوان همان رفتاری که با کلاس والد می‌کنیم را با کلاس‌های فرزند نیز داشته باشیم به طوری که اگر در شرایطی قرار گرفتید که با خود گفتید کلاس فرزند می‌تواند تمامی کارهای کلاس والدش را انجام دهد به جزء برخی موارد خاص، اینجا است که این اصل از SOLID را نقض کرده‌اید.

Interface Segregation Principle
پیش از این هم گفتیم که اینترفیس‌ها فقط مشخص می‌کنند که یک کلاس از چه متدهایی حتماً باید برخوردار باشد. در همین راستا و بر اساس این قانون، چندین اینترفیس تک‌منظوره به مراتب بهتر است از یک اینترفیس چندمنظوره است به طوری که اگر یک اینترفیس چندمنظورهٔ کامل و جامع داشته باشیم و سایر کلاس‌های ما از آن اصطلاحاً implements کنند،‌ در چنین صورتی ممکن است برخی خصوصیات، متدها و رفتارها را به برخی کلاس‌هایی که اصلاً نیازی به آن‌ها ندارند تحمیل کنیم اما اگر از چندین اینترفیس تخصصی استفاده کنیم، به سادگی می‌توانیم از هر اینترفیسی که نیاز داشته باشیم در کلاس‌های مد نظر خود استفاده نماییم و در صورتی هم کلاسی وجود داشت که نیاز به استفاده از چندین اینترفیس مختلف داشت، دست ما باز خواهد بود تا آن کلاس را از چندین اینترفیس implements کنیم.

Dependency Inversion Principle
درک این اصل از اصول پنج‌گانهٔ SOLID کمی دشوارتر به نظر می‌رسد و برخی تازه‌کارها آن را با Dependency Injection اشتباه می‌گیرند. به طور خلاصه، در OOP باید تمام تلاش خود را به کار بندیم تا Dependency (وابستگی) را مابین کلاس‌ها، ماژول‌ها و آبجکت‌های سطح بالا با ماژول‌های سطح پایین به حداقل برسانیم که با این کار، اِعمال تغییرات در آینده به مراتب راحت‌تر صورت خواهد پذیرفت.

در پایان اگر علاقمند به مطالعهٔ بیشتر در مورد این اصول هستید، توصیه می‌کنیم به دورهٔ آموزش قوانین SOLID مراجعه نمایید که در آن با ذکر مثال‌هایی واقعی، این قوانین توضیح داده شده‌اند.

دانلود رمان و کتاب های جدید

 

[☾♔TALAYEH_A♔☽]

آشنایی با قوانین GRASP در برنامه نویسی شیء گرایی


علاوه بر اصول پنج‌گانه ی SOLID در برنامه نویسی شیء گرایی، برخی اصول توسعه ی نرم‌افزار به سبک شیء گرایی هستند که داشتن یک آشنایی نسبی با آن‌ها خالی از لطف نیست. GRASP که مخفف واژگان General Responsibility Assignment Software Patterns به معنی «الگوهای نرم افزاری تفویض کلی مسئولیت»، یکی دیگر از مجموعه قوانینی است که تبعیت از آن‌ها می‌تواند در هرچه حرفه تر شدن ما مفید واقع گردد.

به طور خلاصه، هدف از GRASP این است که مسئولیت ها در آبجکت هایی که از روی کلاس‌های مختلف می‌سازیم مشخص گردد. به طول مثال، چه کسی این آبجکت را می سازد؟ چه کسی مسئول ارتباط مابین آبجکت های مختلف است؟ چه کسی مسئول دریافت درخواست های کاربران و تحویل آن‌ها به آبجکت های مختلف است؟ و سؤالات دیگری از این دست.
توجه داشته باشیم که مفاهیم SOLID و GRASP هیچ گونه کانفلیکت یا «مغایرتی» با یکدیگر ندارند. برنامه نویسی که با یک زبان برنامه نویسی شیء گرا کدنویسی می کند، می‌توان SOLID را در کدنویسی رعایت کند، می‌توان GRASP را در پیش گیرد و یا هیچ کدام را! حال می بایست ببینیم که چه قوانینی بر GRASP حاکم‌اند که در ادامه با برخی از مهم‌ترین آن‌ها آشنا خواهیم شد.

Expert
این اصل حاکی از آن است که اگر مسئولیتی در نرم‌افزار وجود دارد که یکی از کلاس‌های نرم‌افزار می بایست آن را بر عهده گیرد، آن مسئولیت را به کلاسی واگذار کنید که نسبت به بقیه توانمندتر است. این کلاس توانمند می بایست آنقدر به سایر کلاس‌ها احاطه داشته باشد که اگر درخواستی مبنی بر انجام کاری را دریافت کرد، بداند که کدام کلاس از عهده ی این کار بر می‌آید -شاید هم خودش از عهده ی آن برآید- و به چه شکل درخواست را می بایست در اختیار آن کلاس قرار دهد. برای روشن‌تر شدن این مسأله، یو ام ال زیر را مد نظر قرار می دهیم:

فرض کنیم که سه آبجکت داریم تحت عناوین Customer, ShoppingCart و Item. حال فرض کنیم که آبجکت مشتری می‌خواهد بداند که تعداد کل محصولات قرار گرفته در سبد خرید چند مورد است. چنین کاری را ما می‌توانیم داخل آبجکت مشتری انجام دهیم چرا که به نوعی دربرگیرنده ی دو آبجکت دیگر است اما واقعیت امر این است که آبجکت سبد خرید است که مسئول واقعی این کار است.

Creator
در اینجا منظور این است که چه کسی مسئول ساخت یک آبجکت است. با توجه به اینکه تعاملات بسیاری مابین آبجکت های مختلف یک نرم‌افزار وجود دارد، درک این موضوع که کدام آبجکت توسط کدام بخش نرم‌افزار ساخته شده است کار نسبتاً دشواری است. در چنین شرایطی کشیدن نمودارهای سلسله مراتبی کلاس‌های نرم‌افزار تاحدودی کمک می کند. آنچه در اینجا حائز اهمیت است این می‌باشد که آیا یک آبجکت دربرگیرنده ی آبجکت دیگری نیز هست؟

Low Coupling / High cohesion
به طور کلی منظور از Low Coupling این است که یک برنامه نویس می بایست تا حد ممکن میزان Dependency یا «وابستگی» مابین آبجکت های مختلف را به حداقل برساند. اگر یک آبجکت نیاز دارد تا به مثلاً پنج آبجکت دیگر وصل شود، برنامه ی ما دارای High Coupling است و این مسأله می‌تواند در آینده مشکل زا گردد. فرض کنیم در آینده یکی از آبجکت هایی که آبجکت ما به آن وابسته است را تغییر می دهیم، از آن لحظه به بعد عمل‌کرد آبجکت ما هم آن طور که انتظار می‌رود درست پیش نخواهد رفت. پس به خاطر داشته باشیم که می بایست تا حد ممکن وابستگی‌ها را به حداقل برسانیم.

علاوه بر این، توجه داشته باشیم که Low Coupling هرگز بدان معنا نیست که ما هیچ گونه وابستگی‌ به سایر آبجکت های برنامه نخواهیم داشت. آبجکت ها نیاز دارند تا اطلاعاتی در مورد یکدیگر داشته باشند اما همواره می بایست تمام تلاش خود را به کار بندیم تا این میزان وابستگی در کمترین حد ممکن نگه داشته شود.

به طور کلی، منظور از cohesion در برنامه نویسی شیء گرا این است که یک کلاس تا چه اندازه مسئولیت های تخصصی و متمرکزی دارد. اگر یک کلاس به‌قدری خوب نوشته شده باشد که صرفاً یک مسئولیت را برعهده گیرد -یا یکسری مسئولیت های مرتبط با هم را بر عهده گیرد- اینجا است که می‌گوییم کلاس دارای High cohesion است. مثلاً کلاس‌های «همه فن حریف» که دارای طیف گسترده ای از وظایف هستند، اصطلاحاً دارای Low cohesion می باشند. در یک کلام، کلاسی که ما می نویسیم می بایست دارای Low Coupling و High cohesion باشد.

Controller
فرض کنیم که قصد کدنویسی یک وب اپلیکیشن را داریم. این وب اپلیکیشن در ساده‌ترین حالت ممکن دارای یک UI یا «رابط کاربری» است که کاربران سایت آن را مشاهده می‌کنند و یک Logic که «منطق» وب اپلیکیشن که مشخص می‌کند در ارتباط با درخواست های مختلف، چه جوابی برای کاربر می بایست ارسال گردد.

در چنین شرایطی اگر ما آبجکت UI را به طور مستقیم درگیر با آبجکت Logic وب اپلیکیشن کنیم، اصطلاحاً High Coupling ایجاد کرده‌ایم که اصلاً خوب نیست و بایستی تمام تلاش خود را به کار بندیم تا این وابستگی را به حداقل برسانیم و اینجا است که پای آبجکت کنترلر به میان می‌آید که به مثابه ی یک واسطه عمل می کند. به عبارت دیگر، درخواست ها را از آبجکت رابط کاربری گرفته و تحویل به آبجکت منطق وب اپلیکیشن می دهد. آبجکت منطق هم پس از تجزیه و تحلیل این درخواست، پاسخی برای آن آماده کرده و تحویل آبجکت کنترلر می‌دهد و کنترلر هم آنرا دو دستی تقدیم به رابط کاربری می کند! چنین چیزی اصطلاحاً MVC نامیده می‌شود که به منزله ی یکی از معروف ترین الگوی های مدرن برنامه نویسی که در فصل بعد به تفصیل در مورد آن صحبت خواهیم کرد.

Pure Fabrication
مواقعی برای ما پیش خواهد آمد که نیاز داریم چیزی در اپلیکیشن خود داشته باشیم lما آن چیز را نمی‌توان به عنوان یک کلاس یا آبجکت تلقی کرد. به عبارت دیگر، مواقعی برای ما در کدنویسی پیش خواهد آمد که Behavior یی داریم که نمی‌توان آن را در قالب یکی از کلاس‌های موجود اپلیکیشن گنجاند. در چنین مواقعی، به جای به زور تحمیل کردن آن Behavior یا «عملکرد» به یک کلاس و بالتبع کاهش دادن cohesion، در عوض ما اقدام به ساخت یک کلاس جدید می کنیم.
درست است که چنین کلاسی در برنامه‌ریزی اولیه ی ما هیچ جایی نداشته اما در شرایط فعلی به آن نیاز داریم، پس آن را خواهیم ساخت!

Indirection
در یک کلام، هدف از Indirection کاهش میزان وابستگی مابین آبجکت های مختلف است. فرض کنیم چهار آبجکت مختلف داریم که برای انجام وظایف شان، نیاز دارند تا با یکدیگر در ارتباط باشند.

آنچه در یو ام ال فوق مشاهده می شود، سطح بالایی از وابستگی مابین آبجکت ها را نشان می‌دهد که اصلاً خوب نیست.

در عوض، همان طور که در یو ال ام فوق مشاهده می شود ما می‌توانیم ارتباط مستقیم مابین آبجکت های مختلف را حذف کرده و یک Indirection Object میان آن‌ها قرار دهیم تا ارتباطات مابین آبجکت ها را مدیریت کند.

Polymorphism
پیش از این هم در مبحث مربوط به شیء گرایی در مورد Polymorphism صحبت کردیم. به طور خلاصه، این مفهوم عبارت است از تغییر رفتار یک کلاس بر اساس نوع داده‌ای که در اختیارش قرار می دهیم.

Protected Variations
این مفهوم مرتبط با شرایطی است که می‌خواهیم مشخص کنیم بروز یک تغییر در سیستم، تا چه حد بخش‌های دیگر سیستم را تحت الشعاع خود قرار می دهد. به عبارت دیگر، می بایست کدنویسی ما بر اساسی صورت گیرد که ایجاد تغییر در سیستم، دارای حداقل کانفلیکت در سایر بخش‌ها گردد. بر همین اساس، ما به عنوان یک برنامه نویس حرفه‌ای می بایست نقاطی از اپلیکیشن که بسیار حساس هستند و همچنین نقاطی که مستعد تغییر هستند را مشخص نموده تا در صورت بروز هرگونه تغییر، بتوانیم سیستم را به راحتی مدیریت کنیم. برای مثال، Encapsulation یکی از راه‌هایی است که از آن طریق می‌توانیم این تضمین را ایجاد کنیم که در صورت بروز هرگونه تغییری در سیستم، حداقل کانفلیکت رخ خواهد داد. به عنوان راه‌کاری دیگر، می‌توان به اینترفیس ها اشاره کرد که ما را ملزم به استفاده از چیزهایی می‌کنند که در آینده منجر به یکپارچکی بیشتر نرم‌افزار خواهند شد. علاوه بر این ها، قانون Open /Closed Principle در SOLID نیز می‌تواند متضمن ایجاد ثبات در نرم افزارهای ما گردد.

دانلود رمان و کتاب های جدید

 

[☾♔TALAYEH_A♔☽]

مقدمه‌ای بر معماری سه لایه نرم افزاری


Model-View-Controller که به اختصار MVC خوانده می‌شود به عنوان یکی از محبوب‌ترین الگوهای کدنویسی وب اپلیکیشن ها در سال‌های اخیر مبدل شده است که به همین خاطر، توصیه می‌کنیم افراد تازه کار یک آشنایی نسبی با این الگو داشته باشند خواه تمایل به برنامه نویسی وب داشته باشند خواه علاقمند به کدنویسی در سایر حوزه ها باشند.

پیش از هر چیز، نیاز به رفع ابهام در رابـ ـطه با یکسری باورهای نادرست در رابـ ـطه با الگوی برنامه نویسی سه لایه یا MVC داریم. خیلی‌ها بر این باورند که ام وی سی یک دیزاین پترن است که این کاملاً اشتباه است! در واقع، ام وی سی یک الگوی معماری طراحی اپلیکیشن است که با دنبال کردن این الگو، به سادگی می‌توان ساختار یک اپلیکیشن، وظایف تک تک بخش‌ها و نحوه ی تعامل بخش‌های مختلف اپلیکیشن را مشخص نمود.

این الگو ابتدا در سال 1979 معرفی شد اما در آن سال‌ها ام وی سی با آنچه امروزه می‌بینیم کاملاً متفاوت بود و مفهوم امروزی ام وی سی اقتباسی است از آنچه در دهه ی هشتاد میلادی وجود داشت. شاید یکی از دلایل محبوبیت این الگوی معماری طراحی سایت را بتوان به دو فریم ورک Struts و Ruby on Rails نسبت داد. این دو فریم ورک بر پایه ی ام وی سی طراحی شده و راه را برای بسیاری از دیگر فریم ورک های زبان‌های برنامه نویسی مختلف باز کردند.

نکته
در دنیای کامپیوتر و نرم افزار، به طور کلی منظور از Framework (فریم ورک به معنی چارچوب) یک زیرساخت برنامه نویسی است که توسط شرکت های بزرگی همچون مایکروسافت، آی بی ام، گوگل و … برای زبان‌های برنامه نویسی مختلف توسعه داده می‌شود که با استفاده از آن می‌توان اقدام به ساخت و توسعه ی اپلیکیشن ها و سرویس های نرم افزاری مختلفی همچون نرم افزارهای دسکتاپ، وب اپلیکیشن، اپلیکیشن موبایل، وب سرویس و … نمود. فریم ورک ها مجموعه‌ای از Class ها و Library هایی هستند که کاملاً انتزاعی بوده و برنامه نویسان بسته به نیاز خود، اقدام به استفاده از آن‌ها می‌کنند و نرم افزارهایی واقعی با آن‌ها می نویسند.
ایده ی پشت الگوی معماری ام وی سی بسیار ساده بوده و می‌توان آن را در قالب موارد زیر بیان نمود:

Model: مدل مسئول مدیریت Business Logic اپلیکیشن است. به طور کلی، منظور از Business Logic کاری است که اپلیکیشن مد نظر ما به آن خاطر طراحی شده است که به نوعی مهم‌ترین بخش از نرم‌افزار است.

View: ویو یا «نمای» اپلیکیشن جایی است که دیتای مختلف در معرض دید کاربران اپلیکیشن قرار می گیرد. به طور مثال، این صفحه از سکان آکادمی که شما ملاحظه می نمایید، بخشی از ویوی وب اپلیکیشن سکان آکادمی است.

Controller: کنترلر همان‌طور که از نامش پیدا است، مسئول کنترل است. به عبارت دیگر، کنترلر درخواست های کاربران را گرفته و بررسی می‌کند ببیند که مسئول پاسخگویی به این درخواست ها کدام بخش از اپلیکیشن است سپس وظیفه ی هر بخش را به آن تفویض می‌کند که یکی از این بخش ها، همواره مدل ها هستند. به طور مثال، مدل هم به بررسی درخواست پرداخته و در صورتی که درخواست درست بود و جوابی داشت، آن جواب را تحویل کنترلر داده و کنترلر هم پاسخ را در اختیار ویو می گذارد.

امروزه اکثر وب اپلیکیشن هایی که با فریم ورک های استاندارد طراحی می‌شوند از این سه لایه برخوردارند لذا آشنایی مفصل با ساختار هر کدام از این لایه ها نیاز به آموزش‌های جداگانه ای دارد که در ادامه ی این فصل، به هر کدام از لایه‌های MVC یک آموزش جداگانه اختصاص خواهیم داد.

دانلود رمان و کتاب های جدید