الگوی طراحی Decorator :

فروشگاهی را در نظر بگیرید که دارای کالاهای متعدد کادویی و همچنین انواع زیادی از جعبه‌های تزئینی و وسایل برای تزئین کالاهای مختلف می‌باشد . در این فروشگاه قصد داریم سیستمی طراحی کنیم که این قابلیت را داشته ‌باشد که قیمت کل را برای یک کالا با سایر وسایل تزئینی محاسبه کند . یک طراحی برای این مسئله می تواند به صورت زیر باشد که اگر مشتری یک هدیه را بدون هیچ کالای تزئینی دیگر خرید ، یک نمونه از خود آن کلاس ایجاد شود و قیمت آن توسط متد قیمت برگشت داده شود . اگر یک هدیه نوع یک با جعبه یک خریداری شود ، نمونه‌ای از هدیه نوع 1 با جعبه نوع 1 ایجاد شود ، و قیمت کل خرید برگشت داده شود . اما در این حالت ، اگر فروشگاه دارای ده‌ها هدیه و جعبه‌های مختلف باشد و بخواهیم هر کدام از ترکیب‌های ممکن را به‌صورت یک کلاس جداگانه تعریف کنیم ، برای یک کار ساده شاید صدها کلاس داشته باشید که بی‌شک مدیریت و تغییر در هر کدام از کلاس‌ها، هزینه زیادی را در بر خواهد داشت .
طراحی‌های مختلفی را می‌توان برای مسئله بالا ارائه داد . اما یک طراحی و راه‌حل خوب الگوی Decorator است.
در مثال بالا ، می‌خواهیم یک رفتار جدید را به یک شی اضافه کنیم . ولی می‌خواهیم بدون استفاده از وراثت این رفتار را به آن اضافه کنیم . این الگو اجازه می‌دهد ، تا یک رفتار را بدون استفاده از وراثت و به‌صورت دینامیک به یک شی اضافه کنیم .
این الگو که در طبقه‌بندی الگوهای ساختاری جای دارد ، یک سری از ویژگی‌های مهم کلاس را توسعه می‌دهد . به عبارت دیگر الگوی Decorator این امکان را فراهم می‌آورد که علاوه‌بر تغییر متدهای موجود ، می‌توان متدهای جدید در زمان اجرا اضافه نمود .
در شکل مربوطه کلاس دیاگرام مربوط به این الگو نمایش داده شده و در زیر آن شرکت‌کنندگان در آن و نقش هریک بیان شده است .
بنابر گفته GoF هدف از الگوي Decorator عبارت است از :

افزودن مسئوليت‌هاي جديد به يك شي به صورت پويا . Decorator ها راه‌هـاي جـايگزين قابل انعطافی را براي توسعه عملكرد سيستم تهيه مي‌كنند .

🍃💐🍃🌸🍃🌸🍃
➖➖➖➖➖➖➖➖➖➖
🆑 → @segmenttt🔰
➖➖➖➖➖➖➖➖➖➖
👁‍🗨با فوروارد کردن پست های چنل از ما حمایت کنید 👁‍🗨

‍ ✅ انجام کارهای مهم ویندوز فقط با استفاده از یک اسکریپت


🍃💐🍃🌸🍃🌸🍃
➖➖➖➖➖➖➖➖➖➖
🆑 → @segmenttt🔰
➖➖➖➖➖➖➖➖➖➖
👁‍🗨با فوروارد کردن پست های چنل از ما حمایت کنید 👁‍🗨

گزارشی از یک تجربه موفق :

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

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

از دید مدیر و اعضای تیم استقرارتنها یک عملیات جمع آوری داده قرار بود با سیستم انجام شود.

تصمیم گیری های زیر را به عنوان چارچوب کاری انجام دادیم:

1- هر هفته یک نسخه از سیستم را انتشار خواهیم داد.

