رویکرد برنامه نویسی مدولار. برنامه نویسی مدولار. عنوان و ارتباط ماژول با ماژول

ارسال کار خوب خود در پایگاه دانش ساده است. از فرم زیر استفاده کنید

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

نوشته شده در http://www.allbest.ru/

وزارت علومروسیه

چکیده

"برنامه نویسی مدولار"

مقدمه

در قلب یک زبان برنامه نویسی یک ایده راهنما ایجاد شده است که ناشی از نیازها یا در اکثر اوقات بحران در زمینه برنامه نویسی و توسعه نرم افزار است که تأثیر بسزایی در سبک برنامه نویسی دارد و به رفع این بحران کمک می کند.

برنامه نویسی ماشین گرا همزمان با ایجاد رایانه های الکترونیکی ظاهر شد. در ابتدا ، این برنامه ها در کدهای ماشینی بود ، سپس زبان برنامه نویسی Assembler (Autocode) ظاهر شد ، که نوشتن یک برنامه با کد ماشین را کمی "انسانی" کرد.

برنامه نویسی رویه ای. ایده اصلی این سبک الگوریتم سازی فرآیند حل مسئله و انتخاب بهترین الگوریتم (از نظر مصرف حافظه یا سرعت) است.

برنامه نویسی ساختاری. در اینجا ایده اصلی کاملاً توسط N. Wirth در کتاب "الگوریتم ها + ساختار داده ها \u003d برنامه ها" بیان شده است. این پاسخ به بحران برنامه نویسی بود که از اواسط دهه 60 آغاز شد وقتی که حجم برنامه برنامه منبع از خط 1000 خط عبور کرد. در سال 1971 ، یک الگوریتمی زبان پاسکال و اندکی بعد ، در سال 1972 ، زبان C ..

برنامه نویسی مدولار. در اینجا ایده اصلی مخفی کردن داده ها و رویه ها در واحدهای نرم افزاری مستقل - ماژول ها بود . این ایده ابتدا توسط N. Wirth به زبان الگوریتمی Modula (1975-1975) تحقق یافت ، و سپس توسط سایر زبانهای برنامه نویسی رایج در آن زمان "برداشت" شد. به عنوان مثال ، سیستم های برنامه نویسی شناخته شده توربو pascal و توربو C.

برنامه نویسی شی گرا از اواسط دهه 80 میلادی ، حجم کد منبع از مرز 100000 خط عبور کرده است. لازم بود که یک ترکیب تصادفی از داده ها و الگوریتم ها برای پردازش آنها به یک کل واحد ، بلکه معنایی ایجاد نشود. یعنی ایجاد یک برنامه نویسی مدولار از یک سطح جدید ضروری بود ، وقتی تأکید اصلی بر اتصال معنایی ساختارهای داده و الگوریتمهای پردازش آنها است

طراحی برنامه نویسی ماژول

1. هدفبرنامه نویسی مدولار

هنگام تهیه برنامه های بزرگ ، توصیه می شود بخشی از زیر برنامه ها و منابع دیگر مانند متغیرها ، ثابت ها ، توضیحات نوع ، به صورت جداگانه از برنامه اصلی به عنوان کتابخانه منابع یا ماژول ها جمع آوری و گردآوری شوند.

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

برنامه نویسی مدولار تجسم در روند تهیه برنامه ها از هر دو روش متداول مبارزه با پیچیدگی است: هم تضمین کننده استقلال اجزای سیستم و هم استفاده از ساختارهای سلسله مراتبی. برای اجرای روش اول ، الزامات خاصی تدوین شده است که یک ماژول نرم افزاری باید راضی کند ، یعنی. مشخصات اصلی یک ماژول نرم افزاری "خوب" نشان داده شده است. برای اجرای روش دوم ، از ساختارهای برنامه مدولار شبیه به درخت استفاده می شود (از جمله درختان با شاخه های ذوب شده).

2. اصلیمشخصات ماژول نرم افزار

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

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

از لحاظ عملکردی بادوام است ماژول یک ماژول است که یک عملکرد خاص را انجام می دهد. هنگام اجرای این عملکرد ، چنین ماژول می تواند از ماژول های دیگر استفاده کند. این کلاس از ماژول های نرم افزاری برای استفاده توصیه می شود.

اطلاعات با دوام است ماژول یک ماژول است که چندین عملیات (عملکرد) را در همان ساختار داده (شی اطلاعات) انجام می دهد ، که خارج از این ماژول ناشناخته است. برای هر یک از این عملیات ، چنین ماژول ورودی خود را دارد که فرم دسترسی خاص خود را دارد. چنین کلاس باید به عنوان یک کلاس از ماژول های نرم افزاری با بالاترین میزان قدرت در نظر گرفته شود. یک ماژول اطلاعاتی قوی می تواند ، به عنوان مثال ، یک نوع داده انتزاعی را پیاده سازی کند.

