সঠিক আর্কিটেকচার প্যাটার্ন বাছাই করা
এই পাঠে যা শিখবেন
- চারটি সিদ্ধান্ত-নির্ধারক ফ্যাক্টর — টিমের আকার, জটিলতা, টেস্টেবিলিটি, প্ল্যাটফর্ম কনভেনশন
- একটি সত্যিকারের ওজনযুক্ত-মানদণ্ড স্কোরার ফাংশন লেখা ও চালানো
- দেখা যে একই মানদণ্ড-স্কোর সেট, ভিন্ন ওজন দিয়ে, সম্পূর্ণ ভিন্ন র্যাঙ্কিং তৈরি করতে পারে
- কেন এই ধরনের সিদ্ধান্ত-কাঠামো একটি সহায়ক হাতিয়ার, কিন্তু প্রতিস্থাপনযোগ্য "সত্য" নয়
১ · চারটি সিদ্ধান্ত-নির্ধারক ফ্যাক্টর
ছোট টিমে কম বয়লারপ্লেট ও দ্রুত শেখার প্যাটার্ন (MVC/MVVM) সুবিধাজনক; বড় টিমে কঠোর স্তরবিন্যাস (Clean Architecture) সমান্তরাল কাজ সহজ করে।
একটি সাধারণ, কয়েক-স্ক্রিনের অ্যাপে MVC-ই যথেষ্ট হতে পারে; জটিল, বহু-স্ক্রিন, বহু-স্টেট অ্যাপে MVI/Clean Architecture-এর কাঠামো ভবিষ্যতের রক্ষণাবেক্ষণ সহজ করে।
বিজনেস লজিক UI থেকে যত বেশি বিচ্ছিন্ন (MVVM/MVI/Clean Architecture), ইউনিট টেস্ট লেখা তত সহজ — L50-এ বিস্তারিত।
MVVM iOS ও Android উভয় প্ল্যাটফর্মেই idiomatic (L15-L16); MVI আধুনিক Android/Jetpack Compose কমিউনিটিতে বিশেষভাবে জনপ্রিয় (L16, L18)।
২ · একটি ওজনযুক্ত-মানদণ্ড স্কোরার — বাস্তব কোড
প্রতিটি প্যাটার্নের চারটি মানদণ্ডে (১-৫ স্কেলে, বেশি ভালো) একটি স্থির স্কোর ধরা হয়েছে — এগুলো L10-L13-এর
আলোচনার ভিত্তিতে যুক্তিসঙ্গত অনুমান, কোনো আনুষ্ঠানিক পরিমাপ নয়। চূড়ান্ত সুপারিশ
$$\text{স্কোর} = \sum_i w_i \cdot s_i$$
— অর্থাৎ প্রতিটি মানদণ্ডের স্কোরকে তার ওজন দিয়ে গুণ করে যোগফল বের করা হয়, যেখানে w_i হলো
মানদণ্ডটির ওজন (প্রজেক্টের অগ্রাধিকার) আর s_i হলো সেই মানদণ্ডে প্যাটার্নের স্কোর।
# প্রতিটি প্যাটার্নের মানদণ্ড-স্কোর (১-৫, বেশি ভালো) -- L10-L13-এর আলোচনার ভিত্তিতে
patterns = {
"MVC": {"testability": 2, "scalability": 2, "learning_curve": 5, "low_boilerplate": 4},
"MVVM": {"testability": 4, "scalability": 4, "learning_curve": 3, "low_boilerplate": 3},
"MVI": {"testability": 5, "scalability": 4, "learning_curve": 2, "low_boilerplate": 2},
"Clean Architecture": {"testability": 5, "scalability": 5, "learning_curve": 1, "low_boilerplate": 1},
}
def score_pattern(pattern_scores, weights):
return sum(weights[criterion] * pattern_scores[criterion] for criterion in weights)
def print_ranking(title, weights):
print(f"=== {title} ===")
print("অগ্রাধিকার (ওজন):", weights)
ranked = sorted(patterns.items(), key=lambda item: score_pattern(item[1], weights), reverse=True)
for rank, (name, scores) in enumerate(ranked, start=1):
total = score_pattern(scores, weights)
print(f" #{rank} {name:20s} স্কোর: {total:.2f}")
winner = ranked[0][0]
print(f"সুপারিশ: '{winner}'\n")
return winner
# ---------- প্রোফাইল ১: বড় টিম, দীর্ঘমেয়াদী প্রজেক্ট, উচ্চ-টেস্টেবিলিটি প্রয়োজন ----------
enterprise_weights = {
"testability": 0.35,
"scalability": 0.35,
"learning_curve": 0.10,
"low_boilerplate": 0.20,
}
winner_enterprise = print_ranking("প্রোফাইল ১ -- বড় টিম, দীর্ঘমেয়াদী, উচ্চ-টেস্টেবিলিটি", enterprise_weights)
# ---------- প্রোফাইল ২: ছোট টিম, দ্রুত প্রোটোটাইপ, টাইট ডেডলাইন ----------
prototype_weights = {
"testability": 0.10,
"scalability": 0.10,
"learning_curve": 0.40,
"low_boilerplate": 0.40,
}
winner_prototype = print_ranking("প্রোফাইল ২ -- ছোট টিম, দ্রুত প্রোটোটাইপ, টাইট ডেডলাইন", prototype_weights)
print(f"একই চারটি প্যাটার্নের একই মানদণ্ড-স্কোর, কিন্তু ভিন্ন ওজনে ভিন্ন বিজয়ী:")
print(f" প্রোফাইল ১ (এন্টারপ্রাইজ) -> {winner_enterprise}")
print(f" প্রোফাইল ২ (প্রোটোটাইপ) -> {winner_prototype}")patterns ডিকশনারির স্কোরগুলো একবারও বদলানো হয়নি — শুধু weights
বদলানোর কারণে প্রোফাইল ১-এ Clean Architecture (উচ্চ testability+scalability ওজনের
কারণে) শীর্ষে আসে, কিন্তু প্রোফাইল ২-এ MVC (উচ্চ learning_curve+low_boilerplate ওজনের
কারণে) শীর্ষে আসে — Clean Architecture তখন সবচেয়ে নিচে নেমে যায়, কারণ এর জটিলতা ও বয়লারপ্লেট একটি
দ্রুত প্রোটোটাইপে সুবিধার বদলে বোঝা হয়ে দাঁড়ায়। একই ফাংশন, একই ইনপুট ডেটা — শুধু অগ্রাধিকারের ওজন
পাল্টেই সম্পূর্ণ উল্টো সুপারিশ আসে।
একটি ওজনযুক্ত-মানদণ্ড স্কোরার সিদ্ধান্তকে স্বচ্ছ ও তুলনাযোগ্য করে তোলে — কিন্তু নিজেই কোনো "সঠিক" উত্তর তৈরি করে না। মানদণ্ডের স্কোর (প্যাটার্নটি কতটা টেস্টেবল, কতটা জটিল) ও ওজন (প্রজেক্টে কোনটা কতটা গুরুত্বপূর্ণ) — দুটোই বাস্তবে টিমের অভিজ্ঞতা ও প্রজেক্টের প্রেক্ষাপটের ওপর নির্ভরশীল মানবিক বিচার-বিবেচনা। হাতিয়ারটি আলোচনাকে কাঠামোবদ্ধ করে, বিতর্ককে দূর করে না।
ভাবনার প্রশ্ন
প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।
প্র ০১
উপরের কোডে learning_curve মানদণ্ডে MVC-এর স্কোর সবচেয়ে বেশি (৫) কেন?
কারণ MVC-এর ধারণাগত কাঠামো (Model/View/Controller, L10) সবচেয়ে সরল ও পরিচিত — কোনো
Observable/reducer/repository-ইন্টারফেসের মতো অতিরিক্ত ধারণা শিখতে হয় না। MVVM-এ Observable প্যাটার্ন
(L11), MVI-তে ইমিউটেবল State ও reducer (L12), আর Clean Architecture-এ একসাথে তিনটি লেয়ার ও abstract
ইন্টারফেস (L13) শিখতে হয় — তাই তাদের learning_curve স্কোর ক্রমান্বয়ে কম।
প্র ০২ যদি একটি প্রজেক্টে সবগুলো ওজন সমান (প্রতিটি ০.২৫) হতো, তাহলে কী কোনো একটি প্যাটার্ন স্পষ্টভাবে "সেরা" হতো?
এটি সরাসরি হিসেব করে দেখা যায়: MVVM = 0.25×(4+4+3+3) = 3.5, বাকিদের তুলনায় সবচেয়ে বেশি (MVC=3.25, MVI=3.25, Clean=3.0)। এটি অর্থবহ — MVVM প্রতিটি মানদণ্ডে "মাঝারি-থেকে-ভালো" স্কোর পায় (কোনো চরম দুর্বলতা নেই), যেখানে অন্যরা কোনো একটি মানদণ্ডে খুব ভালো কিন্তু আরেকটিতে খুব খারাপ — এটাই ব্যাখ্যা করে কেন MVVM প্রায়ই মোবাইলে "নিরাপদ ডিফল্ট" পছন্দ হিসেবে বিবেচিত হয়।
প্র ০৩ এই স্কোরার কি প্রকৃতপক্ষে প্রজেক্টের কোড লিখে দেখে স্কোর বের করে?
না — patterns ডিকশনারির মানগুলো ম্যানুয়ালি লেখা অনুমান (L10-L13-এর আলোচনা ও সাধারণভাবে
স্বীকৃত ট্রেড-অফের ভিত্তিতে), কোনো স্বয়ংক্রিয় পরিমাপ নয়। স্কোরারটি নিজে শুধু গাণিতিক
যোগ-গুণ করে — এর মূল্য এই নয় যে এটি "সঠিক" সংখ্যা উৎপন্ন করে, বরং এই যে এটি টিমকে তাদের
অগ্রাধিকারগুলো স্পষ্টভাবে লিখতে এবং সেই অগ্রাধিকার অনুযায়ী ধারাবাহিকভাবে তুলনা করতে বাধ্য করে।
অনুশীলন
-
চিন্তা করুন: একটি "মাঝারি" প্রোফাইল — মাঝারি আকারের টিম, মাঝারি জটিলতার অ্যাপ, তবে
টেস্টেবিলিটি খুব গুরুত্বপূর্ণ নয় (কারণ প্রজেক্টে ইতিমধ্যেই ভালো ম্যানুয়াল QA প্রক্রিয়া আছে) — এমন একটি
প্রজেক্টের জন্য আপনি কেমন ওজন সেট করবেন বলে মনে হয়?
একটি যুক্তিসঙ্গত সেট হতে পারে
{"testability": 0.15, "scalability": 0.30, "learning_curve": 0.30, "low_boilerplate": 0.25}— testability-এর ওজন কম রাখা হয়েছে (যেহেতু ম্যানুয়াল QA আছে), কিন্তু scalability এখনো মাঝারি-গুরুত্বপূর্ণ (মাঝারি জটিলতার অ্যাপ ভবিষ্যতে বাড়তে পারে), আর learning_curve/low_boilerplate-কেও যুক্তিসঙ্গত ওজন দেওয়া হয়েছে (মাঝারি টিমের জন্য দ্রুত-শেখা ও কম-বয়লারপ্লেট দুটোই কাজে লাগে)। এই ওজনগুলো দিয়েprint_ranking()চালিয়ে দেখা যেতে পারে কোন প্যাটার্ন শীর্ষে আসে। -
পরীক্ষা করুন: উপরের কোড সেলে
patternsডিকশনারিতে একটি নতুন প্যাটার্ন"MVP": {"testability": 4, "scalability": 3, "learning_curve": 3, "low_boilerplate": 3}যোগ করুন, তারপরprint_ranking()আবার চালিয়ে দেখুন এটি দুটি প্রোফাইলেই কোথায় স্থান পায়।যেহেতু
print_ranking()ফাংশনটি নির্দিষ্ট কোনো প্যাটার্নের নাম হার্ডকোড করে না — এটিpatterns.items()-এর ওপর লুপ করে — নতুন"MVP"এন্ট্রি স্বয়ংক্রিয়ভাবে র্যাঙ্কিংয়ে যুক্ত হয়ে যাবে, কোনো অতিরিক্ত কোড পরিবর্তন ছাড়াই। প্রোফাইল ১-এ (এন্টারপ্রাইজ) এটি MVVM=3.70-এর কাছাকাছি স্কোর পাবে (মাঝামাঝি কোথাও বসবে), আর প্রোফাইল ২-এ (প্রোটোটাইপ) MVC ও MVVM-এর মাঝামাঝি স্থান পাবে — এটি দেখায় স্কোরার ফাংশনটি সত্যিই ডেটা-চালিত, কোনো নির্দিষ্ট প্যাটার্নের সংখ্যায় হার্ডকোড করা নয়।
আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ
- কোর্সের সম্পূর্ণ সিলেবাস দেখুন ৫৭টি পাঠ অ্যাপ লাইফসাইকেল, মোবাইল UI/UX, MVVM/MVI আর্কিটেকচার, নেটিভ বনাম ক্রস-প্ল্যাটফর্ম, নেভিগেশন, স্টেট ম্যানেজমেন্ট, লোকাল স্টোরেজ, ডিভাইস ফিচার ও ডিপ্লয়মেন্ট — বাকি পাঠগুলো শীঘ্রই যুক্ত হবে।
- FSWF · Choosing the Right Stack for a Project সহোদর পাঠ ওজনযুক্ত-মানদণ্ড সিদ্ধান্ত-কাঠামোর একই ধরনের প্রয়োগ ওয়েব স্ট্যাক নির্বাচনের প্রেক্ষাপটে সেই পাঠে দেখা যায়।
- সব Courses দেখুন ABCL TECH C, C++, Python, Java, JavaScript, DSA, DBMS, Discrete Mathematics, System Design, Cybersecurity, Cloud Computing & DevOps, Computer Networks, Operating Systems, Computer Architecture, Programming Languages & Compiler Design, Software Engineering & Git, Theory of Computation, Engineering Economics, Full-Stack Web Frameworks ও Mobile App Development — সব এক জায়গায়।