توی فلاتر به جای ویجت Container میتونید از ویجت های زیر و ترکیب‌شون استفاده کنید :

✅ConstraintedBox
✅SizedBox
✅ColoredBox
✅DecoratedBox
✅Transform
✅Align
✅Padding
✅....

چرا میگم از اینا استفاده کنید ؟

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

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

اینجوری همه چی هدفمند و مشخصه

به نظر من Container برای کسایی هست که تازه تازه فلاتر رو شروع کردن و بعدش باید ازش دست بکشی (صرفن نظر شخصی)

@purecoder_ir

اپوکالیپس؛ مشکلی که همه زمان سنج‌های یونیکسی در سال ۲۰۳۸ خواهند داشت.

مساله اینه که وقتی خدایگان یونیکس تصمیم گرفتن روشی برای زمان‌سنجی اختراع کنن، با خودشون گفتن «ما تعداد ثانیه‌های گذشته از ۱ ژانویه ۱۹۷۰ رو می‌شمریم» و برای اینکار از یه عدد ۳۲ بیتی علامت‌دار استفاده کردن و این متغیر در ۲۰۳۸ پر خواهد شد و زمان ریست می‌شه (: راه حل احتمالی؟ مهاجرت همه لینوکس‌ها، بی اس دی‌ها، یونیکس‌ها،‌ دیتابیس‌ها و همه دوستاشون به زمان سنج‌های ۶۴ بیتی.

https://youtube.com/shorts/ZY4e79NIdVk?feature=share

🔥Data Structures

🔥توی کد هامون همیشه یه سری Data model یا Data Transfer Object یا ... داریم که فقط شامل یه سری فیلد هستن و هیچگونه متدی ندارن ...

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

🔥نکته مهم این هست که اگه گتر و ستر داشته باشن،گتر ها و ستر ها خیلی ساده هستن و لاجیک خاصی ندارن

🔥به این کلاس های فاقد متد میتونیم بگیم دیتا استراکچر.

❓آیا برای این کلاس ها باید تست بنویسیم ؟ ( هرچند میدونم که کلن تست نمی‌نویسید 😁😝 ولی خب)

✅خیر نیازی به تست ندارن چون که لاجیک خاصی ندارن .

❓اگه گتر و ستر و کانستراکتور داشتن چی؟

✅بازم جواب نه هست چون که لاجیک خاصی ندارن و فضایی برای اشتباه کردن وجود نداره و نیازی به تست نیست .

🔥همچنین این کلاس ها میتونن یه سری متد تحت عنوان mapper داشته باشن که اون ها رو به ابجکت های دیگه کانورت میکنه مثل ToJson یا fromJson و ...

❓آیا نیازه برای این ها تست نوشت ؟

✅بله.
✅ولی بهتره این لاجیک رو از این کلاس ها خارج کنید و کلاس های دیگه با نام Mapper توی پروژتون داشته باشید که کارشون تبدیل کردن دو تا تایپ به هم دیگه هست و اون ها رو تست کنید و دیتا استراکچر هاتون رو کلن بدون تست رها کنید .

❓اگه از پکیج ها برای مپ کردن (مثل toJson یا ...) استفاده کردیم نیازی به یونیت تست هست ؟

✅نه نیاز نیست .
نیازی به یونیت تست در این مورد نیست و یه integration test که چندین کلاس به علاوه این کلاس ها رو پوشش میده کافیه .

@purecoder_ir

هر ویدئو یا مقاله ای که زبانش انگلیسی باشه نشون دهنده این نیست که هر چیزی که‌گوینده میگه درسته ...

زبان اصلی بودن اعتبار نمیاره 🤦‍♂

خارجی ها از کره ی مریخ نیومدن، اون ها هم آدمن، ممکنه اشتباه کنن، ممکنه چرت و پرت بگن ...

حواستون باشه به کجا رفرنس می‌زنید

@purecoder_ir

🔥Entity - Model

❌اینکه توی پروژه هاتون هم Entity و هم Model درست می‌کنید خیلی وقت ها کار اضافیه و خیلی وقت ها همون Entity کفایت میکنه...

✅میخواین از دیتابیس استفاده کنید؟ همون Entity کافیه و می‌تونید از ORM برای تبدیل اسکیمای دیتابیس به Entity استفاده کنید.

✅میخواین Json رو به Entity تبدیل کنید و برعکس؟ یه mapper بنویسید که کارش تبدیل جیسون به Entity و برعکس هست .

چه لز‌ومی داره که یه مدل می‌نویسید و این همه کد اضافی به پروژتون اضافه می‌کنید

❌مشکل اینجاست که خیلی وقت ها اصن Entity هاتون رو بدون لاجیک می‌نویسید و صرفن یه دیتااستراکچره و مدلتون هم کپی‌ Entity تون هست !!!!

حتا خیلی از مواقعی که یه rich domain model داریم و Entity مون پر از لاجیک هست هم نیازی به مدل نیست، چه برسه به...

بعضی مواقع واقعن لازمه ولی خیلی وقت ها واقعن اضافه کاریه !!!

🔥کد اضافی نزنید
توی پروژه های موبایل که خیلی خیلی خیلی اضافیه ...

@purecoder_ir

ما چیزی داریم به نام مدل OSI

بچه های شبکه توی دانشگاه یا کلاس های شبکه درموردش خوندن حتماً


از 7 لایه تشکیل شده
وقتی دارید با API کار میکنید دیتای که ارسال میکنید از این 7 لایه میگذره و به مقصد میرسه


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

ولی توی مقصد دریافت و پردازش داده از لایه اول شروع میشه تا برسه به لایه هفتم

لایه هفتم همون اپلیکیشن شما هستش

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

یاد بگیرید حتمن
در حدی که بدونید چیه

🔥Kent Beck Design Rules

@purecoder_ir

🔥Dart 3.3
✅Extension Method vs Extension Type

https://dart.dev/language/extension-types

@purecoder_ir

❓پترن
✅هر پترن یه problem ای رو بیان میکنه که بارها ‌و بارها اتفاق افتاده و یه سولوشن براش ارائه میده ‌.

❓آنتی پترن
✅هر آنتی پترن یه problem ای رو بیان میکنه که بارها و بارها اتفاق افتاده و یه سولوشن رو براش ارائه میده .
این سولوشن در ابتدا مناسب به نظر میرسه ولی خودش باعث problem های بیشتری میشه .

@purecoder_ir

❓چالش

چرا توی معماری هایی مثل کلین میگیم که ورودی خروجی های Application Serivce ها یا usecase ها باید Data Transfer Object (دیتا استراکچر ) باشن و نباید Entity ها رو توی ورودی و خروجی سرویس ها استفاده کنیم. ولی در عین حال میتونیم Entity ها رو از طرف سرویس ها یا یوزکیس ها به Repository ها پاس بدیم و همچنین Repository ها هم میتونن Entity ریترن کنن؟

چرا ورودی و خروجی اونطرفشون باید دیتااستراکچر باشه و نباید Entity باشه ولی توی ارتباط با Repository ها مشکلی نداره Entity رد و بدل بشه؟

@purecoder_ir

🔥clean code

@purecoder_ir

🔥DRY
🔥Don't Repeat Yourself

اصل DRY صراحتن در مورد code duplication صحبت نمیکنه و هر code duplication ای الزامن نقض اصل DRY نیست.

بعضی مواقع با Accidental Duplication روبرو میشیم.

ینی چی؟

یعنی دو قطعه کد کپی یا شبیه هم هستن و ما فکر می‌کنیم که DRY نقض شده و سعی می‌کنیم که با یکی کردن اونها duplication رو از بین ببریم .

ولی در واقعیت این یه duplication تصادفی بوده و به هیج وجه نباید اون دو قطعه کد یکسان سازی بشن‌.

برای همین میگیم که اصل DRY رو نباید در حد code duplication پایین بیاریم.

@purecoder_ir

سندروم شوفر

@purecoder_ir

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

✅Composite
✅Observer
✅Decorator
✅Proxy
✅Visitor
✅Chain of Responsibility
✅Factory Method
✅Template Method
✅Command
✅Momento

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

شما تکمیل ترش کنید...

🔥فریمورک های خوب بهشت دیزاین پترن ها هستن😍😍

🔥برای مثال توی فلاتر ترکیب Composite با Visitor و همچنین ترکیب Composite با Chain of Responsibility رو میبینیم😍

@purecoder_ir

فولدرهای تو در تو الزامن باعث بهتر شدن ساختار یا معماری آپ نمیشن

بعضی جاها باید ۱۰ تا فولدر( با اغراق ) باز کنی که برسی به کلاس هدف ....بعد اصن یادت میره کجا بودی!!!!

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

این موضوع رو خیلی زیاد جاهای مختلف دیدم، چه پروژه های فلاتری و چه ...

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

Simple, simple, simple

شما اگه بخواین از تهران برید مشهد، باید مسیر مستقیم رو برید ....گرمسار، سمنان، دامغان، شاهرود، سبزوار.....

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

پ.ن: در ضمن، شما توی مراحل مختلف میتونی ساختار اپت رو تغییر بدی و الزامی نداره به یه چیزی پایبند باشی که از ابتدای کار خودت رو گرفتار ساختارهای توهمی کنی که نکنه در آینده به مشکل بخورم

@purecoder_ir