کلاچ ماژول - این یک اندازه گیری از وابستگی آن با توجه به داده های سایر ماژول ها است. با روش انتقال داده مشخص می شود. چسبندگی ماژول ضعیف تر به ماژول های دیگر ، استقلال آن از سایر ماژول ها قوی تر است. برای ارزیابی میزان چسبندگی ، مایرز مجموعه ای مرتب از شش نوع ماژول چسبندگی را ارائه می دهد. بدترین نوع کلاچ ماژول است گرفتن محتوا. این اتصال دو ماژول است که یکی از آنها پیوندهای مستقیمی با محتوای ماژول دیگر (برای مثال ، به ثابت موجود در ماژول دیگر) دارد. چنین اتصال ماژول ها قابل قبول نیست. استفاده از آن نیز توصیه نمی شود گرفتن ناحیه عمومی - این یک دسته از ماژول ها است که چندین ماژول از همان فضای حافظه استفاده می کنند. تنها نوع ماژول اتصال برای استفاده توصیه می شود فن آوری پیشرفته برنامه نویسی است گرفتن پارامتر (جفت شدن با توجه به داده های مایرز) مواردی است که داده ها یا به هنگام دستیابی به عنوان مقادیر پارامترهای آن به یک ماژول منتقل می شوند ، یا در نتیجه تماس آن به ماژول دیگری برای محاسبه برخی از عملکردها است. این نوع اتصال ماژول ها با استفاده از تماس به مراحل (توابع) در زبان های برنامه نویسی اجرا می شود.

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

o اگر این منجر به چسبندگی ضعیف (توصیه نمی شود) ماژول ها شود ، همیشه باید از یک ماژول معمول استفاده کنید.

o ماژول های وابسته به تاریخ فقط در صورت لزوم برای تهیه کشش پارامتری مورد استفاده قرار می گیرند.

o در مشخصات ماژول وابسته به تاریخ ، این وابستگی باید بطور واضح تدوین شود تا بتوان رفتار (اثر اجرای) این ماژول را برای تماسهای بعدی متفاوت با آن پیش بینی کرد.

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

3. طراحیمدول

طراحی ماژولار به فرایند شکسته شدن مشکلات بزرگ به مشکلات زیر باریک و قابل کنترل تر اشاره دارد. اولین مرحله طراحی این است که تصمیم بگیرید مرز بین این مشکلات فرعی کجا باشد.

برای به حداکثر رساندن مزایای استفاده از برنامه نویسی ماژولار ، هر فرعی یا ماژول باید یک ورودی و یک خروجی داشته باشد. در این حالت می توانید به راحتی جریان کنترل موجود در برنامه را ردیابی کنید.

3. 1 تجزیه عملکردی

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

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

3.2 به حداقل رساندن تعداد پارامترهای منتقل شده

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

o آیا این ماژول تلاش کرده است چندین کارکرد را انجام دهد؟ آیا این ماژول به پارامترهای مورد استفاده در بخش هایی که مربوط به این ماژول نیستند نیاز دارد؟ اگر پاسخ این سؤالات مثبت است ، باید مجدداً به بخش بندی بیشتر این ماژول متوسل شوید.

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

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

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

3.3 به حداقل رساندن تعداد تماس های مورد نیاز

یكی از مزایای مهم برنامه نویسی مدولار این است كه یك برنامه سطح پایه اغلب می تواند طراحی شود تا به عنوان دنباله ای از مراحل به نام خوانده شود. این واقعیت ، قابل درک بودن برنامه را افزایش می دهد ، زیرا خواننده می تواند پس از خواندن فقط یک یا دو صفحه کد برنامه ، با جریان اصلی و عملکرد آن آشنا شود. با این وجود ، این ویژگی ممکن است معایبی نیز داشته باشد. یکی از بسیاری از برآوردهای برتر برنامه نویسی آماری نشان می دهد که 90٪ زمان اجرای برنامه های معمولی در 10٪ از کد برنامه صرف شده است. این قابل درک است که اگر این 10٪ شامل تعداد زیادی تماس زنجیره ای باشد ، کل زمان صرف شده برای اجرای برنامه می تواند به یک مانع غیر قابل عبور برای استفاده از این روش تبدیل شود.

زمان اضافی صرف شده برای محاسبه آدرس واقعی در بدنه ماژول می تواند به کندی در اجرای یک ماژول خاص نسبت به یک برنامه خاص کدگذاری شده محدود منجر شود.

نتیجه

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

ماژول مجموعه کاملی از منابع نرم افزاری است که برای استفاده توسط دیگر ماژول ها و برنامه ها در نظر گرفته شده است.

کلیه منابع ماژول به دو گروه تقسیم می شوند: خارجی - که برای استفاده توسط دیگر واحد های نرم افزاری در نظر گرفته شده است و منابع داخلی کار این ماژول.

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

ارسال شده در Allbest.ru

اسناد مشابه

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

چکیده ، اضافه شده در تاریخ 29/2/2016


