Interface چیست ؟ 

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

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

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

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

...

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

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

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

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

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

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

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

اما چاره چیه؟ توصیه بودایی ها رو جدی بگیرین «خواستن رنج است». اگر با این دید می رین به یک شرکت که خیلی باشعور باشه، اشتباه میکنین و چیزی رو می خواین که باعث رنج خواهد شد. در مقابل بدونین که وقتی به جایی می رین برای منافع خودتون رفتین (از چیز یاد گرفتن تا سفر رفتن تا حقوق سر ماه تا ...) و به توصیه اولین مدیرخط من آقای شهپر هم گوش بدین: «غر نزنین خودتون رو هم با بقیه مقایسه نکنین. تا لحظه ای که حس می کنین کار کردن در اینجا براتون می‌صرفه اینجا باشین و اگر فکر کردین به نفعتون نیست، برین. خیلی ساده». موقع پیدا کردن شرکت به چیزهایی که واقعا براتون مهمه (مثلا برای من سفر، دوست خوب، محیط کار جالب، رزومه جذاب در آینده و ... مهمتر از حتی حقوق است) توجه کنین و سعی کنین به جایی برین که برای آینده به دردتون بخوره. حس نکنین که بهترین جا رو پیدا کردین و گول زرق و برق سرمایه داری رو نخورین چون پشت ظاهر جذاب بهترین شرکت‌ها، منطق خشک و خشن سود است که کار می کنه.
https://linuxbook.ir/chapters/is_there_a_good_company.html

انتشار دات نت 5 نسخه preview
https://devblogs.microsoft.com/dotnet/announcing-net-5-0-preview-1/

❇️ دو محتوای آموزشی

🔶 سایت Pluralsight بیش از ۷۰۰۰ دوره خودشو رایگان کرد (تا پایان آپریل)
https://www.pluralsight.com/offer/2020/free-april-month

🔷 یه ریپازیتوری تو گیتهاب هست که لیستی از کتابهای رایگان برای زبان های مختلف برنامه نویسی رو گذاشته و من اومدم اوناییش که مرتبط با کارمون هست رو براتون لیست کردم
🔘 .NET Framework
🔘 C Sharp
🔘 ASP.NET
🔘 JavaScript
🔘 TypeScript
🔘 Angular
🔘 React / Redux
🔘 Web Performance
🔘 Security
🔘 SQL Server
🔘 NoSQL
🔘 Bash
🔘 PowerShell
🔘 Professional Development
🔘 Software Architecture
____________________
@DotNetZoom

ویدئو آموزشی کار با کتابخانه سیگنال گو و ساخت یک برنامه console
جهت ارتباطات دوطرفه کلاینت و سرور در سیستم عامل گنو لینوکس

ویدئوی آموزش سیگنالگو در لینوکس که توسط دوست و همکار عزیزم آقای سعید رضایی @mrgrayhat ساخته شده که میتونید توسط این آموزش یاد بگیرید که توی لینوکس چطوری یک سرور و کلاینت سیگنالگو رو با ویژوال استادیو کد و سیگنالگو کد جنریتور بسازید.

https://www.youtube.com/watch?v=WzbYpTiH2L8

Hey Guys, we started working on a strategic game project (Armageddon)
in my GitHub: https://github.com/mrgrayhat/ArmageddonGame

We are currently writing the core structure of the game. ant it's test's.
In the next, we will write the Console & Unity version of the Game (2D/3D).
We welcome your comments / idea's.🤙🏻🙏🏾

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

Publisher 2.1.4 Released (LTS)
Change Log:

* File Manager:
- Fixed Upload Edited file bug to Server.
* Access Control:
- Add Setting Ability to select the authentication step by the user.
By Default, Authentication is asked at the beginning of the command queue execution for easy to use.
You can disable it, in which case you will be asked whenever the command reaches and need the authentication stage.
Change it on:
Tools Menu -> Publisher Settings -> Command's Settings -> Authenticate At First

- Added Master Password For Publisher & Access Control Module.
You can activate Auto Access Control by the toggle button in the status bar of the program.
Once enabled, you do not need to enter a password to execute commands on protected server's, each time.
Otherwise you have to authenticate every time.
Set Master Password by:
Tools Menu -> Publisher Settings

Some improvements.

