মোবাইল ডেভেলপমেন্টে আর্কিটেকচার নীতি: এগুলো কী কী, কত প্রকার এবং কীভাবে প্রয়োগ করবেন

SOLID নীতি

আর্কিটেকচার নীতি — গুণমান কোডের ভিত্তি। SOLID হল একটি সংক্ষিপ্ত রূপ যা রবার্ট মার্টিন («আঙ্কেল বব») প্রবর্তন করেছেন, যা অবজেক্ট-ওরিয়েন্টেড ডিজাইনের পাঁচটি নীতি বর্ণনা করে। SOLID অনুসরণ করা কোডকে আরও নমনীয়, পরীক্ষাযোগ্য এবং পরিবর্তনের প্রতি প্রতিরোধী করে তোলে। আর্কিটেকচার নীতি লঙ্ঘন টেকনিক্যাল ডেটের প্রধান কারণগুলির মধ্যে একটি।

আসুন প্রতিটি নীতি পরীক্ষা করি। Single Responsibility Principle (SRP) — প্রতিটি ক্লাসের পরিবর্তনের শুধুমাত্র একটি কারণ থাকা উচিত। Open/Closed Principle (OCP) — ক্লাসগুলি সম্প্রসারণের জন্য উন্মুক্ত কিন্তু পরিবর্তনের জন্য বন্ধ। Liskov Substitution Principle (LSP) — উপপ্রকারের অবজেক্টগুলি লজিক ভাঙ্গা ছাড়াই বেস টাইপের অবজেক্টগুলি প্রতিস্থাপন করতে সক্ষম হওয়া উচিত। Interface Segregation Principle (ISP) — একটি সাধারণ ইন্টারফেসের চেয়ে অনেকগুলি বিশেষায়িত ইন্টারফেস ভালো। Dependency Inversion Principle (DIP) — কংক্রিট বাস্তবায়নের উপর নয়, বিমূর্ততার উপর নির্ভর করুন।

SonarQube বিশ্লেষণ (2025) অনুসারে, 68% বাণিজ্যিক প্রজেক্টে SOLID নীতি লঙ্ঘন ঘটে। সবচেয়ে সাধারণ সমস্যা হল SRP লঙ্ঘন (35%) এবং ISP লঙ্ঘন (22%)। IT Sectr এ, আমরা আর্কিটেকচার পর্যালোচনা পর্যায়ে SOLID প্রয়োগ করি — এটি সমস্যাগুলি টেকনিক্যাল ডেটে পরিণত হওয়ার আগে সনাক্ত করতে সহায়তা করে।

Single Responsibility Principle (SRP)

SRP (একক দায়িত্বের নীতি) — সবচেয়ে গুরুত্বপূর্ণ এবং একই সাথে সবচেয়ে বেশি লঙ্ঘিত SOLID নীতি। এটি বলে: একটি ক্লাসের পরিবর্তনের শুধুমাত্র একটি কারণ থাকা উচিত। যদি একটি ক্লাস খুব বেশি কাজ করে তবে এটি পরীক্ষা, পরিবর্তন এবং বোঝা কঠিন।

একটি সাধারণ লঙ্ঘন হল একটি ক্লাস যা একই সাথে ডেটা প্রক্রিয়া করে, ডেটাবেসে সংরক্ষণ করে এবং ইমেল বিজ্ঞপ্তি পাঠায়। নীচের উদাহরণটি Kotlin-এ SRP লঙ্ঘন এবং কীভাবে এটি ঠিক করতে হয় তা দেখায়।

// SRP লঙ্ঘন — ক্লাস তিনটি ভিন্ন কাজ করে
class UserService {
    fun registerUser(email: String, name: String) {
        // 1. ডেটা যাচাই
        if (!email.contains("@")) throw IllegalArgumentException("Invalid email")
        
        // 2. ডেটাবেসে সংরক্ষণ
        val user = User(email, name)
        database.save(user)
        
        // 3. বিজ্ঞপ্তি পাঠান
        emailService.sendWelcomeEmail(email, name)
    }
}

// সমাধান — তিনটি ক্লাসে বিভক্ত
class UserRegistrationService {
    fun register(email: String, name: String) {
        UserValidator().validate(email)
        val user = User(email, name)
        UserRepository().save(user)
        NotificationService().sendWelcome(user)
    }
}