ویژگی برنامه نویسی مدولار: رویه ها و عملکردها ، ماژول ها و ساختار آنها ، آرایه ها و رشته های باز ، پارامترهای بدون نسخه. راه های انتقال پارامترها به روال ها در Borland Pascal. برنامه نویسی شی گرا

آزمون ، اضافه شده 04/28/2009


جوهر برنامه نویسی با استفاده از محیط Delphi 7 و قابلیت های گرافیکی اساسی آن. ساختار یک ماژول نرم افزاری کاملاً کاملی کامپایل شده و اصول آن. تکنیک های اساسی برای کار با روش های گرافیکی ، ساخت قوس ، دایره و بیضی.

مقاله ترم ، اضافه شده 16 دسامبر 2011


ظاهر اولین رایانه ها و ظهور برنامه نویسی "خودبخود". رویکرد ساختاری به تجزیه سیستمهای پیچیده. توسعه برنامه نویسی مدولار و شی گرا. ویژگی های رویکرد مؤلفه و فناوری های CASE.

ارائه ، اضافه شده 10/14/2013


تاریخچه شکل گیری فناوری برنامه نویسی سنتی. وظایف و موضوع برنامه نویسی ساختاریبه عنوان یکی از بزرگترین پیشرفت های فناوری برنامه نویسی. زیر برنامه ، انواع ساختارهای کنترل. مفهوم برنامه نویسی مدولار.

ارائه ، اضافه شده 05.11.2016


موضوع تحقیق روشهای نوین برای تهیه برنامه هایی از جمله برنامه نویسی شی گرا و طراحی بصری و همچنین برنامه نویسی ساختاری و مدولار است. C ++ یک زبان برنامه نویسی جهانی است. مفاهیم کلیدی.

مقاله ترم ، اضافه شده 10.01.2009


چرا C ++. ظهور و تکامل زبان C ++. مقایسه زبانهای C ++ و C. کارآیی و ساختار. برنامه نویسی رویه ای. برنامه نویسی مدولار. انتزاع داده ها. برنامه نویسی شی گرا برتر C

چکیده ، اضافه شده 03.06.2004


مروری بر فناوری ها و سیستم های سیستم های اطلاعات جغرافیایی. سیستم و طراحی عملکردی یک ماژول نرم افزاری ، توسعه آن با استفاده از محیط های برنامه نویسی Visual C ++ 6.0 ، Qt 3.3.3. امکان سنجی برای این فرآیند.

پایان نامه ، اضافه شده 2013/3/13


طراحی ماژول نرم افزاری در محیط برنامه نویسی Borland Delphi 7.0. طرح های الگوریتم برای حل مشکلات در موضوعات "متغیرها و رشته ها" ، "آرایه ها" ، "کار با پرونده ها" ، "ایجاد انیمیشن". اجرای ماژول نرم افزار ، کد برنامه.

گزارش تمرین اضافه شده در 2014/4/21


طرح سیستم اطلاعات. تجزیه و تحلیل زبانهای برنامه نویسی و راه حل های موجود برای مدیریت یک سیستم مدیریت پایگاه داده توسعه یک ماژول تعامل و ساختار برنامه. ماژول های مجوز و اتصالات پایگاه داده.

در هر حرفه ای ، نه تنها در برنامه نویسی ، در طول پروژه حالت های عاطفی مختلفی را تجربه می کنید:

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

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

مشکل برنامه نویسی کلاسیک

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

به نظر می رسد چشمان شما قبل از تحویل پروژه است ، درست است؟

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

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

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

در این حالت ، مراجعه به ماژول ها مفیدتر است. ماژول یک قطعه کاملاً منطقی است که دارای یک هدف کاربردی خاص است. برای تعامل ماژولها از روشهایی استفاده می شود که اجازه تغییر پارامترها و عملکرد را نمی دهد. مزایای برنامه نویسی مدولار واضح است:

• سرعت بخشیدن به توسعه
• بهبود قابلیت اطمینان
• ساده سازی آزمایش.
• قابل تعویض

برنامه نویسی ماژولار در توسعه گروه بسیار مؤثر است ، جایی که هر کارمند می تواند فقط در جبهه کار خود تمرکز کند و به تصمیمات همکاران خود نگاهی ندارد. با این حال ، در یک رویکرد فردی ، حداقل مزایای فوق را به دست می آورید.

اما نه چندان ساده.

مسائل برنامه نویسی مدولار

ایده استفاده از ماژول ها کد را بسیار ساده نمی کند ؛ مهم است که تعداد اتصالات مستقیم بین آنها را به حداقل برسانید. در اینجا به مفهوم "وارونگی کنترل" (IoC) می رسیم. ساده شده - این یک اصل برنامه نویسی است که در آن اجزای جداگانه کد به همان میزان ممکن از یکدیگر جدا می شوند. یعنی جزئیات یک ماژول نباید در اجرای دیگری تأثیر بگذارد. این با استفاده از رابط ها یا انواع دیگری از نمایش که دسترسی مستقیم به کد مدولار ارائه نمی دهند حاصل می شود.

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

