সাধারণ মডুলারাইজেশন নিদর্শন

কোনো একক মডুলারাইজেশন কৌশল নেই যা সমস্ত প্রকল্পের সাথে খাপ খায়। Gradle এর নমনীয় প্রকৃতির কারণে আপনি কীভাবে একটি প্রকল্প সংগঠিত করতে পারেন সে সম্পর্কে কিছু সীমাবদ্ধতা রয়েছে। এই পৃষ্ঠাটি কিছু সাধারণ নিয়ম এবং সাধারণ নিদর্শনগুলির একটি সংক্ষিপ্ত বিবরণ দেয় যা আপনি মাল্টি মডিউল অ্যান্ড্রয়েড অ্যাপ তৈরি করার সময় ব্যবহার করতে পারেন।

উচ্চ সংহতি এবং কম সংযোগ নীতি

একটি মডুলার কোডবেস বৈশিষ্ট্যযুক্ত করার একটি উপায় হল কাপলিং এবং সমন্বয় বৈশিষ্ট্যগুলি ব্যবহার করা। কাপলিং যে মাত্রায় মডিউল একে অপরের উপর নির্ভর করে তা পরিমাপ করে। সমন্বয়, এই প্রসঙ্গে, পরিমাপ করে কিভাবে একটি একক মডিউলের উপাদানগুলি কার্যকরীভাবে সম্পর্কিত। একটি সাধারণ নিয়ম হিসাবে, আপনার কম সংযোগ এবং উচ্চ সংহতির জন্য চেষ্টা করা উচিত:

• কম কাপলিং মানে হল মডিউলগুলি একে অপরের থেকে যতটা সম্ভব স্বাধীন হওয়া উচিত, যাতে একটি মডিউলের পরিবর্তনগুলি অন্য মডিউলগুলিতে শূন্য বা সর্বনিম্ন প্রভাব ফেলে। মডিউলগুলির অন্যান্য মডিউলগুলির অভ্যন্তরীণ কাজের জ্ঞান থাকা উচিত নয় ।
• উচ্চ সংহতির অর্থ হল মডিউলগুলিকে কোডের একটি সংগ্রহ অন্তর্ভুক্ত করা উচিত যা একটি সিস্টেম হিসাবে কাজ করে। তাদের স্পষ্টভাবে সংজ্ঞায়িত দায়িত্ব থাকতে হবে এবং নির্দিষ্ট ডোমেন জ্ঞানের সীমানার মধ্যে থাকতে হবে। একটি নমুনা ইবুক অ্যাপ্লিকেশন বিবেচনা করুন. একই মডিউলে বই এবং অর্থপ্রদান সংক্রান্ত কোড একসাথে মিশ্রিত করা অনুপযুক্ত হতে পারে কারণ তারা দুটি ভিন্ন কার্যকরী ডোমেন।

মডিউলের প্রকারভেদ

আপনি আপনার মডিউলগুলি যেভাবে সংগঠিত করবেন তা মূলত আপনার অ্যাপের আর্কিটেকচারের উপর নির্ভর করে। নীচে কিছু সাধারণ ধরণের মডিউল রয়েছে যা আপনি আমাদের প্রস্তাবিত অ্যাপ আর্কিটেকচার অনুসরণ করার সময় আপনার অ্যাপে প্রবর্তন করতে পারেন।

ডেটা মডিউল

একটি ডেটা মডিউলে সাধারণত একটি সংগ্রহস্থল, ডেটা উত্স এবং মডেল ক্লাস থাকে। একটি ডেটা মডিউলের তিনটি প্রাথমিক দায়িত্ব হল:

1. একটি নির্দিষ্ট ডোমেনের সমস্ত ডেটা এবং ব্যবসায়িক যুক্তি এনক্যাপসুলেট করুন : প্রতিটি ডেটা মডিউল একটি নির্দিষ্ট ডোমেনের প্রতিনিধিত্ব করে এমন ডেটা পরিচালনার জন্য দায়ী হওয়া উচিত। যতক্ষণ তারা সম্পর্কিত হয় ততক্ষণ এটি অনেক ধরণের ডেটা পরিচালনা করতে পারে।
2. রিপোজিটরিটিকে একটি বাহ্যিক API হিসাবে প্রকাশ করুন : একটি ডেটা মডিউলের সর্বজনীন API একটি সংগ্রহস্থল হওয়া উচিত কারণ তারা অ্যাপের বাকি অংশে ডেটা প্রকাশ করার জন্য দায়ী৷
3. বাইরে থেকে সমস্ত বাস্তবায়ন বিবরণ এবং ডেটা উত্স লুকান : ডেটা উত্সগুলি শুধুমাত্র একই মডিউল থেকে সংগ্রহস্থলগুলির দ্বারা অ্যাক্সেসযোগ্য হওয়া উচিত৷ তারা বাইরে লুকিয়ে থাকে। আপনি Kotlin এর private বা internal দৃশ্যমানতা কীওয়ার্ড ব্যবহার করে এটি প্রয়োগ করতে পারেন।

