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

شروع معماری یک نرم‌افزار فلاتر:

معماری نرم‌افزار در فلاتر چیزی است که همیشه با مدیریت استیت‌ها گره خورده است! اگر شما به دنبال یک معماری خوب هستید از همان ابتدا به فکر یک سیستم مدیریتی خوب برای استیت‌ها باشید! برنامه ‌نویسیان گوگل اخیرا علاقه زیادی به provider نشان می‌دهند اما حقیقت این است که provider محبوب است، به خاطر اینکه ساده است! من اصرار ندارم که سادگی در تضاد با کارایی خوب است. BLoC پیچیده‌تر است و در نهایت به نظرم بهتر همه چیز را مدیریت می‌کند. من هر دو را دوست دارم، در این معماری از بلاک استفاده کرده‌ام!

یک طراحی خوب چند ویژگی اساسی دارد: ۱- منطق برنامه و رابط کاربری آن مستقل است ۲- تست نوشتن برای آن زحمت بیش‌ از اندازه ندارد ۳- کد‌های نوشته شده بر اساس این معماری قابل نگه‌داری و توسعه هستند

ممکن است واژه قابل نگه‌داری کمی برای شما ناملموس باشد من همان maintainable را ترجمه کرده‌ام که بین برنامه‌نویسان رایج است، اخیرا یک پادکست خوب فارسی در این مورد شنیده‌ام که شما هم می‌توانید سراغش بروید: چگونه کد‌های قابل نگهداری بنویسیم؟

برای استفاده از مدیریت استیت بلاک در فلاتر یک کتابخانه به شدت خوب و توصیه شده هم موجود است که می‌توانید از آن استفاده کنید: flutter_bloc یک سخنرانی بسیار جذاب و شنیدنی هم در مورد بلاک روی یوتیوب هست که توصیه می‌کنم حتما نگاه کنید!

جواب: معماری تمیز (Clean Architecture)

شما سوالی نپرسیده‌اید می‌دانم اما جواب تقریبا هر سوال در مورد معماری خوب یک نرم‌افزار همین معماری تمیز است. معماری تمیز همه ویژگی‌هایی که قبلا شمرده‌ام را با هم دارد!

معماری تمیز

بحث این معماری خب خیلی طولانی است شما می‌توانید خودتان در مورد این طراحی خیلی اطلاعات بدست بیاورید اما یک منبع خوب که اگر با فلاتر کار می‌کنید به شما خیلی کمک می‌کند سری آموزش‌های رسوکدر است: معماری تمیز و TDD در فلاتر

من برای ساده‌تر شدن معماری یک نرم‌افزار دو پکیج به چیز‌هایی که رسوکدر می‌گوید اضافه کرده‌ام و سورس اصلی برنامه‌ام به این شکل است:

constants, styles

ثابت‌های برنامه بیشتر متن‌ها و عددهای ثابت را شامل می‌شود که شاید در جاهای مختلفی از آن‌ها استفاده کنیم. پوشه استایل شامل تم‌ها و رنگ‌های ثابتی است که در جاهای مختلفی به کارمان می‌آیند! البته همه استایل‌ها اینجا تعریف نمی‌شود اگه یک قابلیت (feature) در برنامه استایل خاصی دارد سعی می‌کنیم آن را در پوشه presentation خودش جداگانه تعریف کنیم.

پوشه core شامل چیز‌های اساسی برنامه است، از اسمش هم مشخص است! مثلا طراحی کلی یک UseCase در این پوشه صورت می‌گیرد! هر قابلیت در برنامه در پوشه feature پیاده می‌شود که خودش شامل بخش‌های مختلفی است. رسوکدر از من بهتر و مفصل‌تر همه این‌ها را توضیح داده است.

یک فیچر به این شکل طراحی می‌شود:

طراحی هر فیچر لایه لایه است و همین موضوع باعث خوانایی بهتر کد می‌شود و توسعه‌ دادن آن را ساده‌تر می‌کند.

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

  • Persian

About Nilva

No. 5
Orang Dead End
Abbas Sharghi Alley
Akbari Blv
Tehran, IRAN

T: +98 (0)915 077 3830
E: admin@nilva.ir