2- هر هفته تنها در باره با اولویت ترین نیازهای هفته پیش رو صحبت خواهیم کرد و آنها را انجام خواهیم داد

3- به اندازه ظرفیت کاری تیم یعنی چیزی نزدیک به 40 ساعت نفر در هفته کار برای انجام برداشته می شود

4- لایه سرویس سیستم تست های اتوماتیک داشته باشد.و سرویسی بدون تست پذیرفته نسیت.

5- Build انوماتیک در پروژه وجود داشته باشد.

هفته اول:

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

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

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

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

هفته دوم:

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

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

کارها مانند هفته قبل انجام و جلسه تحویل بر گذار شد.

هفته سوم:

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

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

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

انتهای هفته بخشی از کار پشتیبانی Offline انجام شده بود. در این هفته نسخه قابل ارائه ای وجود نداشت چرا که نتوانسته بودیم ویژگی مورد نظر را کامل کنیم.

هفته چهارم:

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

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

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

کارهایی که ار زمان رها کردن این بخش باقی مانده بود را با برداشتن کارهای جدید به نحوی که زمان تیم را پر کند برداشتیم، اتفاق جدید بیماری یکی از اعضای تیم و عدم حضور 4 روزه او بود.


🍃💐🍃🌸🍃🌸🍃
➖➖➖➖➖➖➖➖➖➖
🆑 → @segmenttt🔰
➖➖➖➖➖➖➖➖➖➖
👁‍🗨با فوروارد کردن پست های چنل از ما حمایت کنید 👁‍🗨

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

هفته پنجم:

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

مدت زمانی که تیم در این هفته برای پروژه گذاشت بیش از 40 ساعت توافق شده در هفته بود.چیزی نزدیک به 80 ساعت. کارهای عقب افتاده طی این هفته انجام شد.

هفته ششم:

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

در پایان هفته سیستم با قابلیتهای توافق شده به تیم بهره بردار تحویل شد.

پروژه انجام شد هم با رضایت مشتری هم خوشحالی تیم توسعه

🍃💐🍃🌸🍃🌸🍃
➖➖➖➖➖➖➖➖➖➖
🆑 → @segmenttt🔰
➖➖➖➖➖➖➖➖➖➖
👁‍🗨با فوروارد کردن پست های چنل از ما حمایت کنید 👁‍🗨

✅ ربات های تبدیل فایل به لینک:

🔹@FileToLinkTGbot
🔹@FileStreamingBot
🔹@PublicDownloadLinkBot
🔹@FilesToIinkBot
🔹@FiletoLinkTelegramBot
🔹@DirectLinkGeneratorBot
🔹@uploadgrammebot

🆕 ربات های تبدیل لینک به فایل:

🔸@UloaditV2Bot
🔸@urluploadxbot
🔸@uploadbot

🍃💐🍃🌸🍃🌸🍃
➖➖➖➖➖➖➖➖➖➖
🆑 → @segmenttt🔰
➖➖➖➖➖➖➖➖➖➖
👁‍🗨با فوروارد کردن پست های چنل از ما حمایت کنید 👁‍🗨

نقش کلاس‌ها :
• Component :
ارائه واسط برای اشیایی که می‌خواهند وظایفی در زمان اجرا به آن‌ها اضافه گردد .

• ConcreteComponent :
شی‌ای که می‌خواهد وظایفی به آن اضافه گردد .

• Decorator :
اشاره به شی Component و ارائه واسط برای مطابقت داشتن با Component Interface .

• ConcreteDecorator :
اضافه کردن وظایف به Component


🍃💐🍃🌸🍃🌸🍃
➖➖➖➖➖➖➖➖➖➖
🆑 → @segmenttt🔰
➖➖➖➖➖➖➖➖➖➖
👁‍🗨با فوروارد کردن پست های چنل از ما حمایت کنید 👁‍🗨

‍ #دانستنی
✅قابلیت‌های عجیب آیفون که نمی‌دونستین وجود دارن!

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

