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

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

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

هدف های معماری :

در اینجا هدف های متنوعی از معماری وجود دارد ،

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

در اینجا اهداف متنوعی وجود دارد که با طراحی مناسب و خوب قابل دسترسی هستند .

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

• جدایی از نگرانی-Separation of Concern:
Separation Cencern چیزی نیست جز سبک اجرای کد یا کار منطقی که مناسب تر است که این دو با هم ادغام شوند ، این بدان معناست که کلید های منطقی بهتر است در لایه های جداگانه یا درون فایلی از طراحی واسط کاربری باشند .

• مسئولیت تنها - Single Responsibility : 
همانطور که از نامش پیداست ، هر معیار یا عنصر بهتره مسئول یک و فقط یک کار باشند .

• حداقل دانش - Least Knowledge :
بدان معنیست که یک عنصر نباید از جزئیات عناصر دیگر خبر داشته باشند .

• تکرار نکردن - Do not Repeat :
این بدان معناست که توابع مختلف در مولفه های مختلف تکرار شوند . یک تابع فقط باید در یک مولفه استفاده شود 

• به حداقل رساندن طراحی - Minimize the Design :
تنها طراحی است که برای برنامه اجباریست و سعی در استفاده مجدد از چیزی که وجود دارد نکنید . تا جایی ای که ممکن است از مولفه های reuseable استفاده کنید . این در بهبود زمان و رفع باگ هایی از برنامه براحتی برنامه را به زمین میزنند ، موثر هستند . 

ایده اصلی این طراحی ها پنهان کردن پیچیدگی ماژول ها بوسیله تقسیم Solution بر اساس مولفه ها و استفاده از مولفه های reuseable یا توابعی است که ممکن است در طول برنامه بارها از آنها استفاده شوند . برای مثال ، قسمت های مختلف را Concern را در مولفه های مختلف نظیر Data Access, Business Logic, Exception Handling Mechanism, Email یا  SMS handling, File Operation, Services ، توزیع کنید . 

تمرین های طراحی - Design Practices

اگر ما به سطح بالا به معماری Solution ها نگاهی بیانداریم ، ایده هایی میرسد که ، عملی شدن آنها مفید میباشد :

• تمرین کردن -- Practice :
در توسعه نرم افزار ، تمرین چیزی نیست جز یک راه کُلی از شیوه کدنویسی یا چگونگی نوشتن کدی که قرار نیست در قسمت های دیگر Solution ما تکرار شود ، یا استفاده از ظرفیت های برنامه نویسی شی گرا . در اینجا ایده های بسیاری وجود دارد که تمرین خوبی در طراحی محسوب میشوند . 

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

• لایه های برنامه -- Application Layer :
درباره ی اینکه قصد توسعه کدام مولفه را در Solution دارید و در مورد طبقه بندی کردن آنها در لایه ها دقیق باشید ، که این امر به ما در پیاده سازی تئوری مشخصی که به دنبال آن هستیم کمک میکند . 

- استفاده از domain model و object برای ارسال و دریافت داده از لایه هر وقت که نیاز بود 
- بر اساس عملکرد مولفه ها ، آنها را در لایه های مختلف نظیر Data Access, Business Logic, Helper یا Utility یا Common, Domain, Service تقسیم میکنیم . 
-همیشه از abstraction برای حاصل شدن توسعه مولفه های loosely coupled استفاده میکنیم . 


• مولفه ها -- Components :
Componentها  نباید وابسته به جزئیات مولفه های دیگر باشند و ارتباط هر مولفه در باره چگونگی ایجاد ارتباط با مولفه های دیگر باید کاملا مشخص باشد . 

تعریف یک قرارداد برای هر مولفه در مورد تواناییِ چگونگی پردازش یک مولفه با عملکرد مولفه ، ماژول یا تابع ؛ و رفتار این عملکرد در جریان اجرا .

• کیفیت سیستم -- System Quality :
کیفیت مولفه ها یکی از جنبه های کلیدی برای توسعه نرم افزار برای مواجه با کارآمد بودنِ نیازمندی های کاربر است . برای انجام unit test برای هر توسعه به منظور اطمینان از درست کار کردن تیکه کد میتوانید از یک سیستم تست کردن دقیق استفاده کنید یا هر سیستم تست کننده دیگر . از ابزار های  automated QA در حین توسعه برای اطمینان از اینکه داده های عملیاتیِ درستی توسط مولفه های برنامه شما و sub-systemها فراهم آورده شده است ، استفاده کنید .

زمان ایجاد معماری -- When to Create Architecture :

