مقایسه ابزارها برای درک بهتر نه قضاوت درباره آنها :

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

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

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

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


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

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


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

✅ مهندسین کامپیوتر را دست کم نگیرید! ✅

❓❓زیرا:

1- آنها اولین چیزی که یاد گرفته اند TrueوFalse بوده،پس راحت میتوانند درست را از نادرست تشخیص دهند.
2- تمام برنامه هایی که انها پیاده سازی میکنند دارای الگوریتم می باشد و مرحله مرحله پیش میرود حتی نقطه برگشت دارد، پس راحت میتوانند به عقب برگردند و مسیر را تغییر دهند.
3- آنها از بچگی در دو دنیا زندگی کرده اند، پس حواستان باشد با یک حرکت میتوانند شما را انتقال دهند به دنیای مجازی.
4- آنها همیشه روی سیستم خود آنتی ویروس نصب میکنند و کوچکترین مورد مشکوکی که ببینند سریع delete میکنند،پس راحت میتوانند شما حذف کنند.
5- انها Cut کردن را خوب بلد هستند.

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

‍ #آموزش

✅ آموزش تعمیر ویندوز آسیب دیده



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

✋سلام دوستای عزیز
ترجمه بخش سوم فصل اول #کتاب #kotlin_in_Action هر چند دیر ولی تموم شد

خلاصه این بخش
🔶#کاتلین کلاس های مجموعه خود را تعریف نمی کند و در عوض کلاس های مجموعه #جاوا را با یک API غنی تر تقویت می کند.
🔶تعریف مقادیر پیش‌فرض برای پارامترهای تابع نیاز به تعریف توابع اضافه را تا حد زیادی کاهش می‌دهد، و #syntax آرگومان نام‌گذاری شده باعث می‌شود فراخوانی‌های توابع با پارامترها بسیار خواناتر شود.
🔶توابع و خصوصیات را می توان مستقیماً در یک فایل اعلان کرد، نه فقط به عنوان اعضای یک کلاس، که امکان ایجاد ساختار کد انعطاف پذیرتر را فراهم می کند.
🔶ویژگی ها و توابع پسوند(#Extension_functions) به شما امکان می دهند #API هر کلاس، از جمله کلاس های تعریف شده در کتابخانه های خارجی، بدون تغییر کد منبع آن و بدون سربار زمان اجرا گسترش دهید.
🔶فراخوانی های #Infix یک syntax تمیز برای فراخوانی متد های اپراتور مانند با یک آرگومان واحد ارائه می کنند.
🔶کاتلین تعداد زیادی از توابع را برای مدیریت راحت رشته ، هم برای عبارات منظم و هم برای رشته های ساده فراهم می کند.
🔶رشته‌های نقل قول سه‌گانه راهی تمیز برای نوشتن عباراتی ارائه می‌کنند که نیاز به جداسازی شلوغی اضافی و الحاق رشته‌ها در جاوا نیاز دارند.
🔶توابع محلی به شما کمک می کنند کد خود را تمیزتر ساختار دهید و کد تکراری را حذف کنید.


🟢مثل همیشه حمایت کنید انشالله فصل های بعدی هم منتشر بشه

#function #ترجمه_کتاب #تبدیل_جاوا_به_کاتلین #برنامه_نویسی #اندروید

✅لینکدین
https://www.linkedin.com/pulse/kotlin-action-farid-mohammadi/?trackingId=DSdcuXAkRM2rclE8lXr4jg%3D%3D

✅ویرگول
https://vrgl.ir/GVMs3


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

الگوی طراحی 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🔰
➖➖➖➖➖➖➖➖➖➖
👁‍🗨با فوروارد کردن پست های چنل از ما حمایت کنید 👁‍🗨