সংশোধিত সংস্করণে, প্রতিটি ক্লাস নিজস্ব কাজের জন্য দায়ী: UserValidator — যাচাইয়ের জন্য, UserRepository — সংরক্ষণের জন্য, NotificationService — বিজ্ঞপ্তির জন্য। এটি কোডকে পরীক্ষাযোগ্য এবং পুনরায় ব্যবহারযোগ্য করে তোলে — আপনি যাচাই লজিক পরিবর্তন না করেই ডেটাবেস বাস্তবায়ন প্রতিস্থাপন করতে পারেন।

GRASP এবং Law of Demeter

GRASP (General Responsibility Assignment Software Patterns) — ক্রেগ লারম্যান দ্বারা বর্ণিত অবজেক্টের মধ্যে দায়িত্ব বণ্টনের নয়টি আর্কিটেকচার নীতি। SOLID-এর বিপরীতে, GRASP এই প্রশ্নের উত্তর দেয় «কোন ক্লাসে এই মেথডটি থাকা উচিত?»। মূল প্যাটার্ন: Information Expert, Creator, Controller, Low Coupling, High Cohesion, Polymorphism, Pure Fabrication, Indirection, Protected Variations.

Law of Demeter (LoD, ন্যূনতম সংযুক্তির নীতি) — একটি সহজ নিয়ম: একটি অবজেক্ট শুধুমাত্র তার নিকটবর্তী প্রতিবেশীদের সাথে যোগাযোগ করা উচিত। a.getB().getC().doSomething() লেখা উচিত নয় — এটি ক্লাসের মধ্যে দৃঢ় সংযুক্তি তৈরি করে। LoD পুনরায় ব্যবহারযোগ্যতা উন্নত করে এবং পরীক্ষা সহজ করে।

IT Sectr-এ, আমরা কোড রিভিউর সময় LoD মেনে চলা যাচাই করি। যদি একটি মেথড তিন বা ততোধিক অবজেক্টের «মধ্য দিয়ে যায়», তবে এটি একটি সংকেত যে আর্কিটেকচারটি সরলীকরণ প্রয়োজন। LoD লঙ্ঘন বড় প্রজেক্টে সবচেয়ে সাধারণ Code Smell-গুলির মধ্যে একটি।

DRY / KISS / YAGNI

DRY (Don't Repeat Yourself), KISS (Keep It Simple, Stupid) এবং YAGNI (You Ain't Gonna Need It) — তিনটি মৌলিক আর্কিটেকচার নীতি যা প্রতিটি ডেভেলপারের জানা। সরলতা সত্ত্বেও, এগুলির লঙ্ঘন ক্রমাগত ঘটে।

DRY — কোড পুনরাবৃত্তি করবেন না। যদি একই লজিক দুটি জায়গায় দেখা যায় তবে এটি একটি সাধারণ মেথড বা ক্লাসে বের করে আনুন। পুনরাবৃত্তি বাগের প্রধান উৎস: একটি জায়গায় সংশোধন অন্য জায়গায় প্রয়োগ করতে ভুলে যায়। DRY মানে এই নয় যে একই রকম কোড থাকতে পারে না — গুরুত্বপূর্ণ হল ব্যবসায়িক লজিক যেন পুনরাবৃত্তি না হয়।

KISS — যত সহজ, তত ভালো। অনেক বিমূর্ততা এবং উত্তরাধিকার সহ জটিল সমাধানগুলি প্রায়ই অপ্রয়োজনীয়। একটি সহজ সমাধান দিয়ে শুরু করুন এবং শুধুমাত্র প্রয়োজন হলে জটিল করুন। YAGNI — «কখনও পরে» প্রয়োজন হতে পারে এমন কার্যকারিতার জন্য কোড লিখবেন না। এটি কোডবেস ফুলিয়ে তোলে এবং রক্ষণাবেক্ষণ জটিলতা বাড়ায়।

DRY — Don't Repeat Yourself

DRY — এটি শুধু কপি-পেস্টের অনুপস্থিতি নয়। এটি একটি নীতি যার অনুসারে জ্ঞান বা লজিকের প্রতিটি অংশের সিস্টেমে একটি একক, দ্ব্যর্থহীন উপস্থাপনা থাকা উচিত। পুনরাবৃত্তি স্পষ্ট (কপি করা কোড) এবং অন্তর্নিহিত (বিভিন্ন স্তরে একই লজিক) হতে পারে।

