সেভ করা পৃষ্ঠা গুছিয়ে রাখতে 'সংগ্রহ' ব্যবহার করুন
আপনার পছন্দ অনুযায়ী কন্টেন্ট সেভ করুন ও সঠিক বিভাগে রাখুন।
একাধিক Gradle মডিউল সহ একটি প্রকল্প একটি মাল্টি-মডিউল প্রকল্প হিসাবে পরিচিত। এই নির্দেশিকাটি মাল্টি-মডিউল অ্যান্ড্রয়েড অ্যাপ্লিকেশানগুলি বিকাশের জন্য সর্বোত্তম অনুশীলন এবং প্রস্তাবিত নিদর্শনগুলিকে অন্তর্ভুক্ত করে৷
ক্রমবর্ধমান কোডবেস সমস্যা
একটি ক্রমবর্ধমান কোডবেসে, স্কেলেবিলিটি, পঠনযোগ্যতা এবং সামগ্রিক কোডের গুণমান প্রায়ই সময়ের সাথে সাথে হ্রাস পায়। কোডবেস আকারে বৃদ্ধি পাওয়ার ফলে এটির রক্ষণাবেক্ষণকারীরা সহজে রক্ষণাবেক্ষণযোগ্য একটি কাঠামো কার্যকর করার জন্য সক্রিয় ব্যবস্থা গ্রহণ না করে। মডুলারাইজেশন হল আপনার কোডবেসকে এমনভাবে গঠন করার একটি উপায় যা রক্ষণাবেক্ষণের উন্নতি করে এবং এই সমস্যাগুলি এড়াতে সাহায্য করে।
মডুলারাইজেশন কি?
মডুলারাইজেশন হল একটি কোডবেসকে আলগাভাবে জোড়া এবং স্বয়ংসম্পূর্ণ অংশে সংগঠিত করার একটি অনুশীলন। প্রতিটি অংশ একটি মডিউল. প্রতিটি মডিউল স্বাধীন এবং একটি পরিষ্কার উদ্দেশ্য পরিবেশন করে। একটি সমস্যাকে ছোট এবং সহজে সমাধান করার জন্য উপ-সমস্যাগুলিকে ভাগ করে, আপনি একটি বড় সিস্টেম ডিজাইন এবং রক্ষণাবেক্ষণের জটিলতা হ্রাস করেন।
চিত্র 1 : একটি নমুনা মাল্টি-মডিউল কোডবেসের নির্ভরতা গ্রাফ
মডুলারাইজেশনের সুবিধা
মডুলারাইজেশনের সুবিধাগুলি অনেক, যদিও তারা প্রতিটি কোডবেসের রক্ষণাবেক্ষণযোগ্যতা এবং সামগ্রিক গুণমান উন্নত করার উপর কেন্দ্র করে। নিম্নলিখিত সারণী মূল সুবিধাগুলি সংক্ষিপ্ত করে।
সুবিধা
সারাংশ
পুনর্ব্যবহারযোগ্যতা
মডুলারাইজেশন কোড শেয়ারিং এবং একই ফাউন্ডেশন থেকে একাধিক অ্যাপ তৈরি করার সুযোগ সক্ষম করে। মডিউলগুলি কার্যকরভাবে ব্লক তৈরি করছে। অ্যাপগুলি তাদের বৈশিষ্ট্যগুলির সমষ্টি হওয়া উচিত যেখানে বৈশিষ্ট্যগুলি পৃথক মডিউল হিসাবে সংগঠিত হয়৷ একটি নির্দিষ্ট মডিউল যে কার্যকারিতা প্রদান করে তা একটি নির্দিষ্ট অ্যাপে সক্ষম হতে পারে বা নাও হতে পারে। উদাহরণস্বরূপ, একটি :feature:news সম্পূর্ণ সংস্করণের ফ্লেভার এবং পরিধান অ্যাপের একটি অংশ হতে পারে কিন্তু ডেমো সংস্করণের স্বাদের অংশ নয়৷
কঠোর দৃশ্যমানতা নিয়ন্ত্রণ
মডিউলগুলি আপনাকে আপনার কোডবেসের অন্যান্য অংশে আপনি কী প্রকাশ করেন তা সহজেই নিয়ন্ত্রণ করতে সক্ষম করে। মডিউলের বাইরে ব্যবহার করা থেকে বিরত রাখতে আপনি আপনার সর্বজনীন ইন্টারফেসকে internal বা private হিসাবে চিহ্নিত করতে পারেন।
কাস্টমাইজযোগ্য ডেলিভারি
প্লে ফিচার ডেলিভারি অ্যাপ বান্ডেলের উন্নত ক্ষমতা ব্যবহার করে, যা আপনাকে শর্তসাপেক্ষে বা চাহিদা অনুযায়ী আপনার অ্যাপের নির্দিষ্ট কিছু বৈশিষ্ট্য সরবরাহ করতে দেয়।
মডুলারাইজেশনের সুবিধাগুলি শুধুমাত্র একটি মডুলারাইজড কোডবেস দিয়ে অর্জন করা যায়। নিম্নলিখিত সুবিধাগুলি অন্যান্য কৌশলগুলির সাথে অর্জন করা যেতে পারে তবে মডুলারাইজেশন আপনাকে সেগুলি আরও কার্যকর করতে সহায়তা করতে পারে।
সুবিধা
সারাংশ
পরিমাপযোগ্যতা
একটি শক্তভাবে সংযুক্ত কোডবেসে একটি একক পরিবর্তন কোডের আপাতদৃষ্টিতে সম্পর্কহীন অংশগুলিতে পরিবর্তনের ক্যাসকেড ট্রিগার করতে পারে। একটি সঠিকভাবে মডুলারাইজড প্রকল্প উদ্বেগের বিচ্ছেদ নীতিকে আলিঙ্গন করবে এবং তাই কাপলিংকে সীমিত করবে। এটি বৃহত্তর স্বায়ত্তশাসনের মাধ্যমে অবদানকারীদের ক্ষমতায়ন করে।
মালিকানা
স্বায়ত্তশাসন সক্ষম করার পাশাপাশি, জবাবদিহিতা প্রয়োগ করতে মডিউলগুলিও ব্যবহার করা যেতে পারে। একটি মডিউলের একজন নিবেদিত মালিক থাকতে পারে যিনি কোডটি রক্ষণাবেক্ষণের জন্য, বাগগুলি সংশোধন করার জন্য, পরীক্ষাগুলি যোগ করার জন্য এবং পরিবর্তনগুলি পর্যালোচনা করার জন্য দায়ী৷
এনক্যাপসুলেশন
এনক্যাপসুলেশন মানে আপনার কোডের প্রতিটি অংশে অন্যান্য অংশ সম্পর্কে জ্ঞানের সর্বনিম্ন পরিমাণে থাকা উচিত। বিচ্ছিন্ন কোড পড়া এবং বোঝা সহজ।
পরীক্ষাযোগ্যতা
পরীক্ষাযোগ্যতা আপনার কোড পরীক্ষা করা কতটা সহজ তা চিহ্নিত করে। একটি পরীক্ষাযোগ্য কোডবেস হল এমন একটি যেখানে উপাদানগুলি সহজেই বিচ্ছিন্নভাবে পরীক্ষা করা যেতে পারে।
সময় বিল্ড
কিছু গ্রেডল কার্যকারিতা যেমন ক্রমবর্ধমান বিল্ড, বিল্ড ক্যাশে বা সমান্তরাল বিল্ড, বিল্ড কর্মক্ষমতা উন্নত করতে মডুলারিটি লিভারেজ করতে পারে।
সাধারণ ক্ষতি
আপনার কোডবেসের গ্রানুলারিটি হল এটি কতটা মডিউল নিয়ে গঠিত। একটি আরও দানাদার কোডবেসে আরও, ছোট মডিউল রয়েছে। একটি মডুলারাইজড কোডবেস ডিজাইন করার সময়, আপনার গ্রানুলারিটির একটি স্তরের বিষয়ে সিদ্ধান্ত নেওয়া উচিত। এটি করার জন্য, আপনার কোডবেসের আকার এবং এর আপেক্ষিক জটিলতা বিবেচনা করুন। খুব সূক্ষ্ম দানাদার হওয়া ওভারহেডকে একটি বোঝা করে তুলবে, এবং খুব মোটা হওয়া মডুলারাইজেশনের সুবিধাগুলিকে কমিয়ে দেবে।
কিছু সাধারণ ত্রুটি নিম্নরূপ:
খুব সূক্ষ্ম দানাদার : প্রতিটি মডিউল বর্ধিত বিল্ড জটিলতা এবং বয়লারপ্লেট কোড আকারে একটি নির্দিষ্ট পরিমাণ ওভারহেড নিয়ে আসে। একটি জটিল বিল্ড কনফিগারেশন মডিউল জুড়ে কনফিগারেশনগুলিকে সামঞ্জস্যপূর্ণ রাখা কঠিন করে তোলে। অত্যধিক বয়লারপ্লেট কোডের ফলে একটি কষ্টকর কোডবেস যা বজায় রাখা কঠিন। যদি ওভারহেড স্কেলেবিলিটি উন্নতির প্রতিরোধ করে, আপনার কিছু মডিউল একত্রিত করার কথা বিবেচনা করা উচিত।
খুব মোটা দানাযুক্ত : বিপরীতভাবে, যদি আপনার মডিউলগুলি খুব বড় হয় তবে আপনি আরও একটি মনোলিথের সাথে শেষ করতে পারেন এবং মডুলারিটির অফার করা সুবিধাগুলি মিস করতে পারেন৷ উদাহরণস্বরূপ, একটি ছোট প্রকল্পে একটি একক মডিউলের মধ্যে ডেটা স্তর রাখা ঠিক। কিন্তু এটি বাড়ার সাথে সাথে সংগ্রহস্থল এবং ডেটা উত্সগুলিকে স্বতন্ত্র মডিউলগুলিতে আলাদা করার প্রয়োজন হতে পারে।
খুব জটিল : আপনার প্রকল্পটিকে মডুলারাইজ করার জন্য এটি সর্বদা অর্থপূর্ণ নয়। একটি প্রভাবশালী ফ্যাক্টর হল কোডবেসের আকার। আপনি যদি আপনার প্রকল্পটি একটি নির্দিষ্ট থ্রেশহোল্ড অতিক্রম করার আশা না করেন তবে স্কেলেবিলিটি এবং বিল্ড টাইম লাভ প্রযোজ্য হবে না।
মডুলারাইজেশন কি আমার জন্য সঠিক কৌশল?
আপনার যদি পুনঃব্যবহারযোগ্যতা, কঠোর দৃশ্যমানতা নিয়ন্ত্রণ বা প্লে ফিচার ডেলিভারি ব্যবহার করার সুবিধার প্রয়োজন হয়, তাহলে মডুলারাইজেশন আপনার জন্য প্রয়োজনীয়। আপনি যদি না করেন, কিন্তু তারপরও উন্নত স্কেলেবিলিটি, মালিকানা, এনক্যাপসুলেশন বা বিল্ড টাইম থেকে উপকৃত হতে চান, তাহলে মডুলারাইজেশন বিবেচনা করার মতো কিছু।
নমুনা
এখন অ্যান্ড্রয়েডে - মডুলারাইজেশন সমন্বিত সম্পূর্ণরূপে কার্যকরী অ্যান্ড্রয়েড অ্যাপ৷
এই পৃষ্ঠার কন্টেন্ট ও কোডের নমুনাগুলি Content License-এ বর্ণিত লাইসেন্সের অধীনস্থ। Java এবং OpenJDK হল Oracle এবং/অথবা তার অ্যাফিলিয়েট সংস্থার রেজিস্টার্ড ট্রেডমার্ক।
2025-08-14 UTC-তে শেষবার আপডেট করা হয়েছে।
[[["সহজে বোঝা যায়","easyToUnderstand","thumb-up"],["আমার সমস্যার সমাধান হয়েছে","solvedMyProblem","thumb-up"],["অন্যান্য","otherUp","thumb-up"]],[["এতে আমার প্রয়োজনীয় তথ্য নেই","missingTheInformationINeed","thumb-down"],["খুব জটিল / অনেক ধাপ","tooComplicatedTooManySteps","thumb-down"],["পুরনো","outOfDate","thumb-down"],["অনুবাদ সংক্রান্ত সমস্যা","translationIssue","thumb-down"],["নমুনা / কোড সংক্রান্ত সমস্যা","samplesCodeIssue","thumb-down"],["অন্যান্য","otherDown","thumb-down"]],["2025-08-14 UTC-তে শেষবার আপডেট করা হয়েছে।"],[],[],null,["# Guide to Android app modularization\n\nA project with multiple Gradle modules is known as a multi-module project. This\nguide encompasses best practices and recommended patterns for developing\nmulti-module Android apps.\n| **Note:** This page assumes a basic familiarity with the [recommended app\n| architecture](/topic/architecture).\n\nThe growing codebase problem\n----------------------------\n\nIn an ever-growing codebase, scalability, readability, and overall code quality\noften decrease through time. This comes as a result of the codebase increasing\nin size without its maintainers taking active measures to enforce a structure\nthat is easily maintainable. Modularization is a means of structuring your\ncodebase in a way that improves maintainability and helps avoid these problems.\n\nWhat is modularization?\n-----------------------\n\nModularization is a practice of organizing a codebase into loosely coupled and\nself contained parts. Each part is a module. Each module is independent and\nserves a clear purpose. By dividing a problem into smaller and easier to solve\nsubproblems, you reduce the complexity of designing and maintaining a large\nsystem.\n**Figure 1**: Dependency graph of a sample multi-module codebase\n\nBenefits of modularization\n--------------------------\n\nThe benefits of modularization are many, though they each center upon improving\nthe maintainability and overall quality of a codebase. The following table\nsummarizes the key benefits.\n\n| Benefit | Summary |\n|---------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| Reusability | Modularization enables opportunities for code sharing and building multiple apps from the same foundation. Modules are effectively building blocks. Apps should be a sum of their features where the features are organized as separate modules. The functionality that a certain module provides may or may not be enabled in a particular app. For example, a `:feature:news` can be a part of the full version flavor and wear app but not part of the demo version flavor. |\n| Strict visibility control | Modules enable you to easily control what you expose to other parts of your codebase. You can mark everything but your public interface as `internal` or `private` to prevent it from being used outside the module. |\n| Customizable delivery | [Play Feature Delivery](/guide/playcore/feature-delivery) uses the advanced capabilities of app bundles, allowing you to deliver certain features of your app conditionally or on demand. |\n\nThe benefits of modularization are only achievable with a modularized codebase.\nThe following benefits might be achieved with other techniques but\nmodularization can help you enforce them even more.\n\n| Benefit | Summary |\n|---------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| Scalability | In a tightly coupled codebase a single change can trigger a cascade of alterations in seemingly unrelated parts of code. A properly modularized project will embrace the [separation of concerns](https://en.wikipedia.org/wiki/Separation_of_concerns) principle and therefore limit the coupling. This empowers the contributors through greater autonomy. |\n| Ownership | In addition to enabling autonomy, modules can also be used to enforce accountability. A module can have a dedicated owner who is responsible for maintaining the code, fixing bugs, adding tests, and reviewing changes. |\n| Encapsulation | Encapsulation means that each part of your code should have the smallest possible amount of knowledge about other parts. Isolated code is easier to read and understand. |\n| Testability | Testability characterizes how easy it is to [test](/training/testing) your code. A testable codebase is one where components can be easily tested in isolation. |\n| Build time | Some Gradle functionalities such as incremental build, build cache or parallel build, can leverage modularity to [improve build performance](/studio/build/optimize-your-build). |\n\nCommon pitfalls\n---------------\n\nThe granularity of your codebase is the extent to which it is composed of\nmodules. A more granular codebase has more, smaller modules. When designing a\nmodularized codebase, you should decide on a level of granularity. To do so,\ntake into account the size of your codebase and its relative complexity. Going\ntoo fine-grained will make the overhead a burden, and going too coarse will\nlessen the benefits of modularization.\n\nSome common pitfalls are as follows:\n\n- **Too fine-grained** : Every module brings a certain amount of overhead in the form of increased build complexity and [boilerplate code](https://en.wikipedia.org/wiki/Boilerplate_code). A complex build configuration makes it difficult to [keep configurations consistent](/topic/modularization/patterns#consistent-configuration) across modules. Too much boilerplate code results in a cumbersome codebase that is difficult to maintain. If overhead counteracts scalability improvements, you should consider consolidating some modules.\n- **Too coarse-grained**: Conversely, if your modules are growing too large you might end up with yet another monolith and miss the benefits that modularity has to offer. For example, in a small project it's ok to put the data layer inside a single module. But as it grows, it might be necessary to separate repositories and data sources into standalone modules.\n- **Too complex**: It doesn't always make sense to modularize your project. A dominating factor is the size of the codebase. If you don't expect your project to grow beyond a certain threshold, the scalability and build time gains won't apply.\n\nIs modularization the right technique for me?\n---------------------------------------------\n\nIf you need the benefits of reusability, strict visibility control or to use the\n[Play Feature Delivery](/guide/playcore/feature-delivery), then modularization is a necessity for you. If you\ndon't, but still want to benefit from improved scalability, ownership,\nencapsulation, or build times, then modularization is something worth\nconsidering.\n\nSamples\n-------\n\n- [Now in Android](https://github.com/android/nowinandroid) - fully functional Android app featuring modularization.\n- [Multi module architecture sample](https://github.com/android/architecture-samples/tree/multimodule)"]]