سه برنامه اصلی در برنامه نویسی مدولار وجود دارد:

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

علیرغم اینکه اولین بار اجرای IoC استفاده می شود ، بهتر است از اولین مراحل برنامه نویسی مدولار نیز از دو مورد دیگر استفاده شود. دلیل این امر این است که ایجاد ساده رابط ها فقط دسترسی به ماژول ها را محدود می کند و برای کاهش پیچیدگی کد نیز لازم است تعداد اتصالات را کاهش دهید. رابط هایی که به طور تصادفی به رابط های دیگر پیوند دارند ، فقط کد را پیچیده می کنند.

برای حل این مشکل ، لازم است یک معماری کد تهیه شود. به عنوان یک قاعده ، شبیه به ساختار پرونده های هر برنامه است:

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

1. یک جداسازی عملکردی روشن از کد ارائه دهید. در صورت بروز خطا می توانید به سرعت منبع را تعیین کنید و اصلاحات منجر به بروز خرابی های جدید نمی شود.
2. تعداد پیوندها را به حداقل برسانید. این توسعه را ساده تر می کند و به چندین توسعه دهنده ماژول مختلف می دهد. یا می توانید بدون نگاه کردن به دیگران ، هر بلوک را بطور مستقل توسعه دهید که این باعث صرفه جویی در وقت و تلاش نیز می شود.
3. ایجاد یک سلسله مراتب با میراث عمودی واضح. این باعث افزایش قابلیت اطمینان کد می شود ، زیرا آزمایش ساده تر است و نتایج آن آموزنده تر است.

رعایت اصل مدولار بودن در پروژه های بزرگ باعث صرفه جویی در وقت می شود و اشتیاق شروع نمی شود. علاوه بر این ، در نهایت می توانید روی جالب ترین نکته - اجرای ایده های اصلی در کد تمرکز کنید. اما این دقیقاً همان چیزی است که هرکدام از ما به دنبال برنامه نویسی هستیم.

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

توجه داشته باشید که لازم است بین استفاده از کلمه "ماژول" تفاوت قائل شویم وقتی منظور ما از ساخت نحوی زبانهای برنامه نویسی است (واحد در Object Pascal) و هنگامی که منظور ما از واحد تقسیم یک برنامه بزرگ به بلوک های جداگانه است (که می تواند هم در قالب مراحل و هم در آن اجرا شود). شکل توابع).

استفاده از برنامه نویسی مدولار تست برنامه و تشخیص خطا را ساده می کند. زیرمجموعه\u200cهای وابسته به سخت افزار را می توان به شدت از زیرمجموعه های دیگر جدا کرد ، که این امر باعث افزایش تحرک برنامه های ایجاد شده می شود.

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

اصطلاح "ماژول" در برنامه نویسی در رابطه با معرفی اصول مدولار در ایجاد برنامه ها شروع به استفاده کرد. در دهه 70 ، ماژول به معنای روشی یا عملکردی بود که مطابق با قوانین خاص نوشته شده است. به عنوان مثال ، "ماژول باید ساده ، بسته (مستقل) ، قابل رویت (از 50 تا 100 خط) باشد ، و فقط یک عملکرد این کار را تحقق می دهد ، فقط یک ورودی و تنها یک نقطه خروجی." با این حال ، هیچ الزامات شناخته شده جهانی وجود ندارد و ماژول اغلب به عنوان اندازه گیری هر روش با اندازه 50 خط نامیده می شود.

اول ، خصوصیات اساسی یک ماژول نرم افزاری کم و بیش به روشنی توسط پارناس تدوین شده است: "برای نوشتن یک ماژول ، باید حداقل دانش در مورد متن دیگر کافی باشد." بدین ترتیب! پارناسوس اولین کسی بود که مفهوم پنهان کردن اطلاعات را در برنامه نویسی مطرح کرد.

مطابق تعریف پارناسوس ، ماژول می تواند هر روش (عملکرد) واحد از پایین ترین سطح سلسله مراتب (سطح اجرای) یا بالاترین سطح باشد ، که در آن فقط تماس ها به سایر روشهای ماژول رخ می دهد.

با این وجود ، فقط ساختهای نحوی موجود در زبانهای دهه 70 ، مانند یک رویه و یک عملکرد ، نمی توانند اطلاعاتی پنهان و مطمئن را فراهم کنند ، زیرا تحت تأثیر متغیرهای جهانی قرار دارند ، که رفتار آنها در برنامه های پیچیده اغلب پیش بینی دشوار است. حل این مشکل فقط با ایجاد یک ساختار نحوی جدید امکان پذیر نیست که تحت تأثیر متغیرهای جهانی قرار نگیرد. این طرح ایجاد شده و ماژول نامیده می شود.