معماری ها در فاز طراحی یا زود تر در توسعه یک سیستم ایجاد می‌شوند . اگر شما از یک پردازش توسعه آبشاری (waterfall development process) استفاده میکنید ، برای مثال ، ایجاد معماری یکی از ابتدایی ترین کارهایی است که شما انجام میدهید . شما مشکل را تعریف میکنید و سپس آن را بوسیله یک معماری حل میکنید . اگر ، به جای آن ، شما از یک پردازش توسعه برنامه مکرر (iterative software development process) نظیر Unified Process یا agile استفاده میکنید ، این معماری اساسا شامل تکرار های زود و موازی با طراحی سطح پایین و کدهای اسان میباشد . زمانی که تکرار توسعه معماری کامل شد ، مراحل دیگر نظیر طراحی و کدنویسی میتوانند آغاز شوند . 

الگو --- Pattern :

Pattern یک ایده  می‌باشد که در یک شرایط تجربی و شاید شرایط دیگر میتواند مفید و کارآمد باشد .  Pattern میتواند به دو دسته Architectural Pattern و  Design Pattern دسته بندی میشوند :

1. Architectural Pattern :
Architectural Pattern ساختار فیزیکی و منطقی یک Solution را در بالاترین سطح تعریف میکند . Architectural Pattern به تمام قسمت های سیستم که توسط Pattern برای استفاده در طراحی آن استفاده شده است ، نیاز دارد . این به دسته های مختلفی میتواند تقسیم شود :

• Client/Server :
توزیع سیستم در دو برنامه ، که در آن Client در خواستی را به Server ارسال میکند . در اکثرا موارد ، سرور یک پایگاه داده یا هر برنامه خدمت گذاری است که تحت عنوان Server میباشد . 

• Component-Based :
تقسیم طراحی و منطق برنامه به توابع یا مولفه های منطقی reuseable برای در معرض گذاشتن مشخصه ها و متدهای well-defined برای داشتن کنش و واکنش با مولفه ها نظیر Grid, Button, Data Adapter و ...

• Domain Driven Design :
Domain Driven Design یک رویکرد OPPS برای طراحی برنامه نرم افزاری بوسیله  مدل سازی یک business domain و تعریف business Objectها بر مبنای Entity ها ، می‌باشد . 

• معماری لایه ای -- Layered Architecture :
تقسیم بندی concernهای یک برنامه در لایه ها و مستقر کردن آنها در یک کامپیوتر .

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

• N-Tier / 3-Tier :
توابع را در قسمتهای مختلف توزیع میکند ، هر کدام از این قسمت ها یک Tier هستند که در سیستم های جدا از هم مستقر شده اند . 

• Object-Oriented :
طراحی object-oriented یک پردازش از ایجاد اشیا self-sufficient دارای یک مجموعه از Property ها و methodها است که با منطق و عملکرد مشخصی از برنامه سر و کار دارد و همچنین میتواند شامل مجموعه ای از داده ها برای قسمتی از عملکردش باشد . 