IT Sectr-এ, আমরা পুনরাবৃত্তি সনাক্ত করতে কোড বিশ্লেষণ মেট্রিক ব্যবহার করি। SonarQube এবং Detekt-এর মতো টুলগুলি পুনরাবৃত্ত কোডের শতাংশ দেখায়। 5% এর বেশি মান রিফ্যাক্টরিংয়ের কারণ। তবে, এটি মনে রাখা গুরুত্বপূর্ণ: DRY ভুল বিমূর্ততার মূল্যে অর্জন করা উচিত নয় — কখনও কখনও একই রকম কোডের দুটি টুকরো যেমন আছে তেমনই রাখা ভাল যদি সেগুলিকে একত্রিত করলে বোঝা জটিল হয়ে যায়।

Separation of Concerns এবং Modularity

Separation of Concerns (SoC) — একটি আর্কিটেকচার নীতি যেখানে সিস্টেমটি স্বাধীন অংশে (concerns) বিভক্ত হয়, প্রতিটি নিজস্ব কাজ সমাধান করে। একটি ক্লাসিক উদাহরণ হল স্তরে বিভক্তকরণ: উপস্থাপনা, ব্যবসায়িক লজিক, ডেটা অ্যাক্সেস। প্রতিটি স্তর শুধুমাত্র নীচের স্তরের উপর নির্ভর করে।

Modularity (মডুলারিটি) — যে মাত্রায় সিস্টেমকে মডিউলে বিভক্ত করা যায়। একটি মডিউল হল একটি সুসংজ্ঞায়িত ইন্টারফেস সহ যৌক্তিকভাবে সম্পর্কিত ক্লাসের একটি গ্রুপ। মডিউলগুলি শিথিলভাবে সংযুক্ত (low coupling) এবং দৃঢ়ভাবে সমন্বিত (high cohesion) হওয়া উচিত।

Cohesion vs Coupling

Cohesion (সমন্বয়) — একটি মাপ যে একই মডিউলের মধ্যে উপাদানগুলি একে অপরের সাথে কতটা সম্পর্কিত। উচ্চ সমন্বয় ভালো: একটি ক্লাস একটি কাজ করে এবং তা ভালোভাবে করে। Low coupling (নিম্ন সংযুক্তি) — একটি মাপ যে মডিউলগুলি একে অপরের থেকে কতটা স্বাধীন। নিম্ন সংযুক্তি ভালো: একটি মডিউলে পরিবর্তন অন্যগুলিকে ভাঙ্গে না।

আদর্শ আর্কিটেকচার হল উচ্চ সমন্বয় এবং নিম্ন সংযুক্তি। অনুশীলনে, এর অর্থ: একটি ক্লাসে এমন মেথড থাকে যা একই ডেটাতে কাজ করে (সমন্বয়), এবং শুধুমাত্র বিমূর্ততার উপর নির্ভর করে, কংক্রিট বাস্তবায়নের উপর নয় (সংযুক্তি)। অসমতলতা «গড অবজেক্ট» বা «স্প্যাগেটি কোড»-এর দিকে নিয়ে যায়।

টেকনিক্যাল ডেট এবং Code Smell

টেকনিক্যাল ডেট (Technical Debt) — ওয়ার্ড কানিংহাম দ্বারা প্রবর্তিত একটি রূপক যা «সুদ» বর্ণনা করে যা একটি দল উপ-অনুকূল আর্কিটেকচার সিদ্ধান্ত এবং আর্কিটেকচার নীতি লঙ্ঘনের জন্য প্রদান করে। আর্থিক ঋণের মতো, টেকনিক্যাল ডেট ইচ্ছাকৃত (আমরা দ্রুত করার সিদ্ধান্ত নিয়েছি, পরে পুনরায় করব) এবং অনিচ্ছাকৃত (অভিজ্ঞতার অভাবে খারাপ আর্কিটেকচার) হতে পারে।

Code Smell — কোডে গভীর সমস্যার উপরিভাগের লক্ষণ। শব্দটি মার্টিন ফাউলার তার «Refactoring» বইয়ে জনপ্রিয় করেছিলেন। সাধারণ Code Smell: দীর্ঘ মেথড, বড় ক্লাস, দীর্ঘ কল চেইন, কোড পুনরাবৃত্তি, মন্তব্যের অত্যধিক ব্যবহার (স্পষ্ট কোডের পরিবর্তে)।

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