آشنایی با Clean Architecture در برنامه نویسی اندروید

بهمن 12, 1399| سنا عبادی
آموزش معماری تمیز در برنامه نویسی اندروید ، آموزش Clean Architecture در برنامه نویسی اندروید | وبلاگ اندروید ریور

در این مقاله درباره معماری تمیز یا Clean Architecture در برنامه نویسی اندروید صحبت می کنیم اینکه معماری تمیز یا برنامه نویسی تمیز چیست و چه مزایایی دارد و چگونه باید در برنامه نویسی این معماری را پیاده و رعایت کنیم. در ادامه همراه باشید..

رابرت سی مارتین(Robert C. Martin) معروف به آنکل باب (Uncle Bob) خالق کتاب هایی همچون Clean Code , Clean Coder است که  در این پست قرار هست در رابطه با آخرین اثر ایشون از مجموعه ی کتب  Clean به نام Clean Architecture مختصر صحبتی را داشته باشیم پس با من همراه باشید .

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

برخی از این معماری ها مانند :

  • Hexagonal یا معماری Ports and Adapters که توسط Alistair Cockburnمعرفی شد.
  • Onion Architecture توسط Jeffrey Palermo (معماری پیازی)
  • Screaming Architecture توسط خود آقای باب مارتین

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

Uncle Bob سعی کرد با تجمیع تمامی خصوصیات های مشترک چند معماری معروف به یک معماری جامع به نام Clean Architecture دست پیدا کند که این معماری در تمامی زبان های برنامه نویسی و فریم ورک ها قابل استفاده و پیاده سازی است .

یکی از وجوه مشترک معماری های فوق میتوان به دو لایه ی Business Rules و Interfaces اشاره کرد .یعنی این دو لایه در تمامی معماری های فوق وجود دارند .

اگر قرار باشد کمی از ویژگی های این معماری ها بگوییم  می توانیم آن ها را به این صورت در چند خط خلاصه کنیم :

  • اولین مورد استقلال و نداشتن وابستگی این معماری به فریمور کی هست که قرار است از آن استفاده کنید . دقیقا همان نکته ایی که بالاتر گفتیم . این معماری در هر فریم ورک قابل پیاده سازی است .در واقع در این سیستم , معماری ها که یک ابزار به حساب می آیند مانند یک افزونه به راحتی قابل ویرایش و یا تعویض هستند .
  • عدم وابستگی به UI  و Database  یکی دیگر از ویژگی های این معماری می باشد . در این معماری ها بدون تغییر در لاجیک یا همان Business Rule میتوان UI  را تغییر داد . این موضوع برای دیتابیس ها نیز صادق است به صورتی که می توان دیتابیس را  از  SQL Server به Oracle یا Mongo  و  BigTable تعویض کرد .
  • و یکی از مهمترین ویژگی ها استقلال و بی اطلاع بودن درونی ترین لایه از بیرون ترین لایه ها می باشد . یعنی لایه ی Business به طور کاملا مستقل از دیگر لایه ها طراحی و پیاده سازی می شود .
  • قابل تست بودن نرم افزار به این دلیل که لایه ها مستقل و جدا از هم فعالیت می کنند که توسط تکنیک هایی مثل mock کردن میتوان هر لایه را مستقل از لایه ی دیگری تست کرد.
  • مستقل بودن از هر منبع خارجی (external resource) . به این صورت که لایه ایی که شامل business rule ها است هیچ اطلاعی از سایر لایه ها ندارد.
همچنین بخوانید :  آموزش طراحی رابط کاربری رسپانسیو برای اپلیکیشن

مطابق تصویر بالا:

  • لایه C به لایه B و A دسترسی دارد.
  • لایه B به هر چیزی در لایه A واقف است ولی از لایه C هیچ اطلاعاتی ندارد. در واقع حتی از وجود لایه C هم با خبر نیست.
  • لایه A پایین‌ترین لایه است و هیچ اطلاعی از لایه‌های دیگر ندارد. در واقع یک لایه کاملاً کور و نابیناست.

اصل ماجرا همین است. مابقی جزئیات در خدمت این سه اصل کلیدی است.

در ادامه شما نمای کلی این معماری را در قالب یک تصویر خواهید دید .

Dependency Rule یا اصل قانون وابستگی :

برای استفاده  از این معماری ما باید با اصلی به نام قانون وابستگی ( Dependency Rule) آشنا باشیم که کمی درموردش صحبت خواهیم کرد .

همانطور که در تصویر بالا مشاهده میکنید , ما با چند لایه سروکار داریم . حداقلش 3 لایه است ولی با توجه به سناریو و پیچیدگی آن میتوان تعداد لایه ها را بیشتر کرد .