برای همین توی ویدیو امروز قراره بهتون ۱۴ تا ترفند از گوشی‌های #آیفون یاد بدیم که خیلی کاربردی و هیجان‌انگیزن.


🍃💐🍃🌸🍃🌸🍃
➖➖➖➖➖➖➖➖➖➖
🆑 → @segmenttt🔰
➖➖➖➖➖➖➖➖➖➖
👁‍🗨با فوروارد کردن پست های چنل از ما حمایت کنید 👁‍🗨

دیگر ویژگی‌های کلیدی :

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

🍃💐🍃🌸🍃🌸🍃
➖➖➖➖➖➖➖➖➖➖
🆑 → @segmenttt🔰
➖➖➖➖➖➖➖➖➖➖
👁‍🗨با فوروارد کردن پست های چنل از ما حمایت کنید 👁‍🗨

#آموزش
فرق cache و Data چیه؟
✅حافظه ی cache حافظه ای موقته که واسه همیشه تو دستگاهتون نمی‌مونه مثلا اگه برید تو یه سایتی و بعد اینترنتتون رو خاموش کنید میبیند بعضی از عکس ها هنوز بازه و میتونید ببینید در واقع این عکس‌ها در کش یا حافظه موقت شما ذخیره شده. 🔰
حالا دیتا چیه؟🧐
حتما شنیدید که میگن فلان برنامه دیتا داره و باید دانلود کنی.
دیتا فایل‌ها ی یه برنامه‌س که اگه نباشه خوب کار نمی کنه یا اصلا کار نمیکنه.
مثلا تو یه بازی یه سال زحمت میکشی بعدش دیتا رو پاک کنی دوباره میفتی مرحله اول!

📌اگه تو یه جمله فرقشونو خلاصه کنم باید بگم اگه کش رو پاک کنی اتفاقی نمیفته ولی اگه دیتا رو پاک کنی برنامه یا مشکل پیدا میکنه یا مثل مثال بالا هرچی رشته بودید پنبه میشه.
📌یه وقتایی لازمه که دیتای برنامه رو پاک کنید که برنامه درست کار کنه.
📌البته با حذف کردن برنامه دیتا هم پاک میشه

چجوری دیتا و کش رو پاک کنیم؟
✅برید تویه تنظیمات بعد قسمت برنامه ها بعد برنامه ی موردنظرو باز کنید میتونید دیتا و کش رو ببینید(حجمشون) و همونجا هم میتونید پاکش کنید.

🍃💐🍃🌸🍃🌸🍃
➖➖➖➖➖➖➖➖➖➖
🆑 → @segmenttt🔰
➖➖➖➖➖➖➖➖➖➖
👁‍🗨با فوروارد کردن پست های چنل از ما حمایت کنید 👁‍🗨

✅ تفاوت بین کلاسهای Abstract و Interface✅