বৈশিষ্ট্য মডিউল

একটি বৈশিষ্ট্য হল একটি অ্যাপের কার্যকারিতার একটি বিচ্ছিন্ন অংশ যা সাধারণত সাইন আপ বা চেকআউট প্রবাহের মতো ঘনিষ্ঠভাবে সম্পর্কিত স্ক্রিনগুলির একটি স্ক্রীন বা সিরিজের সাথে মিলে যায়। যদি আপনার অ্যাপে একটি নীচের বার নেভিগেশন থাকে, তাহলে সম্ভবত প্রতিটি গন্তব্য একটি বৈশিষ্ট্য।

বৈশিষ্ট্যগুলি আপনার অ্যাপের স্ক্রিন বা গন্তব্যগুলির সাথে যুক্ত। অতএব, তাদের যুক্তি ও অবস্থা পরিচালনা করার জন্য তাদের একটি যুক্ত UI এবং ViewModel থাকতে পারে। একটি একক বৈশিষ্ট্য একটি একক দৃশ্য বা নেভিগেশন গন্তব্যে সীমাবদ্ধ থাকতে হবে না। বৈশিষ্ট্য মডিউল ডেটা মডিউলের উপর নির্ভর করে।

অ্যাপ মডিউল

অ্যাপ মডিউল হল অ্যাপ্লিকেশনের একটি এন্ট্রি পয়েন্ট। তারা বৈশিষ্ট্য মডিউলের উপর নির্ভর করে এবং সাধারণত রুট নেভিগেশন প্রদান করে। একটি একক অ্যাপ মডিউল বিভিন্ন বাইনারিতে কম্পাইল করা যেতে পারে ধন্যবাদ ভেরিয়েন্ট তৈরি করার জন্য।

যদি আপনার অ্যাপটি একাধিক ডিভাইসের ধরনকে লক্ষ্য করে, যেমন স্বয়ংক্রিয়, পরিধান বা টিভি, তাহলে প্রতিটির জন্য একটি অ্যাপ মডিউল সংজ্ঞায়িত করুন। এটি পৃথক প্ল্যাটফর্ম নির্দিষ্ট নির্ভরতা সাহায্য করে।

সাধারণ মডিউল

সাধারণ মডিউল, কোর মডিউল নামেও পরিচিত, এতে কোড থাকে যা অন্যান্য মডিউল প্রায়শই ব্যবহার করে। তারা অপ্রয়োজনীয়তা হ্রাস করে এবং একটি অ্যাপের আর্কিটেকচারে কোনো নির্দিষ্ট স্তরের প্রতিনিধিত্ব করে না। নিম্নলিখিত সাধারণ মডিউল উদাহরণ:

• UI মডিউল : আপনি যদি আপনার অ্যাপে কাস্টম UI উপাদান বা বিস্তৃত ব্র্যান্ডিং ব্যবহার করেন, তাহলে আপনার উইজেট সংগ্রহটিকে একটি মডিউলে এনক্যাপসুলেট করে সমস্ত বৈশিষ্ট্য পুনঃব্যবহারের জন্য বিবেচনা করা উচিত। এটি বিভিন্ন বৈশিষ্ট্য জুড়ে আপনার UI কে সামঞ্জস্যপূর্ণ করতে সাহায্য করতে পারে। উদাহরণস্বরূপ, যদি আপনার থিমিং কেন্দ্রীভূত হয়, আপনি একটি বেদনাদায়ক রিফ্যাক্টর এড়াতে পারেন যখন একটি রিব্র্যান্ড ঘটে।
• অ্যানালিটিক্স মডিউল : সফ্টওয়্যার আর্কিটেকচারের সামান্য বিবেচনায় ট্র্যাকিং প্রায়শই ব্যবসায়ের প্রয়োজনীয়তা দ্বারা নির্ধারিত হয়। অ্যানালিটিক্স ট্র্যাকারগুলি প্রায়ই অনেকগুলি সম্পর্কহীন উপাদানগুলিতে ব্যবহৃত হয়। যদি এটি আপনার ক্ষেত্রে হয় তবে একটি ডেডিকেটেড বিশ্লেষণ মডিউল থাকা একটি ভাল ধারণা হতে পারে।
• নেটওয়ার্ক মডিউল : যখন অনেক মডিউলের একটি নেটওয়ার্ক সংযোগের প্রয়োজন হয়, আপনি একটি HTTP ক্লায়েন্ট প্রদানের জন্য একটি মডিউল নিবেদিত রাখার কথা বিবেচনা করতে পারেন। এটি বিশেষভাবে উপযোগী যখন আপনার ক্লায়েন্টের কাস্টম কনফিগারেশন প্রয়োজন।
• ইউটিলিটি মডিউল : ইউটিলিটিগুলি, যা সাহায্যকারী হিসাবেও পরিচিত, সাধারণত ছোট ছোট কোড যা অ্যাপ্লিকেশন জুড়ে পুনরায় ব্যবহার করা হয়। ইউটিলিটিগুলির উদাহরণগুলির মধ্যে রয়েছে টেস্টিং হেল্পার, একটি কারেন্সি ফরম্যাটিং ফাংশন, ইমেল ভ্যালিডেটর বা একটি কাস্টম অপারেটর।

পরীক্ষা মডিউল

টেস্ট মডিউল হল Android মডিউল যা শুধুমাত্র পরীক্ষার উদ্দেশ্যে ব্যবহার করা হয়। মডিউলগুলিতে পরীক্ষার কোড, পরীক্ষার সংস্থান এবং পরীক্ষার নির্ভরতা রয়েছে যা শুধুমাত্র পরীক্ষা চালানোর জন্য প্রয়োজন এবং অ্যাপ্লিকেশনের রানটাইমের সময় প্রয়োজন হয় না। টেস্ট মডিউলগুলি পরীক্ষা-নির্দিষ্ট কোডকে মূল অ্যাপ্লিকেশন থেকে আলাদা করার জন্য তৈরি করা হয়, মডিউল কোড পরিচালনা এবং বজায় রাখা সহজ করে তোলে।

পরীক্ষার মডিউলগুলির জন্য কেস ব্যবহার করুন

নিম্নলিখিত উদাহরণগুলি এমন পরিস্থিতিতে দেখায় যেখানে পরীক্ষা মডিউলগুলি প্রয়োগ করা বিশেষভাবে উপকারী হতে পারে:

• শেয়ার্ড টেস্ট কোড : যদি আপনার প্রোজেক্টে একাধিক মডিউল থাকে এবং কিছু টেস্ট কোড একাধিক মডিউলের জন্য প্রযোজ্য হয়, তাহলে আপনি কোড শেয়ার করার জন্য একটি টেস্ট মডিউল তৈরি করতে পারেন। এটি ডুপ্লিকেশন কমাতে এবং আপনার পরীক্ষার কোড বজায় রাখা সহজ করতে সাহায্য করতে পারে। শেয়ার্ড টেস্ট কোডে ইউটিলিটি ক্লাস বা ফাংশন অন্তর্ভুক্ত থাকতে পারে, যেমন কাস্টম অ্যাসার্টেশন বা ম্যাচার, সেইসাথে পরীক্ষার ডেটা, যেমন সিমুলেটেড JSON প্রতিক্রিয়া।

• ক্লিনার বিল্ড কনফিগারেশন : টেস্ট মডিউল আপনাকে ক্লিনার বিল্ড কনফিগারেশনের অনুমতি দেয়, কারণ তাদের নিজস্ব build.gradle ফাইল থাকতে পারে। শুধুমাত্র পরীক্ষার জন্য প্রাসঙ্গিক কনফিগারেশন সহ আপনাকে আপনার অ্যাপ মডিউলের build.gradle ফাইলে বিশৃঙ্খলা করতে হবে না।

• ইন্টিগ্রেশন টেস্ট : টেস্ট মডিউলগুলি ইন্টিগ্রেশন টেস্টগুলি সঞ্চয় করতে ব্যবহার করা যেতে পারে যা ব্যবহারকারীর ইন্টারফেস, ব্যবসায়িক যুক্তি, নেটওয়ার্ক অনুরোধ এবং ডাটাবেস কোয়েরি সহ আপনার অ্যাপের বিভিন্ন অংশের মধ্যে মিথস্ক্রিয়া পরীক্ষা করতে ব্যবহৃত হয়।