Server Manager 1.7 Released! (LTS)
* Important Notes:
- We Fixed some bug's which affected Service Manager And increased CPU consumption. Update for better performance And Stability.
* Fixed Stop Service And Process PIP Bug's while restarting and update. Sometimes it didn't work properly.
- Make Some Background Function's Async And Multithread.
- Added AutoStart Option For Service's. If you don't want an service to automatically start while server manager startup, just uncheck it in server info page and save!
-Some Improvment and Integrated With New Feature's added in Publisher 2.

Note: Update Server Manager To Latest Version To Use Publisher > 2.0 Features.

Publisher 2.1.5 Released (LTS)
Change Log:

* Access Control
- AC Authenticator Bug Fix.
(ask password for non protected server's in command runner)

Add "Empty to remove" and Hint Text param for in input dialog. (to remove stored secret for server's or master password, if you forgot).

The Box
Dusan Katelic

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

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

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


#ابله
#فئودور_داستایفسکی

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

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

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

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

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

از سری مطالب معماری نرم افزار #1
بررسی اجمالی اصول طراحی و چرخه تولید نرم افزار ها

اگر هنرجو یا دانشجوی رشته مهندسی نرم افزار بوده باشید، حتما با رویکرد هایی که در آموزش برنامه نویسی و طراحی نرم افزار استفاده میشه آشنا هستین. اکثر شیوه های آموزشی در دانشگاه ها و آکادمی ها بیشتر جنبه آشنایی و تئوری دارن.
در فاز عملی، نحوه کدنویسی و مبانی پایه هر زبان آموزش داده میشه. مثلا الگوریتم، قواعد زبان c,c++ یا اخیرا c#، ساختمان داده و ازین دست مقوله ها. اگر کمی علمی تر باشه، شاید جنبه های چرخه تولید و نگهداری نرم افزار ها و رویکرد های تخصصی رو هم تا حدی بهش بپردازن. (اما چیزی که ما اکثرا دیدیم فقط یکسری کد و برنامه فاکتوریل و فیبوناچی و ستاره چاپ کن ... بوده)
در درجه اول این شما هستین که باید پیگیر موضوعات مختلف در علوم مهندسی نرم افزار باشین. پروتکل ها، پلتفرم ها، اصول و قواعد زبان های برنامه نویسی، همه در سطوح تئوری و تا حدودی عملی به شما معرفی میشن اما خیلی کمیاب و بعیده که به درون این مباحث هم بپردازن. (به قول استادی ما فقط استارت رو میزنیم، دیگه تهش یکم هل ات میدیم)
تایید حرف من رو میتونین در بین خیلی از دانشجوهای این رشته ببینید. حتی در بین برنامه نویس ها و تحصیل کرده های بازار کار این حوزه، هنوز عده کثیری درک درستی از ساختمان داده، الگوهای طراحی، اصول شئ گرایی و نرم افزار، به درستی ندارند. ضعف سیستم آموزشی ما بر هیچ کس پوشیده نیست، اما ضعف خود ما چی؟ چند درصد دانشجو ها و مهندس ها واقعا به دنبال یادگیری بیشتر و کسب تجربه میرن؟ (مطمئنم دلیل اینکه هی میگفتن رشته کامپیوتر اشباع شده رو الان بهتر درک میکنین، از جک هایی که راجع بهمون میگن که دیگه نگم براتون :D )

یکی از صدها موضوع فوق العاده مهم در علم مهندسی نرم افزار، معماری نرم افزار هست. به رشته های مکانیک، ساختمان و معماری نگاه کنید. صرفا داشتن ابزار و اطلاعات کمک کننده نیست. قبل از ساخت یک ساختمان، ابتدا نقشه منطقه و ساختمان، زیر ساخت ها، امکانات و نیازمندی ها و ... آماده میشه و بعد شروع به ساخت و ساز میکنن. مطمئنا اگر وسط ساخت و ساز به فکر تغییر ابعاد خانه یا رفع ناهماهنگی بین سازه ها و اجزای ساختمان باشین، تمام وقت و سرمایه خودتون و دیگران رو هدر خواهید داد و چه بسا خشت اول رو که کج بزارین، تا آخر کج خواهید رفت!
پس قبل از پلن پیاده سازی، باید بدونید چی نیاز دارین و چطور میخواین انجامش بدین، کدنویسی یک مهارته، فراتر از اون معماری و معماری طراحی هست (منظور دیزاین نیست) . به همین خاطر شما میتونید تنها یک معمار نرم افزار باشید چون خودش تخصص جداگانه ای هست که راحت کسب نمیشه. میتونید فقط یک کدنویس باشید که طبق معماری و خواسته های طراح و مدیر پروژه با سابقه ای پیاده سازی کنید.
طراحی نرم افزار مباحث زیادی داره که من فعلا موضوع معماری های نرم افزار رو مدنظر گرفتم.
*نکته مهم*
مباحث معماری نرم افزار، الگوی معماری نرم افزار و الگوی طراحی نرم افزار، سه مبحث کاملا متفاوت و بنیادی در مهندسی نرم افزار و برنامه نویسی است. گاها این سه مقوله یکسان در نظر گرفته میشن یا با هم اشتباه گرفته میشن. (خیلی جاها هم اصلا مفهوم معماری دیده نمیشه و فقط کدهای متعدد و لایه بندی های زیاد میبینیم بعد میگن معماریمون n-layer یا DDD عه! )
معماری و الگوهای استفاده شده در نرم افزار، پیاده سازی، آینده توسعه و نگهداری و استفاده از نرم افزار رو رقم میزنه. اینکه یک سامانه متشکل از صدها سرویس و هزاران کاربر چطور طراحی و پیاده سازی بشه تاثیر مستقیم در موفقیت تیم شما و محصول شما داره. معماری و تحلیل تکنیکال مناسب، تاثیر زیادی در صرفه جویی هزینه ها و زمان شما و تیم تون داره. همچنین میتونه تضمین کنه که تغییرات و اتفاقات آینده، با مناسب ترین هزینه و زمان به شیوه مشخص و بهینه ای قادر به انجام خواهند بود.
در مطلب بعدی درباره هر سه موضوع نام برده، توضیح میدم.
@csharpfriends #SoftwareEngineering #SoftwareArchitecture #SoftwareLifeCycle

از سری مطالب معماری و مهندسی نرم افزار #2

مفاهیمی در معماری نرم افزار خیلی وقت ها کج فهمیده میشه و در این مطلب سعی میکنم این موضوع رو کمی تشریح کنم.
1. معماری نرم افزار (Software Architecture):
معماری نرم افزار به موضوع شناخت و ترسیم کلیت نرم افزار و شکستن کل به بخش های مختلف، رفتارها و ارتباطاتش با دیگر اجزا مانند سرویس ها و برنامه های خارجی، دیتابیس، سرور ها و زیر ساخت ها می پردازد.
همچنین دید کلی از سامانه های نرم افزاری، شبکه ارتباطات داخلی و خارجی(external)، نگهداری و توسعه نرم افزار ها که ارتباط تنگاتنگی با معماری استفاده شده در نرم افزار ها دارد. به طور ساده تر و خلاصه تعریف معماری نرم افزار رو میتونیم به شکل: نقشه ای برای مدیریت پیچیدگی ها/نیازمندی های سیستم و ایجاد ارتباط و هماهنگی بین بخش های مختلف بیان کرد.

از معروف ترین معماری های نرم افزار، میتوان موارد زیر را نام برد:
معماری یکپارچه یا Monolithic
معماری سرویس گرا/مبتتنی بر سرویس یا SOA
معماری میکروسرویس یا Microservice

2. الگوی معماری نرم افزار (Software Architecture Pattern):
الگوهای معماری نرم افزار، جهت جداسازی منطق و ساختار لایه های مختلف، قابلیت استفاده مجدد و توسعه آنها استفاده میشوند. تعیین پروتکل های ارتباطی و منطق لایه های مختلف مانند لایه Presentation، دیتابیس و دسترسی به داده، سرویس ها و ... از خواص الگوی معماری انتخاب شده ارث میبرند. در واقع آنها روش هایی برای کمک به مشکلات و نیاز های مربوط به طراحی نرم افزار ارائه میدهند.
خیلی ها معماری و الگوی معماری نرم افزار را یکسان تلقی میکنن. در آموزش ها، مقالات و وبسایت ها اغلب یا به اشتباه توضیح داده میشن یا به یکسان. شیوه و روش طراحی نرم افزار، با معماری کل نرم افزار تفاوت دارد. به نما و کلیت معماری ساختمان، ساختار و سازه های داخلی و نحوه ارتباط اجزا مختلف و استفاده اونها فکر کنید. به سیم کشی ها و پیچیدگی های مخفی شده در بین سازه ها و ارتباط دیوارها و ستون ها، نحوه باز شدن درب و پنجره و .. اینها یکسان هستند؟!

برخی از پرکاربرد ترین الگوهای معماری نرم افزار(Architectural Patterns) :
- الگوی سه لایه و چند لایه 3Layer & N-Layer و n-Tire
- الگوی MVC (Model View Controller)
- الگوی MVP (Model View Presenter)
- الگوی MVVM (Model View Viewmodel)

رویکرد طراحی دامنه محور یا Domain Driven Design، به اختصار DDD ( اینجا اوردم چون خیلی با معماری و الگو اشتباه میگیرن)

3. الگوی طراحی نرم افزار (Software Design Pattern):
الگوهای طراحی (Design Patterns)، به شیوه و راه حل های مشکلات رایج در طراحی نرم افزار میپردازند. به عبارت دیگر مجموعه ‌‌ای از بهترین راه‌ حل‌های مشکلات متداول در فرآیند برنامه نویسی نرم ‌افزار را الگوهای طراحی می‌نامند.
الگوهای طراحی جزو معماری‌های نرم افزاری نیستند و فقط شیوه ای صحیح از کدنویسی را ارائه می‌دهند. بنابراین این الگوها فقط در قلمرو کدنویسی ( مخصوصا شی گرا) وارد می‌شوند و مستقل از زبان‌های برنامه نویسی هستند. ( در رابطه با تاریخچه و گروه Gang Of Four معروف به GOF، طبقه بندی کننده و نویسنده اولین کتاب الگوهای طراحی، مطلب جداگانه ای مینویسم)
**هر دیزاین پترن برای اهداف مشخصی ایجاد شده که به برخی از کاربردی ترین ها اشاره میکنم:
1. الگوهای طراحی سازنده(Creational)، به حل مشکلات مربوط به ایجاد اشیا در نرم افزار اشاره میکنند؛ مانند:
- الگوهای سازنده یا Builder، کارخانه یا Factory، یکتا/یگانه یا Singleton،
تزریق وابستگی یا Dependency Injection
2. دسته دیگر معروف به الگوهای طراحی ساختاری(Structural)، به مدیریت ارتباط میان کلاس‌ها و شی‌ها با یکدیگر پرداخته مانند:
- الگوهای فساد یا Facade، مخزن یا Repository، تزئین کننده یا Decorator، آداپتور یا Adapter، پُل یا Bridge، پراکسی یا Proxy
3. دسته دیگری معروف به الگوهای طراحی رفتاری(Behavioral)، به راهکارهای کدنویسی مربوط به تعامل و ارتباط اشیا با یکدیگر میپردازند؛ مانند:
- الگوهای دستور یا Command، واحد کار یا UnitOfWork، واسطه گر یا Mediator، توکن یا Memento

* الگوهای طراحی مزایایی همچون افزایش سرعت توسعه، انعطاف و توسعه پذیری، کاهش خطاها، مشکلات و میزان کدنویسی نرم افزار را به همراه دارند. ( البته کد کمتر همیشه درست یا خوب نیست، کد بیشتر هم همینطور، کد تمیز و ساختار مند انعطاف، مطالعه و توسعه پذیری توسط دیگران رو هم بالا میبره)
در عین حال استفاده نادرست و غلط از آنها نتیجه عکس خواهد داد و میتواند سربار و مشکلات دیگری اضافه کند؛ مانند استفاده های نادرست از الگوهای طراحی ریپازیتوری، تزریق وابستگی و ioc
در ادامه به ترتیب به تشریح 3 مفهوم فوق میپردازم.
@csharpfriends
#SoftwareArchitecture #SoftwareArchitecturePattern #SoftwareDesignPattern

گروه تبادل نظر و پرسش و پاسخ کانال: https://news.1rj.ru/str/csharpfriendsgroup
هر گونه انتقاد، پیشنهاد، مطلب و صحبتی داشتید میتونید با من و بقیه به اشتراک بگذارید، با نام خودتون، ناشناس یا هر شکل دیگه ای. هیچ چیز شخصی نیست و هدف، یادگیری و اشتراک دانش هست. انشالله تحت یک پلتفرم آنلاین در آینده.
اگر دوست داشتید به دیگران هم معرفی کنید.
@csharpfriends

از سری مطالب معماری های نرم افزار #3
در مطلب قبل در رابطه با 3 مفهوم معماری، الگوی معماری و الگوی طراحی در معماری نرم افزار توضیح داده شد. حال به چند نمونه معروف و رایج معماری های نرم افزار (Software Architecture) میپردازیم.

1.1 معماری یکپارچه (Monolithic)
در این معماری همه چیز در یک دید کلی ترسیم و پیاده سازی شده است. یک نرم افزار میتواند شامل ده ها و صد ها بخش (قابلیت/سرویس) باشد؛ که همگی در کنار هم و در یک نرم افزار واحد جای داده شده اند. نرم افزارهای مدیریت محتوا، CRM برخی از مثال های نرم افزار های تجاری یکپارچه اند. این نرم افزار ها قابلیت ها و کارهای زیادی را به صورت واحد انجام میدهند. مثلا ثبت نام و مدیریت کاربران، مدیریت محتوا و دیتابیس، سرویس های ارتباط با مشتریان و پشتیبانی و ...
اینگونه نرم افزار ها معمولا شامل چند بخش میشوند، بانک اطلاعاتی، رابط کاربری و بخش سمت سرور که مدیریت درخواست ها را انجام میدهد و واسطه پردازش داده های بانک اطلاعاتی با رابط کاربری میباشد.

این معماری قدمت زیادی دارد، اگر تجربه کار با سامانه ها و نرم افزار های قدیمی 10 سال پیش رو داشته باشید، بخوبی ساختار و مشکلات نگهداری و توسعه آنها را درک میکنید. هنوز هم بسیاری از سامانه ها و نرم افزار های دولتی و خصوصی بر پایه این معماری و فریم ورک های قدیمی است. دلایل عدم توانایی در ارتقا و توسعه آنها هم کاملا مشخص است. برخی از مزایا و معایب این معماری در زیر آورده شده:
+ مزایا (بیشتر مزایا برای نرم افزار هایی در مقیاس کوچک تا متوسط صادق است) :
* سهولت توسعه و نگهداری در ابتدای کار
* هزینه کم راه اندازی و نگهداری
* دغدغه های کمتر درباره امنیت و محافظت از نرم افزار، به دلیل یکپارچه بودن همه عملیات ها و نظارت بر آنها.
* پرفوورمنس و کارایی بهتر، به دلیل سرعت بالاتر دسترسی به حافظه اشتراکی، نسبت به سرعت پردازش و ارتباطات از طریق شبکه و کانال ها در معماری هایی مثل میکروسرویس.
- معایب:
* مقیاس پذیری و ارتقا: یکی از دشوارترین کارها در این نوع معماری است؛ زیرا همه اجزاء به صورت یک واحد یکتا در کنار هم چیده شده اند و نمیتوان فقط بخش ها و سرویس های خاصی را بیشتر کرد یا ارتقا داد.
* پیچیدگی و عدم انعطاف تکنولوژی ها، توسعه پذیری کم: هر تکنولوژی و کتابخانه ای که در طول توسعه نرم افزار استفاده شده شامل وابستگی ها و بخش های مختلفی هست که توسعه پذیری و انعطاف رو در برابر حذف یا تغییر دادن اونها به شدت کم میکنه. نتیجتا ساختار ها، فریم ورک ها و کتابخانه های استفاده شده در این نرم افزار، به اجبار باید در طول توسعه رعایت شوند؛ درغیر اینصورت کل نرم افزار باید زیر و رو شود (مثلا برای زبان برنامه نویسی یا یک کتابخانه مثل Entity freamework).
* استقرار، عیب یابی و بروزرسانی: در صورتی که بخشی از نرم افزار آپدیت شود و یا به مشکلی در راه اندازی بخورد، کل نرم افزار باید دوباره بروزرسانی و راه اندازی شود.
* پایداری کم، تفکیک پذیری پایین: در صورتی که بخشی از نرم افزار مثلا یک سرویس، منجر به بروز خطا ای در سیستم یا اختلالی در عملکرد نرم افزار شود، ممکن است کل نرم افزار را با مشکل مواجه کند و از کار بیندازد. همچنین پایین بودن امکان تفکیک سطوح مختلف، یا فرضا ماژولی به حافظه بیشتری نیاز داشته باشد و دیگری به پردازنده قوی تری.
* درک سخت تر، به دلیل پیچیدگی و اتصالات سفت بخش های مختلف برنامه در طول روند بزرگ و بزرگ تر شدن آن، به سختی میتوان عملکردی در نرم افزار را پیدا کرد و تغییر داد. علاوه بر آن مطالعه و تحلیل همه کدها به شدت زمان بر خواهد شد.
@csharpfriends
#SoftwareArchitecture #Monolithic