1- یک کلاس معمولی می تواند از یک کلاس Abstract ارث بری کند ولی همان کلاس میتواند از چندین Interface ارث ببرد .
2- یک Interface فقط میتواند اعلان متدها و خصوصیتها را داشته باشد اما یک کلاس Abstract علاوه بر آنها میتوانید متدها و خصوصیتهایی با کدهای کامل داشته باشد .
3- عناصر موجود در کلاس Abstract میتوانند مانند یک کلاس معمولی دارای سطح دسترسی باشند ولی Interface ها فاقد این امکان می باشند .
4- وقتی شما متدی را به کلاس Abstract اضافه می کنید ، به طور خودکار به همه زیر کلاسها اعمال می شود اما در Interface اگر متدی اضافه کنید باید در تمام زیر کلاسها آن را اعمال کنید .
5- کلاس Abstract مانند کلاسهای معمولی می توانند دارای فیلد و عناصر دیگری (مثل ثابت ها)باشند در حالی که Interface فاقد این امکان می باشد . همچنین کلاس abstract میتواند شامل سازنده باشد اما اینترفیس نمیتواند.
6- کلاس Abstract یکی از انواع کلاس است ولی Interface کلاس نیست .
7- اینترفیس تنها میتواند از اینترفیس ارث بری کند اما کلاس abstract میتواند از اینتر فیس ، کلاس Abstract یا سایر کلاس ها ارث بری کند.
👌👌چه زمانی از Interface ها یا کلاسهای Abstract استفاده کنیم ؟
با توجه به توضیحات ذکر شده مواقعی که نیاز به وراثت چند گانه داریم باید از Interface استفاده کنیم ، به دلیل اینکه این امکان در کلاس های Abstract وجود ندارد .
زمانی که بخواهیم تمام متدهای معرفی شده در کلاس پایه به طور کامل در کلاس مشتق شده پیاده شود باید از Interface استفاده کنیم.
وقتی در پروژه های بزرگ با تغییرات زیادی مواجه هستیم استفاده از کلاس Abstract توصیه می شود چون با تغییر آن به طور خودکار تغییرات در کلاسهای مشتق شده اعمال می شود .
با توجه به اینکه به غیر از اعلان متدها و خصوصیتها امکان تعریف عناصر دیگر در Interface ها وجود ندارد ، در صورتی که ملزم به استفاده از این عناصر باشیم ، استفاده از کلاسهای Abstract ضروری می باشد .
در صورتی که نخواهیم کلیه متد ها در کلاس های مشتق شده پیاده شود و تعدادی از آنها را در کلاس پدر کدنویسی کنیم ، باید از کلاس Abstract استفاده کنیم .
به طور کلی Interface ها چارچوب و قابلیتهای کلاس را مشخص میکند و یک قرارداد است ولی کلاس Abstract نوع کلاس را معین می کند . این تفاوت کمک بسیاری برای تشخیص زمان استفاده از این دو را ، به برنامه نویسان میدهد .


🍃💐🍃🌸🍃🌸🍃
➖➖➖➖➖➖➖➖➖➖
🆑 → @segmenttt🔰
➖➖➖➖➖➖➖➖➖➖
👁‍🗨با فوروارد کردن پست های چنل از ما حمایت کنید 👁‍🗨

‍ #دانستنی
✅ چرا نباید موقع شارژ با گوشی کار کنیم؟


🍃💐🍃🌸🍃🌸🍃
➖➖➖➖➖➖➖➖➖➖
🆑 → @segmenttt🔰
➖➖➖➖➖➖➖➖➖➖
👁‍🗨با فوروارد کردن پست های چنل از ما حمایت کنید 👁‍🗨

الگوی طراحی Adapter :