• বড় আকারের অ্যাপ্লিকেশন : টেস্ট মডিউলগুলি জটিল কোডবেস এবং একাধিক মডিউল সহ বড় আকারের অ্যাপ্লিকেশনগুলির জন্য বিশেষভাবে কার্যকর। এই ধরনের ক্ষেত্রে, পরীক্ষার মডিউলগুলি কোড সংগঠন এবং রক্ষণাবেক্ষণযোগ্যতা উন্নত করতে সাহায্য করতে পারে।

মডিউল থেকে মডিউল যোগাযোগ

মডিউলগুলি খুব কমই মোট বিচ্ছেদে বিদ্যমান এবং প্রায়শই অন্যান্য মডিউলের উপর নির্ভর করে এবং তাদের সাথে যোগাযোগ করে। মডিউল একসাথে কাজ করলে এবং ঘন ঘন তথ্য আদান-প্রদান করলেও কাপলিং কম রাখা গুরুত্বপূর্ণ। কখনও কখনও দুটি মডিউলের মধ্যে সরাসরি যোগাযোগ হয় আর্কিটেকচারের সীমাবদ্ধতার ক্ষেত্রে পছন্দসই নয়। এটি অসম্ভবও হতে পারে, যেমন চক্রাকার নির্ভরতার সাথে।

এই সমস্যাটি কাটিয়ে উঠতে আপনি একটি তৃতীয় মডিউল থাকতে পারেন যা অন্য দুটি মডিউলের মধ্যে মধ্যস্থতা করে । মধ্যস্থতাকারী মডিউল উভয় মডিউল থেকে বার্তা শুনতে এবং প্রয়োজনে সেগুলি ফরোয়ার্ড করতে পারে। আমাদের নমুনা অ্যাপে, চেকআউট স্ক্রীনটি জানতে হবে কোন বইটি কিনবেন যদিও ইভেন্টটি একটি আলাদা স্ক্রীন থেকে শুরু হয়েছে যা একটি ভিন্ন বৈশিষ্ট্যের অংশ। এই ক্ষেত্রে, মধ্যস্থতাকারী হল সেই মডিউল যা নেভিগেশন গ্রাফের মালিক (সাধারণত একটি অ্যাপ মডিউল)। উদাহরণে, আমরা নেভিগেশন উপাদান ব্যবহার করে হোম বৈশিষ্ট্য থেকে চেকআউট বৈশিষ্ট্যে ডেটা পাস করতে নেভিগেশন ব্যবহার করি।

navController.navigate("checkout/$bookId")

চেকআউট গন্তব্য একটি আর্গুমেন্ট হিসাবে একটি বই আইডি পায় যা এটি বই সম্পর্কে তথ্য আনতে ব্যবহার করে। আপনি একটি গন্তব্য বৈশিষ্ট্যের ViewModel এর মধ্যে নেভিগেশন আর্গুমেন্ট পুনরুদ্ধার করতে সংরক্ষিত স্টেট হ্যান্ডেল ব্যবহার করতে পারেন।

class CheckoutViewModel(savedStateHandle: SavedStateHandle, …) : ViewModel() {

   val uiState: StateFlow<CheckoutUiState> =
      savedStateHandle.getStateFlow<String>("bookId", "").map { bookId ->
          // produce UI state calling bookRepository.getBook(bookId)
      }
      …
}

আপনি নেভিগেশন আর্গুমেন্ট হিসাবে বস্তু পাস করা উচিত নয়. পরিবর্তে, সাধারণ আইডিগুলি ব্যবহার করুন যা বৈশিষ্ট্যগুলি ডেটা স্তর থেকে পছন্দসই সংস্থানগুলি অ্যাক্সেস এবং লোড করতে ব্যবহার করতে পারে৷ এইভাবে, আপনি কাপলিং কম রাখবেন এবং সত্য নীতির একক উৎস লঙ্ঘন করবেন না।