در تمامی قسمت های این لایه ها این اصل و قانون رعایت شده است . به این صورت که دایره های داخلی سیاست های (Policy) نرم افزار و دایره های خارجی تر شامل مکانیزم های مورد نیاز جهت پیاده سازی آن سیاست ها هستند.

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

در تصویر زیر می توان مفهوم اینکه ارتباط لایه ها از خارج به داخل می باشد را بهتر متوجه شد :

به این تصویر در رابطه با این روابط بین لایه ها توجه کنید :

لایه Entities

این لایه شامل business rule هاست . Business rule می توانند به صورت آبجکت ها و کلاس ها و حتی ساختمان داده هایی پیاده  سازی شوند . این لایه مقاوم ترین لایه در مقابل تغییرات است . یعنی اگر در لایه های خارجی تغییری صورت گیرد , این لایه هیچ گونه تغییری نخواهد کرد . یعنی اگر در قسمت UI  تغییری انجام شود این قسمت بدون تغییر باقی خواهد ماند .

لایه Use Cases

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

  • ثبت سفارش
  • ثبت اطلاعات شخصی برای پروفایل
  • ثبت و ارسال نظرات 
همچنین بخوانید :  آموزش ساخت صفحه اسپلش در اندروید استدیو

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

لایه Interfaces and Adapters

این لایه شامل اینترفیس ها و آداپتور هایی برای تبدیل فرمت به فرمتی دیگر است . یعنی تبدیل فرمت های لایه ها برای یک دیگر . به طور مثال تبدیل فرمت داده ها از حالت مناسب برای لایه های entities و use cases به فرمت مناسب برای لایه های خارجی تر و بالعکس از وظایف این لایه به شمار می آیند .

لایه Frameworks and drivers

این لایه خارجی ترین و متشکل از Tools  ها یا همان ابزارها و فریم ورک ها است . مواردی مثل دیتابیس ها و فریمورک ها و مواردی مشابه در این لایه تعریف و پیاده می شوند . یعنی تمامی جزییات سیستم در این لایه قرار دارند . یعنی پایگاه داده ها , UI  , .. همان جزییات هستند .

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

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

  • Kotlin : زبانی برای برنامه نویسی اندروید که توسط شرکت گوگل پشتیبانی می شود و خصوصیات و ویژگی های بسیاری دارد که آن را از رقیب خود برای برنامه نویسی اندروید یعنی جاوا متمایز میکند . برای مطالعه بیشتر میتوانید به داکیومنت های مربوطه مراجعه کنید.
  • Dagger 2 : یک فریم ورک برای dependency injection در برنامه نویسی اندروید و زبان کاتلین و جاوا
  • RxJava 2 : کتابخانه ایی برای برنامه نویسی Reactive 
  • Retrofit 2 : کتابخانه ایی برای ارتباط با سرور در اندروید
  • Room : کتابخانه ایی برای پایگاه داده ها در اندروید که مبتنی بر Sqlite  هست .
  • ViewModel : کتابخانه ایی که برای مدیریت و ذخیره رابط کاربری به روش آگاهی از چرخه زندگی اکتیویتی یا فرگمنت استفاده میشود.
  • LiveData : اصطلاحا یک observable دیتا هست که بازهم با توجه به life cycle یک اکتیویتی یا فرگمنت دیتا را مدیریت میکند .
  • Paging Library: لود کردن  دیتا را  به صورت تدریجی در RecyclerView را برای ما آسان تر میکند.

همانطور که گفتم می توانید طبق نیاز خود هر کدام رو استفاده یا حذف و یا تغییر دهید . 

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

در ادامه خوشحال خواهم شد با ارسال دیدگاه در این مقاله شرکت کنید و دیدگاه خودتون رو بیان کنید 🙂 Happy Coding

  تخفیف ها و اخبار ویژه رو در تلگراممون دنبال کن :)
سنا عبادی نویسنده مقاله

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



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

مقالات مرتبط را بخوانید :


سورس های اندروید شامل تخفیف رو ببین !

به این مقاله امتیاز دهید :
4.5/5 (2 Reviews)
  خرید سورس های حرفه ای بازی و اپلیکیشن اندروید

دسته‌ها: آموزش برنامه نویسی اندروید

دیدگاهتان را بنویسید

راهنما : برای نوشتن موارد مختلف در دیدگاه می توانید از راهنمای نگارش اندروید ریور استفاده کنید : نگارش کد کوتاه `your code`
نگارش کد بلند یا نگارش بخش عمده یک سورس کد :
[sourcecode lang="your code language"] your code here [/sourcecode]