همان ‌گونه که از اسم این الگو مشخص است ، هنگامی که دو کلاس واسط‌های غیرمرتبط با یکدیگر داشته باشند این الگو واسط یکی را به دیگری تبدیل می‌کند که بتوانند با یکدیگر ارتباط برقرار کنند .
از این الگو که یک الگوی ساختاری است زمانی استفاده می‌شود که در یک برنامه بخواهیم که دو کلاس غیرمرتبط با یکدیگر کار کنند . این الگو در برنامه‌هایی که از کلاس‌های آماده و یا از کلاس‌هایی که قبلا نوشته شده‌اند و به‌گونه‌ای می‌باشند که طراحان نرم‌افزار اجازه تغییر در این کلاس‌ها را نداده باشند، استفاده می‌شود. بسیاری از مثال‌های الگوی Adapter درگیر ورودی و خروجی هستند. زیرا این دامنه‌ای است که همیشه تغییر می‌کند.
برای مثال برنامه‌هایی که در دهه 80 میلادی نوشته شده‌اند دارای UI بسیار ضعیف‌تری نسبت به برنامه‌های نوشته شده در هزاره سوم میلادی هستند. حال اگر دوباره‌نویسی همان برنامه‌های قبلی به‌صرفه نباشد و بخواهیم این برنامه‌ها با سخت افزارهای جدید همخوانی و سازگاری داشته باشند، باید برنامه‌ای طراحی کنیم که بین این دو برنامه یعنی برنامه قدیمی و راه‌اندازهای سخت افزارهای جدید قرار بگیرد و بین این دو برنامه ارتباط برقرار کند. به برنامه‌ای که بین این دو برنامه قرار می‌گیرد، Adapter گویند. حال شاید به نظر برسد که استفاده از Adapter اصلاً نیاز نباشد و می‌توان واسط یکی از کلاس‌ها را تغییر داد تا بتواند کار کند، این کار زمانی ممکن است که بتوان به کد کلاس‌ها دسترسی داشت و تغییر کلاس‌ها باعث به وجود آمدن مشکل در برنامه نباشد و پیچیدگی برنامه را افزایش ندهد که در اکثر مواقع این عمل به‌صرفه نیست.
الگويAdapter الگويی است كه در دنيای واقعي نمونه‌هاي زيادي از آن وجود دارد و به همين خاطر درك اين الگو زياد مشكل نخواهد بود.
در شکل مربوطه کلاس دیاگرام مربوط به این الگو نمایش داده شده و در زیر آن شرکت‌کنندگان در آن و نقش هریک بیان شده است.
بنابر گفته GoF هدف از الگوي Adapter عبارت است از :
تبدیل واسط یک کلاس به واسط دیگری که کاربر توقع دارد. Adapter امکان همکاری بین چند کلاس که به علت ناهمگونی واسط‌هایشان به روش دیگری نمی‌توانند باهم کار کنند، را فراهم می‌آورد .

🍃💐🍃🌸🍃🌸🍃
➖➖➖➖➖➖➖➖➖➖
🆑 → @segmenttt🔰
➖➖➖➖➖➖➖➖➖➖
👁‍🗨با فوروارد کردن پست های چنل از ما حمایت کنید 👁‍🗨

‍ #ترفند
✅ ترفند های شیطانی موبایل


🍃💐🍃🌸🍃🌸🍃
➖➖➖➖➖➖➖➖➖➖
🆑 → @segmenttt🔰
➖➖➖➖➖➖➖➖➖➖
👁‍🗨با فوروارد کردن پست های چنل از ما حمایت کنید 👁‍🗨

الگوهای طراحی و معماری-2

