সঠিক সফ্টওয়্যার পচন

অনুক্রমিক পচন

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

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

বস্তু নির্বাচন করার আগে, অন্তত মানসিকভাবে সিস্টেমটিকে মৌলিক শব্দার্থিক ব্লকগুলিতে ভাগ করুন। ছোট অ্যাপ্লিকেশানগুলিতে, এটি করা সাধারণত খুব সহজ: কয়েকটি স্তরের শ্রেণিবিন্যাস যথেষ্ট, যেহেতু সিস্টেমটি প্রথমে সাবসিস্টেম/প্যাকেজে বিভক্ত, এবং প্যাকেজগুলি ক্লাসে বিভক্ত।

এই ধারণাটি যতটা তুচ্ছ মনে হয় ততটা নয়। উদাহরণস্বরূপ, মডেল-ভিউ-কন্ট্রোলার (MVC) এর মতো একটি সাধারণ "স্থাপত্য প্যাটার্ন" এর সারাংশ কী?

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

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

সাধারণ শীর্ষ-স্তরের মডিউলগুলি, সিস্টেমের প্রথম বিভাজনের ফলে প্রাপ্ত সবচেয়ে বড় উপাদানগুলি হল:

• ব্যবসায়িক যুক্তি;
• ব্যবহারকারী ইন্টারফেস;
• তথ্যশালা;
• মেসেজিং সিস্টেম;
• বস্তুর ধারক।

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

কার্যকরী পচানি

মডিউল/সাবসিস্টেমের মধ্যে বিভাজনটি সিস্টেমটি সমাধান করে এমন কাজের উপর ভিত্তি করে করা হয় । প্রধান কাজটি তার উপাদান সাবটাস্কগুলিতে বিভক্ত, যা একে অপরের থেকে স্বাধীনভাবে স্বায়ত্তশাসিতভাবে সমাধান/সম্পাদিত হতে পারে।

প্রতিটি মডিউল কিছু সাবটাস্ক সমাধানের জন্য দায়ী এবং এর সংশ্লিষ্ট ফাংশন সম্পাদন করতে হবে । কার্যকরী উদ্দেশ্য ছাড়াও, মডিউলটি তার কার্য সম্পাদনের জন্য প্রয়োজনীয় ডেটার একটি সেট দ্বারাও চিহ্নিত করা হয়, যা হল:

মডিউল = ফাংশন + ডেটা এটি চালানোর জন্য প্রয়োজন।

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

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

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

শক্তিশালী এবং দুর্বল সংযোগ

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

পচনশীলতার মানের জন্য প্রধান মাপকাঠি হল কিভাবে মডিউলগুলি তাদের কাজগুলি সমাধান করার উপর দৃষ্টি নিবদ্ধ করে এবং স্বাধীন।

এটি সাধারণত নিম্নরূপ প্রণয়ন করা হয়: "পচনের ফলে প্রাপ্ত মডিউলগুলি অভ্যন্তরীণভাবে সর্বাধিক সংযোজিত হওয়া উচিত (উচ্চ অভ্যন্তরীণ সমন্বয়) এবং ন্যূনতমভাবে একে অপরের সাথে সংযুক্ত হওয়া উচিত (নিম্ন বাহ্যিক সংযোগ)।"

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

সংহতি মডিউল দ্বারা সম্পাদিত কাজগুলি একে অপরের সাথে সম্পর্কিত যে ডিগ্রিটি চিহ্নিত করে।

উচ্চ সমন্বয়ের একটি পরিণতি হল একক দায়িত্ব নীতি - পাঁচটি সলিড নীতির মধ্যে প্রথমটি , যেটি অনুসারে যে কোনও বস্তু/মডিউলের শুধুমাত্র একটি দায়িত্ব থাকা উচিত এবং এটি পরিবর্তন করার জন্য একাধিক কারণ থাকা উচিত নয়।

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

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

সঠিক ডিজাইনের সাথে, আপনি যদি একটি মডিউল পরিবর্তন করেন তবে আপনাকে অন্যগুলি সম্পাদনা করতে হবে না, বা এই পরিবর্তনগুলি ন্যূনতম হবে। কাপলিং যত সহজ হবে, প্রোগ্রামটি লিখতে/বুঝতে/প্রসারিত করা/মেরামত করা তত সহজ হবে।

এটি বিশ্বাস করা হয় যে ভালভাবে ডিজাইন করা মডিউলগুলির নিম্নলিখিত বৈশিষ্ট্য থাকা উচিত:

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

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

উত্তরাধিকারের পরিবর্তে রচনা

উপযুক্ত পচন একটি শিল্প এবং বেশিরভাগ প্রোগ্রামারদের জন্য একটি কঠিন কাজ। সরলতা এখানে প্রতারণামূলক, এবং ভুলগুলি ব্যয়বহুল।

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

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

একটি সিস্টেমকে পচানোর সময়, নিজেকে প্রশ্ন জিজ্ঞাসা করে এর গুণমান পরীক্ষা করা বাঞ্ছনীয়: "প্রতিটি মডিউল কী কাজ সম্পাদন করে?", "মডিউলগুলি পরীক্ষা করা কতটা সহজ?", "মডিউলগুলি নিজেরাই ব্যবহার করা কি সম্ভব? নাকি অন্য পরিবেশে?" অন্যদের প্রভাবিত করে?"

আপনাকে যতটা সম্ভব স্বায়ত্তশাসিত মডিউলগুলি রাখার চেষ্টা করতে হবে । পূর্বে উল্লিখিত হিসাবে, এটি সঠিক পচনের জন্য একটি মূল পরামিতি । অতএব, এটি এমনভাবে করা উচিত যে মডিউলগুলি প্রাথমিকভাবে একে অপরের উপর দুর্বলভাবে নির্ভরশীল। আপনি যদি সফল হন, তাহলে আপনি মহান।

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

এটা বলা যেতে পারে যে ডিকপলিংয়ের কৌশলগুলি প্রধান "স্থপতির টুলকিট" গঠন করে। এটি কেবলমাত্র বুঝতে হবে যে আমরা সমস্ত সাবসিস্টেম সম্পর্কে কথা বলছি এবং শ্রেণীবিন্যাসের সমস্ত স্তরে সংযোগটি দুর্বল করা প্রয়োজন , অর্থাৎ, শুধুমাত্র ক্লাসগুলির মধ্যে নয়, প্রতিটি স্তরের স্তরের মডিউলগুলির মধ্যেও।