নীচের উদাহরণে, উভয় বৈশিষ্ট্য মডিউল একই ডেটা মডিউলের উপর নির্ভর করে। এটি মধ্যস্থতাকারী মডিউলকে ফরোয়ার্ড করার জন্য প্রয়োজনীয় ডেটার পরিমাণ কমিয়ে আনা সম্ভব করে এবং মডিউলগুলির মধ্যে সংযোগ কম রাখে। বস্তুগুলি পাস করার পরিবর্তে, মডিউলগুলিকে আদিম আইডি বিনিময় করা উচিত এবং একটি ভাগ করা ডেটা মডিউল থেকে সংস্থানগুলি লোড করা উচিত।

নির্ভরতা বিপরীত

যখন আপনি আপনার কোডটি এমনভাবে সাজান যাতে বিমূর্ততা একটি কংক্রিট বাস্তবায়ন থেকে আলাদা হয়।

• বিমূর্ততা : একটি চুক্তি যা সংজ্ঞায়িত করে কিভাবে আপনার অ্যাপ্লিকেশনের উপাদান বা মডিউল একে অপরের সাথে ইন্টারঅ্যাক্ট করে। বিমূর্ততা মডিউল আপনার সিস্টেমের API সংজ্ঞায়িত করে এবং ইন্টারফেস এবং মডেল ধারণ করে।
• কংক্রিট বাস্তবায়ন : মডিউল যা বিমূর্তকরণ মডিউলের উপর নির্ভর করে এবং একটি বিমূর্ততার আচরণ বাস্তবায়ন করে।

যে মডিউলগুলি বিমূর্তকরণ মডিউলে সংজ্ঞায়িত আচরণের উপর নির্ভর করে সেগুলি নির্দিষ্ট বাস্তবায়নের পরিবর্তে শুধুমাত্র বিমূর্ততার উপর নির্ভর করে।

উদাহরণ

একটি বৈশিষ্ট্য মডিউল কল্পনা করুন যে কাজ করার জন্য একটি ডাটাবেস প্রয়োজন. বৈশিষ্ট্য মডিউলটি কীভাবে ডাটাবেস প্রয়োগ করা হয় তা নিয়ে উদ্বিগ্ন নয়, এটি একটি স্থানীয় রুম ডাটাবেস বা দূরবর্তী ফায়ারস্টোর উদাহরণ হতে পারে। এটি শুধুমাত্র অ্যাপ্লিকেশন ডেটা সংরক্ষণ এবং পড়তে হবে।

এটি অর্জন করতে, বৈশিষ্ট্য মডিউল একটি নির্দিষ্ট ডাটাবেস বাস্তবায়নের পরিবর্তে বিমূর্তকরণ মডিউলের উপর নির্ভর করে। এই বিমূর্ততা অ্যাপের ডাটাবেস APIকে সংজ্ঞায়িত করে। অন্য কথায়, এটি ডাটাবেসের সাথে কীভাবে ইন্টারঅ্যাক্ট করতে হয় তার নিয়ম সেট করে। এটি বৈশিষ্ট্য মডিউলটিকে তার অন্তর্নিহিত বাস্তবায়নের বিশদ জানার প্রয়োজন ছাড়াই যেকোনো ডাটাবেস ব্যবহার করার অনুমতি দেয়।

কংক্রিট বাস্তবায়ন মডিউল বিমূর্তকরণ মডিউলে সংজ্ঞায়িত API-এর প্রকৃত বাস্তবায়ন প্রদান করে। এটি করার জন্য, বাস্তবায়ন মডিউলটি বিমূর্তকরণ মডিউলের উপরও নির্ভর করে।

ইনজেকশন নির্ভরতা

এখন পর্যন্ত আপনি ভাবছেন কিভাবে বৈশিষ্ট্য মডিউল বাস্তবায়ন মডিউল সঙ্গে সংযুক্ত করা হয়. উত্তর হল ডিপেনডেন্সি ইনজেকশন । বৈশিষ্ট্য মডিউল সরাসরি প্রয়োজনীয় ডাটাবেস উদাহরণ তৈরি করে না। পরিবর্তে, এটি কোন নির্ভরতা প্রয়োজন তা নির্দিষ্ট করে। এই নির্ভরতাগুলি তখন বাহ্যিকভাবে সরবরাহ করা হয়, সাধারণত অ্যাপ মডিউলে ।

releaseImplementation(project(":database:impl:firestore"))

debugImplementation(project(":database:impl:room"))

androidTestImplementation(project(":database:impl:mock"))

সুবিধা

আপনার API গুলি আলাদা করার সুবিধা এবং তাদের বাস্তবায়ন নিম্নরূপ:

• বিনিময়যোগ্যতা : API এবং বাস্তবায়ন মডিউলগুলির একটি স্পষ্ট বিচ্ছেদ সহ, আপনি একই API এর জন্য একাধিক বাস্তবায়ন বিকাশ করতে পারেন এবং API ব্যবহার করে এমন কোড পরিবর্তন না করে তাদের মধ্যে স্যুইচ করতে পারেন। এটি এমন পরিস্থিতিতে বিশেষভাবে উপকারী হতে পারে যেখানে আপনি বিভিন্ন প্রসঙ্গে বিভিন্ন ক্ষমতা বা আচরণ প্রদান করতে চান। উদাহরণস্বরূপ, পরীক্ষার জন্য একটি উপহাস বাস্তবায়ন বনাম উত্পাদনের জন্য একটি বাস্তব বাস্তবায়ন।
• Decoupling : বিচ্ছেদ মানে বিমূর্ততা ব্যবহার করে মডিউল কোনো নির্দিষ্ট প্রযুক্তির উপর নির্ভর করে না। আপনি যদি পরবর্তীতে আপনার ডাটাবেসকে রুম থেকে ফায়ারস্টোরে পরিবর্তন করতে চান তবে এটি সহজ হবে কারণ পরিবর্তনগুলি শুধুমাত্র কাজটি করা নির্দিষ্ট মডিউলে ঘটবে (বাস্তবায়ন মডিউল) এবং আপনার ডাটাবেসের API ব্যবহার করে অন্য মডিউলগুলিকে প্রভাবিত করবে না।
• পরীক্ষাযোগ্যতা : API গুলিকে তাদের বাস্তবায়ন থেকে আলাদা করা পরীক্ষাকে ব্যাপকভাবে সহজতর করতে পারে। আপনি API চুক্তির বিরুদ্ধে পরীক্ষার মামলা লিখতে পারেন। আপনি উপহাস বাস্তবায়ন সহ বিভিন্ন পরিস্থিতি এবং প্রান্তের ক্ষেত্রে পরীক্ষা করতে বিভিন্ন বাস্তবায়ন ব্যবহার করতে পারেন।
• উন্নত বিল্ড পারফরম্যান্স : আপনি যখন একটি API এবং এর বাস্তবায়নকে বিভিন্ন মডিউলে আলাদা করেন, তখন বাস্তবায়ন মডিউলের পরিবর্তনগুলি API মডিউলের উপর নির্ভর করে বিল্ড সিস্টেমকে মডিউলগুলি পুনরায় কম্পাইল করতে বাধ্য করে না। এটি দ্রুত নির্মাণের সময় এবং উত্পাদনশীলতা বৃদ্ধির দিকে পরিচালিত করে, বিশেষত বড় প্রকল্পগুলিতে যেখানে নির্মাণের সময়গুলি উল্লেখযোগ্য হতে পারে।

কখন আলাদা করতে হবে

নিম্নলিখিত ক্ষেত্রে আপনার APIগুলিকে তাদের বাস্তবায়ন থেকে আলাদা করা উপকারী:

• বিভিন্ন ক্ষমতা : আপনি যদি আপনার সিস্টেমের অংশগুলিকে একাধিক উপায়ে প্রয়োগ করতে পারেন, একটি পরিষ্কার API বিভিন্ন বাস্তবায়নের বিনিময়যোগ্যতার অনুমতি দেয়। উদাহরণস্বরূপ, আপনার কাছে একটি রেন্ডারিং সিস্টেম থাকতে পারে যা OpenGL বা Vulkan ব্যবহার করে, অথবা একটি বিলিং সিস্টেম যা Play বা আপনার ইন-হাউস বিলিং API এর সাথে কাজ করে।
• একাধিক অ্যাপ্লিকেশন : আপনি যদি বিভিন্ন প্ল্যাটফর্মের জন্য ভাগ করা ক্ষমতা সহ একাধিক অ্যাপ্লিকেশন বিকাশ করেন তবে আপনি সাধারণ API সংজ্ঞায়িত করতে পারেন এবং প্রতি প্ল্যাটফর্মের জন্য নির্দিষ্ট বাস্তবায়ন বিকাশ করতে পারেন।
• স্বাধীন দল : বিচ্ছেদ বিভিন্ন ডেভেলপার বা দলকে একই সাথে কোডবেসের বিভিন্ন অংশে কাজ করার অনুমতি দেয়। ডেভেলপারদের এপিআই কন্ট্রাক্ট বোঝার এবং সঠিকভাবে ব্যবহার করার উপর ফোকাস করা উচিত। তাদের অন্যান্য মডিউলগুলির বাস্তবায়নের বিশদ সম্পর্কে চিন্তা করার দরকার নেই।
• বড় কোডবেস : যখন কোডবেস বড় বা জটিল হয়, তখন এপিআইকে বাস্তবায়ন থেকে আলাদা করা কোডটিকে আরও পরিচালনাযোগ্য করে তোলে। এটি আপনাকে কোডবেসকে আরও দানাদার, বোধগম্য এবং রক্ষণাবেক্ষণযোগ্য ইউনিটে ভাঙ্গতে দেয়।