ساخت نحوی تخصصی این ماژول برای اولین بار توسط N. Wirth در سال 1975 پیشنهاد شد و در زبان جدید وی ، ماژول گنجانده شده است. در همان سال ، یک آزمایش تجربی از زبان ماژولا انجام شد. پس از چند پردازش ، این زبان جدید سرانجام در سال 1977 اجرا شد و نام Modula-2 را دریافت کرد. پس از آن ، طرح های مشابه ، با برخی تفاوت ها ، در سایر زبان های برنامه نویسی گنجانده شد: پاسکال پلاس (ولزی و بستر ، 1979) ، آدا (1980) ، نسخه توربو پاسکال نسخه 4.0 و موارد دیگر.

در ابتدا فرض بر این بود که در اجرای سیستم های نرم افزاری پیچیده ، باید از ماژول به همراه مراحل و کارکردها به عنوان طرحی استفاده شود که با هم ترکیب شده و به طور قابل اعتماد جزئیات اجرای یک کار خاص را پنهان می کند. با این حال ، زبان Borland (Turbo) Pascal تمام قابلیت های نظری این ماژول را عملی نکرد. به طور خاص ، در این زبان هیچ پشتیبانی از ماژول های داخلی (شبیه به رویه ها و عملکردهای داخلی) وجود ندارد ، واردات (بند استفاده) انعطاف پذیر به اندازه کافی نیست ، که به شما امکان نمی دهد اشیاء را از سایر ماژول ها به صورت انتخابی وارد کنید. این شرایط و همچنین واقعیت این است که با ظهور کامپیوترهای شخصی دایره افراد برنامه نویسی بطور چشمگیری گسترش یافت (و این به طور قابل توجهی باعث کاهش سطح متوسط \u200b\u200bآموزش نظری برنامه نویسان شد) ، که منجر به این واقعیت شد که هنگام تهیه برنامه های کاربردی در این نسخه قبلی Object Pascal ، زبان ماژول ها بطور عمده به عنوان ابزاری برای ایجاد کتابخانه های مشکل از رویه ها و توابع استفاده می شود. و فقط ماهرترین برنامه نویسان از تمام توان ساخت این زبان برای ساخت پروژه های خود استفاده می کردند. در زبان Object Pascal محدودیتهای ذکر شده در مورد اجرای ماژول ها باقیمانده است ، با این وجود به این دلیل که هر شکل در دلفی لزوماً ماژول خاص خود را دارد و الگوریتم های غیر بصری نیز به طور معمول به عنوان ماژول های جداگانه اجرا می شوند ، از طراحی "ماژول" برای هدف اصلی خود استفاده می شد. همه برنامه نویسان فارغ از صلاحیت آنها

محیط دلفی از مفهوم برنامه نویسی مدولار در Object Pascal پشتیبانی خوبی دارد که با استفاده از ماژول ها ، یک شیوه برنامه نویسی مترقی و قابل اعتماد را تحریک می کند ، و از این طریق Delphi و Object Pascal را از دیگر ابزارهای توسعه مدرن برنامه متمایز می کند.

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

یک موضوع نظری دیگری را در رابطه با استفاده از برنامه نویسی مدولار در نظر بگیرید. این سوال مربوط به فرم طراحی ماژولار است.

شکل دادن به ساختار سلسله مراتبی یک پروژه ماژولار ، به شما امکان می دهد روند پیشرفت آن را بهبود بخشید. تعداد ماژول هایی که توسط ماژول به هم متصل می شوند و تعداد ماژول هایی که آن را وصل می کنند ، بر پیچیدگی پروژه تأثیر می گذارد. جردن (Yourdon) تعداد ماژول های متصل از این ماژول ، دامنه یا عرض ماژول های کنترل را نام می برد. همراه با سایز بزرگ ماژول با عرض کنترل بسیار کوچک یا بسیار بزرگ ، نشانه ای از یک طرح ماژول ضعیف است. به طور کلی ، عرض کنترل ماژول نباید بیش از 10 باشد. این عدد با "جادوی" شماره 7 همراه است ، که براساس مفاد روانشناسی ، به ویژه در نظریه "chunking" اطلاعات است. حافظه کوتاه مدت انسان توانایی محدودی در صرفه جویی در "تکه های" اطلاعات دارد. آزمایشات روانشناختی نشان داد که توانایی حافظه کوتاه مدت ما در محدوده 5-11 "قطعه" است (به طور متوسط \u200b\u200b- 7). او به طور همزمان می تواند حدود 7 "قطعه" از اطلاعات را کار کند. وقتی شخصی از این حد فراتر رود ، بیشتر مستعد خطا می شود. سازماندهی مجدد اطلاعات ، به تفکیک قسمت های مناسب ، گامی مهم برای استفاده کارآمد از حافظه کوتاه مدت انسان و برای بهبود مواد قابل فهم است. افراد در بسیاری از شرایط زندگی به طور ناخودآگاه چنین سازماندهی مجدد را انجام می دهند. با این حال ، برنامه نویس می تواند با اجازه آگاهانه اجازه ندادن عرض ماژول های کنترل ، که به طور قابل توجهی از عدد 7 فراتر رفته ، به خود کمک کند.

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