Domain Model – بخش اول :
منظور از اين مدل، object model ي از دامنه مساله است که هر کلاس آن شامل رفتار و ساختار موجوديتي(Entity) از موجوديتهاي آن دامنه است، براي مثال، "سند حسابداري"، که از مجموعه اي از آرتيکلها، تاريخ، شماره عنوان و وضعيت ساخته مي شود، از سويي مي تواند متد يا رفتاري با نام BALANCE را در خود داشته باشد که تراز بودن آن را مشخص مي کند،يادآوري مي کنم در روشي مانند Transaction Script متدي در يک کلاس که تراکنش ثبت سند را انجام مي دهد وجود دارد که تراز بودن سند را بررسي مي کند در حالي که در الگوي حاضر اين متد درون خود کلاس سند قرار مي گيرد.
نمودار Domain Model ، شبيه به نمودار Database Model است،با اين تفاوت که در آن موجوديتها علاوه بر ساختار، داراي رفتار و پروسس بوده و در مدل، شبکه اي پيچيده از ارتباطات (Association)بين اشيا و رابطه ارث بري (Inheritance) بين آنها وجود دارد.
خلاصه اينکه Domain Model متشکل از شبکه اي از اشيا به هم مرتبط از موجوديتهاي دامنه مساله است، هر موجوديت در دامنه مساله فارغ از سايز و اندازه اش و پيچيدگيش، داراي معناي خاص و واضحي است براي مثال "شرکت" موجوديتي بزرگ و "سفارش خريد" موجوديتي کوچک در دامنه مساله سيستم "پيگيري سفارشات" است که هر دو در مدل، کلاسهايي نظير براي خود دارند. بديهي است استفاده از Domain Model در يک برنامه به معناي قرار دادن تمام شبکه اشياء ساخته شده براي مساله در آن دامنه است، پس بهتر است از همين ابتدا ذکر کنم که خيال کندن بخشي از يک مدل و قرار دادن آن د برنامه اي ديگر را از ذهنتان بيرون کنيد، اين کار در ادامه پروژه تان به فاجعه منجر خواهد شد.
در مدل مورد بحث، ميتوان اشياء را به دو دسته تقسيم کرد، اشيايي که داراي ساختاري معادل با موجوديت هاي مساله هستند و اشيايي که تنها قوانين و آلگوريتمهاي محاسباتي مختلف را در خود دارند و به اقتضاي نيازهاي غير عملکردي در سيستم بوجود آمده اند، براي مثال مي توان به شي کارمند و احکام حقوقي او در سيستم حقوق دستمزد و شي محاسبه کننده کسورات بر اساس نوع بيمه کارمند اشاره کرد، دو شي اولي داراي ساختاري از اطلاعات دامنه مساله و دومي در برگيرنده آلگوريتمهاي محاسبه کسورات بر حسب نوع بيمه و قرارداد کارمند است. لازم به ذکر است که در الگوي Domain model اولويت با ترکيب الگوريتمها در کلاس نماينده موجوديتهاست و تنها بايد بر حسب ضرورتهاي طراحي و بر اساس الگوهاي طراحي نسبت به استخراج آلگوريتمها و محاسبات و قرار دادن آنها در کلاسهاي جداگانه اقدام کرد.
مدلهاي حاصل از اين الگو را مي توان به دو دسته ساده و پيچيده تقسيم کرد، در Domain Model هاي ساده به ازاي هر جدول در بانک اطلاعاتي يک کلاس در مدل وجود دارد؛ در مدلهاي پيچيده الازمي براي تطابق ساختار مدل با ساختار بانک اطلاعاتي وجود نداشته و درآن از ارث بري و الگوهاي طراحي به منظور خوانايي و انعطاف بيشتر استفاده مي شود. نگاشت مدلهاي ساده به بانک اطلاعاتي به سادگي و با استفاده از الگويي مانند Active Record انجام مي شود در حالي که نگاشت مدلهاي پيچيده مشکل تر بوده و نيازمند استفاده از Data Mapper ها ست .(در اين باب در پستهاي بعدي به تفصيل سخن خواهم گفت)
از آنجا که قوانين حاکم بر دامنه کسب و کار مرتبط با برنامه هاي ايجاده شده عموما در حال تغيير و تحول هستند لازم است براي جلوگيري از نشر و تاثير اين تغييرات در لايه هاي ديگر برنامه، حداقل وابستگي ممکن بين Domain Model و ساير لايه هاي برنامه وجود داشته باشد تا بتوان علاوه بر کنترل باز نشر تغييرات در ساير لايه ها، امکان Build و Test جداگانهDomain Model را نيز فراهم کرد.

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

معايب:
اين شيوه نياز به دانش بيشتري در حوزه طراحي و اصول و مفاهيم شي گرايي نسبت به ساير روشها داشته و نيازمند بکارگيري نيروهاي حرفه اي تر و متعاقبا گرانتري در انجام پروژه است، از سويي وجود لايه ها و کامپوننت هاي متعدد براي نگاشت موجوديتها به جداول بانک اطلاعاتي (Data Mappper) و DTO ها

چه زماني از اين روش استفاده کنيد:
زماني بايد ازالگوي Domain Model استفاده نمود که با مساله اي پيچيده مواجه هستيد، مساله اي که در آن تعداد زيادي آلگوريتم محاسباتي براي شرايط مختلف، الگوهاي متفاوت براي صحت سنجي اطلاعات و مجموعه اي از قوانين دائما در حال تغيير وجود دارد

