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

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

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

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

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

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

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

ডেটা মডিউল

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

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

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

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

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

অ্যাপ মডিউল

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

যদি আপনার অ্যাপটি একাধিক ডিভাইসের ধরণকে লক্ষ্য করে, যেমন Android Auto, Wear বা TV, তাহলে প্রতিটির জন্য একটি অ্যাপ মডিউল নির্ধারণ করুন। এটি প্ল্যাটফর্ম-নির্দিষ্ট নির্ভরতা পৃথক করতে সাহায্য করে।

সাধারণ মডিউল

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

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

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

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

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

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

• শেয়ার্ড টেস্ট কোড : যদি আপনার প্রোজেক্টে একাধিক মডিউল থাকে এবং কিছু টেস্ট কোড একাধিক মডিউলের জন্য প্রযোজ্য হয়, তাহলে আপনি কোডটি শেয়ার করার জন্য একটি টেস্ট মডিউল তৈরি করতে পারেন। এটি ডুপ্লিকেশন কমাতে সাহায্য করতে পারে এবং আপনার টেস্ট কোডটি রক্ষণাবেক্ষণ করা সহজ করে তুলতে পারে। শেয়ার্ড টেস্ট কোডে ইউটিলিটি ক্লাস বা ফাংশন, যেমন কাস্টম অ্যাসারশন বা ম্যাচার, সেইসাথে সিমুলেটেড 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 ব্যবহার করে এমন কোড পরিবর্তন না করেই তাদের মধ্যে স্যুইচ করতে পারেন। এটি বিশেষভাবে এমন পরিস্থিতিতে উপকারী হতে পারে যেখানে আপনি বিভিন্ন প্রসঙ্গে বিভিন্ন ক্ষমতা বা আচরণ প্রদান করতে চান। উদাহরণস্বরূপ, পরীক্ষার জন্য একটি মক বাস্তবায়ন বনাম উৎপাদনের জন্য একটি বাস্তব বাস্তবায়ন।
• ডিকাপলিং : বিভাজনের অর্থ হল বিমূর্তকরণ ব্যবহার করে মডিউলগুলি কোনও নির্দিষ্ট প্রযুক্তির উপর নির্ভর করে না। আপনি যদি পরে আপনার ডাটাবেসটি রুম থেকে ফায়ারস্টোরে পরিবর্তন করতে চান, তবে এটি আরও সহজ হবে কারণ পরিবর্তনগুলি কেবলমাত্র নির্দিষ্ট মডিউলে (বাস্তবায়ন মডিউল) কাজটি করবে এবং আপনার ডাটাবেসের API ব্যবহার করে অন্যান্য মডিউলগুলিকে প্রভাবিত করবে না।
• টেস্টেবিলিটি : API গুলিকে তাদের বাস্তবায়ন থেকে আলাদা করলে পরীক্ষা করা অনেক সহজ হতে পারে। আপনি API চুক্তির বিরুদ্ধে টেস্ট কেস লিখতে পারেন। আপনি বিভিন্ন পরিস্থিতি এবং এজ কেস পরীক্ষা করার জন্য বিভিন্ন বাস্তবায়ন ব্যবহার করতে পারেন, যার মধ্যে মক বাস্তবায়নও অন্তর্ভুক্ত।
• উন্নত বিল্ড পারফরম্যান্স : যখন আপনি একটি API এবং এর বাস্তবায়নকে বিভিন্ন মডিউলে আলাদা করেন, তখন বাস্তবায়ন মডিউলের পরিবর্তনগুলি API মডিউলের উপর নির্ভর করে বিল্ড সিস্টেমকে মডিউলগুলি পুনরায় কম্পাইল করতে বাধ্য করে না। এর ফলে দ্রুত বিল্ড সময় এবং উৎপাদনশীলতা বৃদ্ধি পায়, বিশেষ করে বৃহৎ প্রকল্পগুলিতে যেখানে বিল্ড সময় উল্লেখযোগ্য হতে পারে।

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

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

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

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

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

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

   

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

   

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

   

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

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

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

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

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

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

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

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

অ্যান্ড্রয়েড স্টুডিও তিনটি গুরুত্বপূর্ণ ধরণের মডিউল সমর্থন করে:

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

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