علاوه بر این ، هنگام طراحی سلسله مراتب طبقاتی باید همان اصول را نیز اعمال کرد. به عنوان مثال ، در سلسله مراتب کلاس های از پیش تعریف شده Object Pascal ، فقط دو کلاس ، TObject و Exception ، تعداد کلاس های نزول فوری به طور قابل توجهی بزرگتر از 7 دارند. این را می توان با نقش اساسی جهانی TObject و ماهیت "شمرده شده" کلاس Exception توضیح داد. برای سه کلاس ، این تعداد در محدوده 8-9 است و کلاسهای باقیمانده نیز کمتر از 7 فرزند فوری دارند.

برای کاهش پیچیدگی سیستم نرم افزاری آن را به بسیاری از ماژول های کوچک و بسیار مستقل تجزیه می شود. ماژول یک برنامه بسته است که می توان از هر ماژول دیگری در سیستم فراخوانی کرد. این یک قطعه از متن برنامه است که بلوک ساختاری برای ساختار بدنی سیستم است. به عنوان یک قاعده ، یک ماژول از یک قسمت رابط و یک بخش پیاده سازی تشکیل شده است. ماژول ها را می توان در زبان های مختلف برنامه نویسی توسعه داد و به طور جداگانه گردآوری شد. استقلال بالایی از ماژول های سیستم نرم افزاری را می توان با استفاده از دو روش بهینه سازی بدست آورد: تقویت اتصالات داخلی در هر ماژول و تضعیف رابطه بین آنها. برنامه نویسی مدولار در اوایل دهه 60 پدید آمد. قرن XX . هنگام ایجاد سیستم های نرم افزاری ، مزایای زیر را ارائه می دهد:

• توسعه و پیاده سازی سیستم های نرم افزاری ساده شده است.
• امکان کار همزمان (موازی) مجریان وجود دارد که امکان کاهش زمان لازم برای ایجاد پستهای فرعی را فراهم می آورد.
• پیکربندی و اصلاح PS را ساده می کند.
• نقاط عطف طبیعی زیادی برای نظارت بر پیشرفت پروژه وجود دارد.
• می توانید کتابخانه هایی از رایج ترین برنامه ها ایجاد کنید.
• خواندن و درک برنامه تسهیل می شود.
• آزمایش کامل تر ارائه شده است.
• روش بارگیری آسانتر می شود حافظه دسترسی تصادفی large PS (بازده توزیع برنامه در صفحات هنگام کار در حافظه مجازی بستگی به نحوه تقسیم آن به ماژول ها دارد).

در کنار این مزایا ، معایبی نیز وجود دارد که می تواند منجر به افزایش هزینه سیستم نرم افزاری شود:

• زمان اجرای برنامه ممکن است افزایش یابد.
• اندازه حافظه مورد نیاز ممکن است افزایش یابد.
• ممکن است زمان گردآوری و بارگیری افزایش یابد.
• مشکلات سازماندهی تعامل بین مدولار می تواند کاملاً پیچیده باشد.

ما خصوصیات و ملزومات اصلی ماژول ها را لیست می کنیم.

• 1. نتیجه ماژول از گردآوری جداگانه یا بخشی از نتیجه جمع آوری مشترک است. می توان آن را فعال کرد سیستم عامل یا زیر برنامه ای باشد که توسط ماژول دیگر فراخوانی می شود.
• 2. محتویات ماژول می تواند باشد مراجعه کنید با استفاده از نام خود
• 3. ماژول باید کنترل را برگرداند به کسی که او را صدا می کند.
• 4. ماژول می تواند انجام دادن به ماژول های دیگر
• 5- ماژول باید داشته باشد یک ورودی و یک خروجی. بعضی اوقات ممکن است برنامه ای با ورودی های متعدد کوتاه تر باشد و فضای حافظه کمتری را به خود اختصاص دهد. با این حال ، تجربه برنامه نویسی ماژولار نشان داده است که توسعه دهندگان ترجیح می دهند چندین ماژول مشابه داشته باشند ، اما از چندین ورودی و خروجی در یک ماژول استفاده نکنید. دلیل این امر منحصر به فرد بودن ورودی و خروجی ، جداسازی ماژول را تضمین می کند و نگهداری سیستم نرم افزاری را ساده تر می کند.
• 6. ماژول نسبتا کوچک. اندازه ماژول بر میزان استقلال عناصر برنامه ، سهولت خواندن و تست تأثیر می گذارد. مشخص شد که ماژول های کوچک به شما امکان می دهد برنامه هایی بسازید که اصلاح آنها ساده تر باشد. چنین ماژول ها بیشتر مورد استفاده قرار می گیرند ؛ آنها ارزیابی و مدیریت توسعه را تسهیل می کنند ؛ این برنامه ها را می توان به برنامه نویسان با تجربه و بی تجربه توصیه کرد. می توان با طراحی برنامه به عنوان چندین ماژول بزرگ ، معیارهای مقاومت بالا و حداقل قدرت را برآورده کرد ، اما بعید به نظر می رسد که استقلال بالایی از این طریق حاصل شود. به عنوان یک قاعده ، یک ماژول باید از 10 تا 100 اپراتور زبان سطح بالا (در بعضی از نشریات تا 200) باشد.

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