‍ #ترفند
✅ ترفندهای رجیستری ویندوز

🍃💐🍃🌸🍃🌸🍃
➖➖➖➖➖➖➖➖➖➖
🆑 → @segmenttt🔰
➖➖➖➖➖➖➖➖➖➖
👁‍🗨با فوروارد کردن پست های چنل از ما حمایت کنید 👁‍🗨

الگوهای طراحی و معماری-1

Domain Logic

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

در فرآيند توليد نرم افزار يکي از مهم ترين مسال اين است که اين قوانين را کجا قرار دهيم، چگونه سامانشان دهيم، چگونه دسته بندي شان کنيم و ... . راه هايي که براي اين کار وجود دارند را Domain Logic Pattern مي نامند. منهاي الگوهاي من درآوردي که هر برنامه نويسي در ابتداي کارش اختراع مي کند، سه الگو وجود دارند که حساب خود را در مسائل مختلف پس داده اند و بهتر است با ايده گرفتن از آنها طراحي اين لايه را انجام داد، اولين الگو براي سازماندهي قوانين دامنه کسب و کار Transaction Script است.

Transaction Script:

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

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

براي سازمان دادن مجموعه Transaction Script ها مي توانيد آنها را بر حسب فاکتوری مانند موجوديتهاي محوري کسب و کار سازمان دهي کنيد و در يک کلاس جاي دهيد، بديهي است که مي توانيد فعاليتهاي مشترک را نيز در متدهايي جداگانه جاي دهيد تا هردفعه مجبور به تکرار آنها نشويد. از سويي مي توانيد هر Transaction Script را بصورت يک کلاس درآورده و با الگوي Command اجرا کنيد، مزيت اين روش قابليت تغيير Transaction Script ها در زمان اجراست،-واقعيت اين است که حتي خود آقاي Fowler هم به گفته خودش تا کنون به مساله اي بر نخورده که نياز به اين کار باشد!- در حالتي نوستالژيک هم مي توانيد تمام Transaction Script ها را در يک کلاس Static همچون متدهاي Global قرار دهيد و مانند دوران پيشا OO آنها را فراخواني کنيد.

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

دسترسي به Database :

عموما دسترسي به بانک اطلاعاتي در اين روش به واسطه لايه کوچکي از کلاسهاي Helperصورت مي گيرد که گاها تنها روکشي براي تکنولوژي ها يي همچو ADO.NET هستند. اگر لايه فيزيکی يا چارچوب عمومی ای برای دسترسي به داده جدا گانه اي نداريد پيشنهاد مي کنم حداقل يک کلاس به عنوان Helper براي کار با بانک اطلاعاتی داشته باشيد و اگر هم داشتن يک کلاس براي انجام کارهاي بانک اطلاعاي برايتان سخت است! حداقل کار را به متدهاي جدا گانه اي که تخصصشان کار با بانک اطلاعاتي است منتقل نماييد.

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

مزايا:

مهمترين مزيت روش Transaction Script سادگي آن است، سيستمي که با اين روش نوشته شده باشد و قوانين مختصري در دامنه مساله اش داشته باشد براي هر برنامه نويسي به راحتي قابل فهم است.اين روش از حيث Performance نيز سر بار کمتري را به دنبالدارد.

معايب:

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

چه زماني از اين روش استفاده کنيد:

زماني که با مساله اي کوچک، داراي مجموعه قوانين کسب و کار مختصر طرف هستيد که تغيير چنداني در دامنه مساله نداريد اين روش بسيار کارا و مفيد است.


🍃💐🍃🌸🍃🌸🍃
➖➖➖➖➖➖➖➖➖➖
🆑 → @segmenttt🔰
➖➖➖➖➖➖➖➖➖➖
👁‍🗨با فوروارد کردن پست های چنل از ما حمایت کنید 👁‍🗨