কিভাবে বাস্তবায়ন করবেন?

নির্ভরতা ইনভার্সন বাস্তবায়ন করতে, এই পদক্ষেপগুলি অনুসরণ করুন:

1. একটি বিমূর্ততা মডিউল তৈরি করুন : এই মডিউলটিতে API (ইন্টারফেস এবং মডেল) থাকা উচিত যা আপনার বৈশিষ্ট্যের আচরণকে সংজ্ঞায়িত করে।
2. বাস্তবায়ন মডিউল তৈরি করুন : বাস্তবায়ন মডিউলগুলিকে API মডিউলের উপর নির্ভর করতে হবে এবং একটি বিমূর্ততার আচরণ বাস্তবায়ন করতে হবে।

   

3. উচ্চ স্তরের মডিউলগুলিকে বিমূর্তকরণ মডিউলের উপর নির্ভরশীল করুন : একটি নির্দিষ্ট বাস্তবায়নের উপর সরাসরি নির্ভর করার পরিবর্তে, আপনার মডিউলগুলিকে বিমূর্তকরণ মডিউলের উপর নির্ভরশীল করুন। উচ্চ স্তরের মডিউলগুলিকে বাস্তবায়নের বিশদ জানতে হবে না, তাদের শুধুমাত্র চুক্তি (API) প্রয়োজন।

   

4. বাস্তবায়ন মডিউল প্রদান করুন : অবশেষে, আপনাকে আপনার নির্ভরতার জন্য প্রকৃত বাস্তবায়ন প্রদান করতে হবে। নির্দিষ্ট বাস্তবায়ন আপনার প্রকল্প সেটআপের উপর নির্ভর করে, তবে অ্যাপ মডিউল সাধারণত এটি করার জন্য একটি ভাল জায়গা। বাস্তবায়ন প্রদানের জন্য এটিকে আপনার নির্বাচিত বিল্ড বৈকল্পিক বা একটি টেস্টিং সোর্স সেটের জন্য নির্ভরতা হিসাবে উল্লেখ করুন।

   

সাধারণ সর্বোত্তম অনুশীলন

শুরুতে উল্লিখিত হিসাবে একটি মাল্টি-মডিউল অ্যাপ্লিকেশন বিকাশের কোন একক সঠিক উপায় নেই। যেমন অনেক সফ্টওয়্যার আর্কিটেকচার রয়েছে, তেমনি একটি অ্যাপকে মডুলারাইজ করার অনেক উপায় রয়েছে। তবুও, নিম্নলিখিত সাধারণ সুপারিশগুলি আপনাকে আপনার কোডকে আরও পঠনযোগ্য, রক্ষণাবেক্ষণযোগ্য এবং পরীক্ষাযোগ্য করতে সাহায্য করতে পারে।

আপনার কনফিগারেশন সামঞ্জস্যপূর্ণ রাখুন

প্রতিটি মডিউল কনফিগারেশন ওভারহেড প্রবর্তন করে। যদি আপনার মডিউলের সংখ্যা একটি নির্দিষ্ট থ্রেশহোল্ডে পৌঁছে যায়, তাহলে সামঞ্জস্যপূর্ণ কনফিগারেশন পরিচালনা করা একটি চ্যালেঞ্জ হয়ে দাঁড়ায়। উদাহরণস্বরূপ, এটি গুরুত্বপূর্ণ যে মডিউলগুলি একই সংস্করণের নির্ভরতা ব্যবহার করে। শুধুমাত্র একটি নির্ভরতা সংস্করণ বাম্প করার জন্য আপনাকে যদি প্রচুর সংখ্যক মডিউল আপডেট করতে হয়, তবে এটি শুধুমাত্র একটি প্রচেষ্টা নয়, সম্ভাব্য ভুলের জন্যও একটি রুম। এই সমস্যাটি সমাধান করতে, আপনি আপনার কনফিগারেশনকে কেন্দ্রীভূত করতে gradle এর টুলগুলির একটি ব্যবহার করতে পারেন:

• সংস্করণ ক্যাটালগগুলি সিঙ্কের সময় Gradle দ্বারা উত্পন্ন নির্ভরতার একটি প্রকার নিরাপদ তালিকা। এটি আপনার সমস্ত নির্ভরতা ঘোষণা করার একটি কেন্দ্রীয় স্থান এবং একটি প্রকল্পের সমস্ত মডিউলের জন্য উপলব্ধ।
• মডিউলগুলির মধ্যে বিল্ড লজিক শেয়ার করতে কনভেনশন প্লাগইনগুলি ব্যবহার করুন৷

যতটা সম্ভব কম প্রকাশ করুন

একটি মডিউলের সর্বজনীন ইন্টারফেস ন্যূনতম হওয়া উচিত এবং শুধুমাত্র প্রয়োজনীয় জিনিসগুলি প্রকাশ করা উচিত। এটির বাইরে কোনো বাস্তবায়ন বিবরণ ফাঁস করা উচিত নয়। সম্ভাব্য ক্ষুদ্রতম পরিমাণে সবকিছু ব্যাপ্তি করুন। ঘোষণা মডিউল-ব্যক্তিগত করতে Kotlin এর private বা internal দৃশ্যমানতার সুযোগ ব্যবহার করুন। আপনার মডিউলে নির্ভরতা ঘোষণা করার সময়, api এর চেয়ে implementation পছন্দ করুন। পরেরটি আপনার মডিউলের ভোক্তাদের কাছে ট্রানজিটিভ নির্ভরতা প্রকাশ করে। বাস্তবায়ন ব্যবহার করা বিল্ড টাইম উন্নত করতে পারে কারণ এটি পুনঃনির্মাণ করা দরকার এমন মডিউলের সংখ্যা হ্রাস করে।

কোটলিন এবং জাভা মডিউল পছন্দ করুন

তিনটি অপরিহার্য ধরনের মডিউল রয়েছে যা অ্যান্ড্রয়েড স্টুডিও সমর্থন করে:

• অ্যাপ মডিউলগুলি আপনার অ্যাপ্লিকেশনের একটি এন্ট্রি পয়েন্ট। এগুলিতে সোর্স কোড, সংস্থান, সম্পদ এবং একটি AndroidManifest.xml থাকতে পারে। একটি অ্যাপ মডিউলের আউটপুট একটি অ্যান্ড্রয়েড অ্যাপ বান্ডেল (এএবি) বা একটি অ্যান্ড্রয়েড অ্যাপ্লিকেশন প্যাকেজ (এপিকে)।
• লাইব্রেরি মডিউলগুলিতে অ্যাপ মডিউলগুলির মতো একই সামগ্রী রয়েছে৷ এগুলি অন্যান্য অ্যান্ড্রয়েড মডিউলগুলি নির্ভরতা হিসাবে ব্যবহার করে। একটি লাইব্রেরি মডিউলের আউটপুট হল একটি অ্যান্ড্রয়েড আর্কাইভ (AAR) কাঠামোগতভাবে অ্যাপ মডিউলগুলির সাথে অভিন্ন তবে সেগুলি একটি Android আর্কাইভ (AAR) ফাইলে কম্পাইল করা হয় যা পরবর্তীতে অন্যান্য মডিউলগুলি নির্ভরতা হিসাবে ব্যবহার করতে পারে৷ একটি লাইব্রেরি মডিউল অনেকগুলি অ্যাপ মডিউল জুড়ে একই যুক্তি এবং সংস্থানগুলিকে এনক্যাপসুলেট এবং পুনরায় ব্যবহার করা সম্ভব করে তোলে।
• কোটলিন এবং জাভা লাইব্রেরিতে কোনো Android সম্পদ, সম্পদ, বা ম্যানিফেস্ট ফাইল নেই।

যেহেতু অ্যান্ড্রয়েড মডিউলগুলি ওভারহেডের সাথে আসে, বিশেষত, আপনি যতটা সম্ভব কোটলিন বা জাভা ধরনের ব্যবহার করতে চান।