• (Service-Oriented Architecture (SOA :
SOA چیزی نیست جز ، زمانی که یک برنامه سرویس هایی را برای برنامه های مستقل از هرگونه platform یا technology فراهم می‌آورد که با استفاده از قرار دادها و پیام ها ،  عملکرد را تحت عنوان یک سرویس فرض میکند . 

2. Design Pattern :

Design Pattern چیزی نیست جز یک پردازش یا روش تحلیل برای تایید یا پیاده سازی یک معماری خوب در یک Solution . به عبارت دیگر ، Design Pattern زیر مجموعه ای از معماری است که ما برای جلوگیری از بروز یکسری مشکلات شناخته شده در توسعه برنامه که باعث کاهش زمان maintainability میشود ، یکسری الگوهای برنامه نویسی را دنبال می‌کنیم . 

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



Design Pattern را با مفاهیم زیر اشتباه نگیرید !
- Patternها Framework نیستند 
- Pattern یک حلّال مشکلات جامع نیستند 
- Pattern یک الگوریتم نیست 
- Pattern فقط ویژه OOPS نیست 

Design Pattern خود را ایجاد کنید :

ایجاد Design Pattern کار زیاد سخت و دشواری نیست اما شما نیاز به یک ایده برای حل یک مشکل را دارید ، بهترین راه حل برای حل یک مشکل .  سپس آن را بازبینی کنید ، آن را مستند کنید ، سپس آن را منتشر کنید . 

قوانین سه گانه : 
هر Solution میتواند یک Design Pattern باشد در صورتی که قوانین سه گانه را تصدیق کند ، که این بدین معناست که یک چیز باید حداقل سه بار برای حل موفقیت آمیز یک مشکل یکسان استفاده شود تا بتوان آن را یک 
 Design Pattern به حساب آورد . 

انواع Design Pattern :
در اینجا سه دسته از Design Pattern وجود دارد که میتواند برای هر نیازی مورد استفاده قرار بگیرد و آنها عبارتند از : 

- Creational Patterns :

 این Pattern مکانیزمی را برای ایجاد اشیا یک کلاس بصورت کارآمد تر را فراهم میآورد :

• Factory :
Factory Pattern اشیا را بدون شرح دادن منطق ایجاد آن برای کاربر ، ایجاد میکند و یا استفاده از یک inteface معمولی به اشیا جدید ایجاد شدده ارجاع می‌کند . 

• Abstract Factory :
Abstract Factory چیزی نیست جز یک Factory از Factoryها ، که اشیا Factory  را بر مبنای Interface بدون مشخص کردن صریح کلاس ، ایجاد می‌کند .هر Factort تولید شده میتواند تحت عنوان Factory Pattern به اشیا داده شود .

•  Builder :
بصورت مرحله به مرحله با استفاده از اشیا ساده اشیایی پیچیده را Build میکند . 

• Prototype :
با استفاده از cloning (همتا سازی) به ما امکان ایجاد اشیا همتا (duplicate objects) را میدهد . این زمانی موثر است که ایجاد یک شی بسیار پر هزینه است . 

• Singleton :
در این Pattern  فقط کلاس های واحد - single classes - فقط یک شی را ایجاد و شامل میشوند . 

-  الگوهای ساختاری -- Structural Patterns :
این الگو مکانیزمی را برای سرو کار داشتن با رابطه های مختلف entityها با یک روش ساده تر ، فراهم می‌آورد . 

• Adapter :
این الگو چیزی شبیه یک پل میان دو Interface مستقل است که یک کلاس عملکرد این دو Interface مستقل را به هم متصل می‌کند . 

• Bridge :
Bridge Pattern یک abstraction  را از پیاده سازی آن جدا میکند ، پس با این وجود این دو قسمت بصورت مستقل و جدا از هم میتوانند کار کنند . 

• Composite :
الگوی طراحی مختلط  (Composite design patterns) برای ارائه قسمتی ، به خوبی ارائه تمام سلسه مراتب ، یک درخت ساختار را تشکیل میدهد . این الگو یک کلاس ایجاد میکند که گروهی از اشیا خودش را نگه میدارد و راهی برای گسترش و ویرایش این اشیاه فراهم می‌آورد .

 • Decorator :
این یک نوع از پیاده سازی کلاس wrapper است که بدون ایجاد تغییر در جریان ،  این امکان را به کاربر میدهد که یک عملکرد جدید را به شی اضافه کند ، این الگو با یک کلاس موجود همانند یک wrapper عمل میکند . wrap class ، پیاده سازی اصلی کلاس را محصور و احاطه میکنند و ویژگی های دیگر را برای کلاس فراهم می‌آورند .

 • Façade :
این Pattern پیچیدگی های داخلی یک سیستم را پنهان میکند و برای سر و کار داشتن با sub systemهای مختلف یک متد ساده را فراهم می‌آورد . این الگو یک کلاس Single دارد و ان متد delegateهای مختلف را برای متدهای کلاس های مختلف فراهم می‌آورد . 

• Flyweight :
 این یک factory pattern است که برای کاهش تعداد اشیا ایجاد شده ،دارای یک حافظه داخلی است . قبل از ایجاد یک شی بررسی میکند که اگر یک شی ازین نوع وجود داشته باشد ، آن را به همان ارجاع میدهد . 


- الگو های رفتاری -- Behavioral Patterns :

این الگو مکانیزمی را برای ارتباط entity ها با هم ، ارائه میدهد .

• زنجیره مسئولیت -- Chain of Responsibility :

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

• دستور --Command:

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

• مترجم -- Interpreter:
این الگو راهی برای ارزیابی زبان یا expression فراهم می آورد . این برای تجزیه برخی Syntax ها و Expression ها مفید هستند . 

• مکرر -- Iterator :
Iterator pattern یک راه برای پیاده سازی کلاس های Iterator که اشیا را از یک آرایه مجموعه بدون دانستن جزئیات اساسی ، باز میگرداند 

• میانجی -- Mediator :
پیچیدگی ارتباطات بین اشیا  چندگانه یا کلاس ها را کاهش میدهد . جایی که کلاس ها بصورت مستقیم با هم در ارتباط نیستند .  کلاس میانجی همه ارتباطات بین کلاس های مختلف را مدیریت می کند. 

• Memento:

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

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

•  وضعیت -- State :
این الگو ، رفتار کلاس را بر اساس حالت آن تغییر می دهد. روش کار به این صورت است که یک شی ایجاد می کند که حالات مختلف را نمایش می دهد  و یک شی context  که رفتار آن ، بر اساس رفتار شی ، تغیر می کند.

• راهبرد --Strategy:

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

• Template Method:

این الگو یک کلاس abstract تعریف می کند و یک متد ایجاد می کند که مجموعه ای از متدها را در یک روش تعریف شده، اجرا می کند. 

• Visitor:

این الگو یک عملیات بر روی یک مولفه از ساختار شی اجرا می کند و همچنین یک عملیات جدید بدون تغییر سلسله مراتب کلاس تعریف می کند.بنابراین با این روش، تعداد عملیات ها می تواند همزمان با تغییر تعداد visitor ها تغییر کند. 

آموزش سی شارپ