‍ #دانستنی
✅ گلوگاه سی پی یو چیست ؟ و چگونه آن را کاهش دهیم؟

🍃💐🍃🌸🍃🌸🍃
➖➖➖➖➖➖➖➖➖➖
🆑 → @segmenttt🔰
➖➖➖➖➖➖➖➖➖➖
👁‍🗨با فوروارد کردن پست های چنل از ما حمایت کنید 👁‍🗨

الگوهای طراحی و معماری 0

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

در مقدمه نياز است تا برخي از تعاريف را با هم همسان کنيم تا در ادامه به سوء تفاهم دجار نشويم.

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

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

لذا

اولاً: براي يافتن تعريفي دقيق از اين دسته از نرم افزارها به کتاب PoEAA ، بخش مقدمه و مبحث Enterprise Applications مراجعه نماييد. همانطور که در آن کتاب خواهيد ديد مجموعه اي از خصوصيات براي نرم افزارهايي که ما آن را Enterprise Applications مي ناميم ارائه شده است که شامل موارد ذيل مي باشند:

· Data Persistence

· Large Amount Of Data

· Access Data Concurrently

· A lot of user interface screens

· Need to integrate with
other enterprise applications

· Complex business logic

ثانياً: اين الگوها مانند هر الگوي ديگري بايد متناسب با مساله اي که درگير حل آن هستيد و با توجه به بايدها و نبايدهاي آن مساله و فضاي آن بکار گرفته شوند، بي شک الگوهايي که براي ساخت سيستم اتوماسيون اداري يک سازمان کوچک با 20 کارمند بکار مي رود بسيار متفاوت با سيستم اتوماسيون سازماني با 14000 کارمند و ده ها شعبه است.

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

🍃💐🍃🌸🍃🌸🍃
➖➖➖➖➖➖➖➖➖➖
🆑 → @segmenttt🔰
➖➖➖➖➖➖➖➖➖➖
👁‍🗨با فوروارد کردن پست های چنل از ما حمایت کنید 👁‍🗨

‍ #آموزش
✅ آموزش تنظیم ساعت و تاریخ در ویندوز و امکانات بیشتر آن


🍃💐🍃🌸🍃🌸🍃
➖➖➖➖➖➖➖➖➖➖
🆑 → @segmenttt🔰
➖➖➖➖➖➖➖➖➖➖
👁‍🗨با فوروارد کردن پست های چنل از ما حمایت کنید 👁‍🗨

الگوهای معماری Architectual Patterns

یک الگوی معماری توضیحی از گروهی از اجزا(Element) و روابط بین آنها با مجموعه ای از محدودیتها(Constraint) برا ی استفاده از آنهاست.یک الگو می تواند به عنوان مجموعه ای از محدودیتها بر روی یک معماری در نظر گرفته شود-بر روی اجزا و الگوهای ارتباطی بین آنها-و این محدودیتها مجموعه یا خانواده ای از معماری هایی که آنها را برآورده سازند معرفی می کنند.برای مثال Client –Server یک الگوی معماری معمول است،Client , Server دو نوع از اجزا(Element) هستندعبارت Client –Server نشان دهنده وجود چندین Client است ،خود Client ها و مجموعه فعالیتهای آنها مشخص نمی شوند و تنها پیاده سازی پروتکل ارتباطی آنها بر عهده هریک از Client ها و Server گذاشته می شود در معماری بررسی می شوند.معماری های بیشماری بر اساس این تعریف از نوع معماری Client –Server خواهند بود اما هریک از آنها متفاوت از دیگری است.


🍃💐🍃🌸🍃🌸🍃
➖➖➖➖➖➖➖➖➖➖
🆑 → @segmenttt🔰
➖➖➖➖➖➖➖➖➖➖
👁‍🗨با فوروارد کردن پست های چنل از ما حمایت کنید 👁‍🗨