• 7. ماژول نباید سابقه تماسهای خود را برای کنترل عملکرد خود ذخیره کند. چنین ماژولی نامیده می شود قابل پیش بینی. ماژولی که در تماس های پی در پی اثری از حالات خود را ذخیره می کند قابل پیش بینی نیست. همه ماژول های PS باید قابل پیش بینی باشند ، یعنی نباید هیچ گونه اطلاعاتی را در مورد تماس قبلی ذخیره کند. خطاهای پیچیده ، گریزان و وابسته به زمان در برنامه هایی اتفاق می افتند که سعی می کنند مکرراً از یک ماژول غیرقابل پیش بینی تماس بگیرند.
• 8. ساختار تصمیم گیری در ماژول باید طوری ساماندهی شود که آن دسته از ماژولهایی که مستقیماً تحت تأثیر تصمیم قرار می گیرند در ارتباط با ماژول تصمیم گیری ، تابع (نامیده می شوند) باشند. بنابراین ، معمولاً می توان انتقال پارامترهای نشانگر ویژه که نمایانگر تصمیماتی است که باید اتخاذ شود ، از بین رفت و همچنین تصمیماتی گرفت که بر مدیریت برنامه تأثیر بگذارد و در سطح بالایی از سلسله مراتب برنامه قرار گیرد.
• 9. دسترسی به داده ها را به حداقل برسانید. مقدار داده ای که ماژول می تواند به آنها مراجعه کند باید به حداقل برسد. محرومیت از کنترل در ناحیه عمومی ، داده های خارجی و فرمت گام خوبی در این جهت است. طراح باید سعی کند اطلاعات مربوط به هر ساختار داده خاص یا ثبت در پایگاه داده را در یک ماژول جداگانه (یا یک زیر مجموعه کوچک از ماژول ها) جدا کند ، احتمالاً از طریق ماژول های با دوام اطلاعات.
• 10. رویه های داخلی یک روش داخلی یا زیرروال یک فرعی بسته از نظر جسمی است که در ماژول قرار دارد و آن را صدا می کند. از چنین رویه هایی باید به دلایل مختلف اجتناب شود. جداسازی روش های داخلی برای آزمایش دشوار است ، و نمی توان آنها را از ماژول های دیگری غیر از مواردی که حاوی آنهاست فراخوانی کرد. این با ایده استفاده مجدد سازگار نیست. البته یک گزینه جایگزین نیز وجود دارد - کپی کردن مراحل داخلی را در تمام ماژول های مورد نیاز خود درج کنید. با این حال ، این اغلب منجر به خطا می شود (کپی ها معمولاً "خیلی دقیق نمی شوند") و نگهداری از برنامه را پیچیده می کند ، زیرا هنگامی که رویه تغییر می کند ، باید همه ماژول ها مجدداً جبران شوند.

بعد از اینکه یک تعبیه کننده مبتدی یک LED را چشمک می زند ، مطمئناً تصمیم خواهد گرفت تا چیزی جدی تر بنویسد و او ، مانند هر مبتدی ، فقط یک خواسته خواهد داشت "که همه چیز را سریعتر کند!". در چنین تلاشی برای ادعای خود ، همه چیز را در یک پرونده می نویسد بدون اینکه به ساختار برنامه فکر کند ، اما بعد از مدتی وقتی بخشی از برنامه اجرا می شود ، مشخص خواهد شد که هرچه برنامه بزرگتر شود ، پیدا کردن هرچه سخت تر باشد. این امر او را به این ایده سوق می دهد که برنامه باید ساختاری داشته باشد و او به اینترنت برود تا ببیند که چگونه دیگر جاسوسی ها این مسئله را حل می کنند .پس از مشاهده چگونگی نگاه برنامه های نوشته شده توسط افراد دیگر ، او نتیجه گرفت که این برنامه به پرونده هایی تقسیم شده است واحدهای منطقی کاملی را نمایان کنید ، که بخشی از عملکرد و متغیرها به سربرگ منتقل می شوند و خیلی موارد دیگر. همه موارد فوق تجربه من است ، اما همه مبتدیان به همین روش پیش می روند ، بنابراین من آنچه را که با آن روبرو شدم در اینجا شرح خواهم داد.

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

سوال بعدی که مطرح می شود ، از آنجا که ماژول یک ساختار مستقل است ، می توانیم بگوییم " چیز به خودی خود"، سپس او هیچ ارتباطی با جهان خارج ندارد ، اما این مناسب ما نیست. برای اتصال ماژول ها با دنیای خارج از آن استفاده می شود فایلهای هدر ، هدر / هدر نیز نامیده می شود و آنها یک پسوند دارند .ه. می توانید عنوان را مطابق میل خود نامگذاری کنید ، اما راحت تر است که نام با ماژول مطابقت داشته باشد ، ال سی دی و ds18b20.hهمچنین باید بگویم که همه پرونده های متصل ( #عبارتند از) راحت است که آن را در هدر قرار دهید و آن را فقط در ابتدای ماژول وصل کنید.
وقتی هیچ هدفی وجود نداشت ، شروع lcd.s به این شکل ظاهر می شد
#define F_CPU 8000000UL #includ #عبارتند از
و بعد از ایجاد هدر ، این طور شروع شد
#عبارتند از

اما بعد سؤال دیگری پیش می آید که چه چیزی را می توان در سرصفحه قرار داد؟
لازم است نمونه های اولیه توابع مورد نیاز در سایر ماژول های برنامه در هدر تهیه شود. نمونه اولیه عملکرد فقط تابع را اعلام می کند و حاوی بدنه عملکرد نیست ، اما با نگاه کردن به آن می توانید نام تابع ، کمیت ، نوع آرگومان ها و نوع داده بازگشتی را پیدا کنید.
در پرونده ال سی دی
void lcd_init (باطل)؛ void lcd_write_symbol (نماد برجسته)؛ void lcd_write_string (کاراکتر * خیابان)؛ void lcd_clear (باطل)؛
در پرونده ds18b20.h نمونه های زیر اعلام می شوند:
void ds18b20_init (باطل)؛ uint8_t ds18b20_get_temperature (باطل)؛

در مورد ماکروها ، می توانید ماکروها را مسئول جمع آوری شرطی قرار دهید
# تعریف MAKE_CALIBRATION // عدم اظهار نظر برای کالیبراسیون
و در جایی از کد ساختاری وجود دارد که اگر خط قبلی بدون اعتبار باشد ، اجرا می شود
#ifdef MAKE_CALIBRATION touch_x - \u003d 300؛ touch_x \u003d 240 - touch_x / ((Xmax-Xmin) / 240)؛ touch_y - \u003d 350؛ touch_y \u003d 320 - touch_y / ((Ymax-Ymin) / 320)؛ #endif
همچنین می توانید ماکروهایی تهیه کنید که وظیفه انتخاب پین هایی را که به آنها وصل می شوند ، ایجاد کنند
#define D0 PORTA // بنابراین داده ها در یک اتوبوس 16 بیتی ، #define D7 PORTD // منتقل می شوند برای این مورد از دو پورت استفاده می کنیم

اما در عین حال ، در هدر شما نیازی به قرار دادن موارد موردنیاز در ماژول های دیگر ندارید:

• ماکروها را تایپ کنید
  #define (LCD_PIN & 0X80) بررسی کنید_بازی_فلغ
• متغیرهایی که فقط در داخل ماژول قابل استفاده هستند کلمه کلیدی ایستا
• متغیرهای واجد شرایط بیرونی
• نمونه های اولیه توابع که برای برخی اقدامات واسطه ای لازم هستند ، به عنوان مثال تابعی که یک عدد را به آن ترجمه می کند قالب BCD

اکنون چند کلمه در مورد اتصال هدرها هنگام برنامه ریزی میکروکنترلرها AVR تقریباً در تمام ماژول ها ، یک هدر به کار با پورت های I / O وصل می شود.
#inc avr / io.h
یعنی به هم وصل می شود ال سی دی و در ds18b20.h، اکنون اگر این دو هدر را در پرونده اصلی برنامه وارد کنیم ، آنگاه avr / io.h دو بار وصل می شود ، اگرچه یکی کافی بود. به منظور جلوگیری از بروز چنین شرایطی ، هدر دو بار به استفاده متصل نشد # نگهبانانکه به شرح زیر است
#ifndef _EN CodeER_H_ # تعریف_ENCODER_H_ // به عنوان یک سرصفحه معمولی #endif اجرا کنید
این طراحی به پیش پردازنده اجازه می دهد تا تعیین کند که عنوان قبلی قبلاً در برنامه گنجانده شده است و مجدداً آن را وارد نمی کند. می توانید در این باره اطلاعات بیشتری بخوانید.
همچنین می توانید با استفاده از طراحی تعداد اتصالات پرونده را به یک محدود کنید
#pragma یک بار // به عنوان یک هدر معمولی اجرا کنید
مزیت استفاده # پراگما یک بار بجای # نگهبانان قابل خواندن است
به هر حال ، شما می توانید نه تنها هدرها ، بلکه فایلها را با پسوند وصل کنید .از جانبدر صورت لزوم
# شامل "font.c"
در این حالت ، یک فونت برای نمایش حروف روی صفحه TFT متصل می شود.
این همه ، به نظر من این حداقل است که هر برنامه نویس میکروکنترلر تازه کار باید بداند.