সফটওয়্যার প্রোগ্রামিংয়ে কিছু অভিজ্ঞতার সাথে যে কেউ নিজের ক্যারিয়ারের পথের ভিত্তিতে রায় দেওয়ার পরামিতি ব্যবহার করে অন্যদের দ্বারা লিখিত সফ্টওয়্যার কোড বিচার করে।
আমার পেশাগত কেরিয়ারের সময়কালে, আমি অনেক বিকাশকারীকে জানি এবং আমি কয়েক হাজার লাইন কোড দেখেছি এবং যখন কোনও বিকাশকারীর দক্ষতার মূল্যায়ন করার প্রয়োজন হয় তখন আমি প্রধানত দুটি কারণ দেখি:
ভাগ্যক্রমে, এমন কিছু মৌলিক বা নীতি রয়েছে যা কোডিংয়ে আরও ভাল হওয়া সহজ করে দেয়।
সংক্ষিপ্ত আকার SOLID এর জন্য:
S: একক দায়িত্বের নীতি
O: মুক্ত-বদ্ধ নীতি
L: লিসকভ প্রতিস্থাপনের নীতি
I: ইন্টারফেস পৃথককরণের নীতি
D: নির্ভরতা বিপরীতার মূলনীতি
আসুন প্রথম সলিড নীতিটি ডিলিং দিয়ে শুরু করি, যথা
একটি শ্রেণীর (বা মডিউল) পরিবর্তিত হওয়ার, বিকশিত হওয়ার একমাত্র কারণ থাকতে হবে।
ধারণাটি নিজেই খুব সহজ, তবে এই সরলতা অর্জনের জন্য বাস্তবায়নের পথটি খুব জটিল হতে পারে। একটি শ্রেণীর পরিবর্তনের একমাত্র কারণ থাকতে হবে।
কিন্তু কেন?
পরিবর্তনের একমাত্র কারণ থাকা কেন এত গুরুত্বপূর্ণ?
উদাহরণস্বরূপ, যদি পরিবর্তনের জন্য দুটি ভিন্ন কারণ থাকে তবে এটি অনুমেয় যে দুটি পৃথক দল দুটি ভিন্ন কারণে একই কোডে কাজ করতে পারে। প্রত্যেককে তাদের নিজস্ব সমাধান প্রয়োগ করতে হবে, যা সংকলিত ভাষার ক্ষেত্রে (যেমন সি ++, সি # বা জাভা) মডিউলগুলিতে নিয়ে যেতে পারে যা অন্যান্য দল বা অ্যাপ্লিকেশনের অন্যান্য অংশের সাথে বেমানান।
আরেকটি উদাহরণ, আপনি যদি কোনও ব্যাখ্যামূলক ভাষা ব্যবহার করে থাকেন তবে বিভিন্ন কারণে আপনাকে একই শ্রেণি বা মডিউলটি পরীক্ষা করতে হতে পারে। এর অর্থ মানের নিয়ন্ত্রণের জন্য আরও কাজ, সময় এবং প্রচেষ্টা।
ক্লাস বা মডিউলের যে বৈশিষ্ট্যটি হওয়া উচিত কেবল তা সনাক্তকরণ পরীক্ষা চালানোর জন্য কেবলমাত্র চেকলিস্টে দেখার চেয়ে জটিল।
তবে আসুন আমরা কম প্রযুক্তিগত দৃষ্টিকোণ থেকে চিন্তা করার চেষ্টা করি, এটি হ'ল আমাদের শ্রেণি বা মডিউলটির ব্যবহারকারীর বিশ্লেষণ করার চেষ্টা করি, এটিই কে এটি ব্যবহার করবে। একটি মৌলিক দিক যা আমাদের সর্বদা মাথায় রাখতে হবে, এটি হ'ল আমরা যে অ্যাপ্লিকেশন বা সিস্টেমটি বিকাশ করি যাঁরা একটি নির্দিষ্ট মডিউল দ্বারা পরিবেশন করা হয় সেগুলিই এর পরিবর্তনের জন্য অনুরোধ করবে। যারা পরিবেশন করেছেন তারা ক্লাস বা মডিউল পরিবর্তন করতে বলবেন।
মডিউল এবং তাদের ব্যবহারের কয়েকটি উদাহরণ:
সুতরাং প্রথম পদক্ষেপটি যদি মডিউলের সাথে কথোপকথনের ভূমিকা রাখে এমন অভিনেতা বা অভিনেতার সন্ধান করা হয়, সমস্ত ভূমিকার সাথে ব্যক্তিদের সংযুক্ত করা কঠিন হতে পারে। একটি ছোট সংস্থায়, একজন ব্যক্তি একাধিক ভূমিকা পালন করতে পারে যখন একটি বৃহত সংস্থায় একক ভূমিকা রাখে এমন একাধিক ব্যক্তি থাকতে পারে।
ব্যক্তি বা ব্যবহারকারীদের চেয়ে ভূমিকাগুলি সনাক্ত করা আরও যুক্তিসঙ্গত বলে মনে হয়।
অতএব:
আসুন কিছু উদাহরণ দেখুন
মনে করুন আমাদের কাছে এমন একটি বুক ক্লাস রয়েছে যা একটি বইয়ের ধারণা এবং এর কার্যকারিতাটি ঘিরে রেখেছে।
ক্লাস বই {
ফাংশন getTitle () {
"একটি দুর্দান্ত বই" ফেরত;
}
ফাংশন getAuthor () {
"আলেসান্দ্রো ব্যারিকো" ফিরিয়ে দিন;
}
ফাংশন পরবর্তী পৃষ্ঠা () {
// পরবর্তী পৃষ্ঠা
}
ফাংশন মুদ্রণকেন্দ্রপেজ () {
প্রতিধ্বনি "বর্তমান পৃষ্ঠার বিষয়বস্তু";
}
}
এটি খুব সাধারণ শ্রেণি। আমাদের একটি বই আছে, এবং ক্লাস আমাদের শিরোনাম দিতে পারে, তারা আমাদের লেখক দিতে পারে এবং তারা এগিয়ে যেতে পারে। শেষ পর্যন্ত, এটি স্ক্রিনে বর্তমান পৃষ্ঠা মুদ্রণ করতেও সক্ষম।
তবে একটি ছোট সমস্যা আছে।
বুক অবজেক্ট পরিচালনার সাথে জড়িত অভিনেতাদের সম্পর্কে ভাবনা, তারা কে হতে পারে?
আমরা এখানে দুটি ভিন্ন অভিনেতাকে সহজেই ভাবতে পারি: বই পরিচালনা (হিসাবে গ্রন্থাগারিক) ই তথ্য জমা দেওয়ার প্রক্রিয়া (যেমন আমরা ব্যবহারকারীর কাছে কীভাবে সামগ্রী সরবরাহ করতে চাই: অন-স্ক্রিন, গ্রাফিক্যাল ইউজার ইন্টারফেস, কেবলমাত্র পাঠ্য-ব্যবহারকারী ইন্টারফেস, সম্ভবত মুদ্রণ)।
ক্লাসের সাথে ইন্টারঅ্যাক্ট করার জন্য আমাদের দুটি খুব ভিন্ন অভিনেতা রয়েছে।
সংক্ষেপে এই শ্রেণীটি এর মধ্যে একটি মিশ্রণ তৈরি করে:
এটি সমস্যা হতে পারে কারণ এটি একক দায় নীতি (এসআরপি) লঙ্ঘন করে।
আমরা কীভাবে পরিবর্তন করতে পারি, একক দায়িত্বের নীতিকে সম্মান জানাতে আমরা এই কোডটি কীভাবে উন্নত করতে পারি?
নিম্নলিখিত কোডটি একবার দেখুন:
ক্লাস বই {
ফাংশন getTitle () {
"ওশেনো মেরে" ফিরুন;
}
ফাংশন getAuthor () {
"আলেসান্দ্রো ব্যারিকো" ফিরিয়ে দিন;
}
ফাংশন টার্ন পৃষ্ঠা () {
// পরবর্তী পৃষ্ঠা
}
ফাংশন getCurrentPage () {
প্রতিধ্বনি "বর্তমান পৃষ্ঠার বিষয়বস্তু";
}
}
ইন্টারফেস প্রিন্টার
ফাংশন প্রিন্টপেজ ($ পৃষ্ঠা);
}
ক্লাস স্ট্যাম্পলিব্রো প্রিন্টার প্রয়োগ করে {
ফাংশন মুদ্রণ পৃষ্ঠা ($ পৃষ্ঠা) {
প্রতিধ্বনি $ পৃষ্ঠা;
}
}
শ্রেণি এইচটিএমএলপ্রিন্টার প্রিন্টার প্রয়োগ করে {
ফাংশন মুদ্রণ পৃষ্ঠা ($ পৃষ্ঠা) {
প্রতিধ্বনি ' '। । পৃষ্ঠা ' ';
}
}
এটি অত্যন্ত সাধারণ উদাহরণটি কীভাবে ব্যবসায়ের যুক্তি থেকে উপস্থাপনা আলাদা করতে হয় তা দেখায় এবং এসআরপি'র সাথে সম্মতিতে এটি আমাদের প্রকল্পের নমনীয়তায় দুর্দান্ত সুবিধা দেয়।
আরেকটি উদাহরণ তাকান:
উপরের মতো একটি উদাহরণ হ'ল যখন কোনও বস্তু উপস্থাপনা থেকে নিজেকে সংরক্ষণ এবং পুনরুদ্ধার করতে পারে।
ক্লাস বই {
ফাংশন getTitle () {
"ওশেনো মেরে" ফিরুন;
}
ফাংশন getAuthor () {
"আলেসান্দ্রো ব্যারিকো" ফিরিয়ে দিন;
}
ফাংশন টার্ন পৃষ্ঠা () {
// পরবর্তী পৃষ্ঠা
}
ফাংশন getCurrentPage () {
"বর্তমান পৃষ্ঠার বিষয়বস্তু" প্রদান;
}
ফাংশন সংরক্ষণ () {
$ ফাইলের নাম = '/ নথি /'। $ এটি-> getTitolo ()। '-'। $ এটি-> getAuthor ();
ফাইল_পুট_কন্টেন্টস ($ ফাইলের নাম, সিরিয়ালাইজ ($ এটি));
}
}
আগের মতো, এখানেও আমরা বিভিন্ন অভিনেতা পছন্দ করতে পারি বই পরিচালনা (হিসাবে গ্রন্থাগারিক) ই জেদ। যখনই আমরা পৃষ্ঠা থেকে অন্য পৃষ্ঠায় যাওয়ার উপায়টি পরিবর্তন করতে চাই, আমাদের এই শ্রেণিটি পরিবর্তন করা দরকার। পরিবর্তনের জন্য আমাদের বেশ কয়েকটি কারণ থাকতে পারে।
ক্লাস বই {
ফাংশন getTitle () {
"ওশেনো মেরে" ফিরুন;
}
ফাংশন getAuthor () {
"আলেসান্দ্রো ব্যারিকো" ফিরিয়ে দিন;
}
ফাংশন টার্ন পৃষ্ঠা () {
// পরবর্তী পৃষ্ঠা
}
ফাংশন getCurrentPage () {
"বর্তমান পৃষ্ঠার বিষয়বস্তু" প্রদান;
}
}
ক্লাস সিম্পল ফায়ারপ্রেস্টিটি {
ফাংশন সেভ (বই $ বই) {
$ ফাইলের নাম = '/ নথি /'। $ book-> getTitle ()। '-'। $ book-> getAuthor ();
ফাইল_পুট_কন্টেন্টস ($ ফাইলের নাম, সিরিয়ালাইজ ($ বই));
}
}
দৃ class়তা অপারেশনটিকে অন্য শ্রেণিতে স্থানান্তর করা স্পষ্টভাবে দায়িত্ব পৃথক করবে এবং আমরা আমাদের বুক ক্লাসকে প্রভাবিত না করেই অধ্যবসায় পদ্ধতির আদান-প্রদান করতে মুক্ত হতে পারি। উদাহরণস্বরূপ, একটি ডেটাবেসস্পার্টিস্ট ক্লাস প্রয়োগ করা তুচ্ছ হবে এবং বইয়ের ক্রিয়াকলাপগুলিতে নির্মিত আমাদের ব্যবসায়িক যুক্তি পরিবর্তিত হবে না।
দ্বিতীয় নীতিটি উন্মুক্ত / বন্ধ -> পড়া চালিয়ে যান
Ercole Palmeri
ইউকে সিএমএ কৃত্রিম বুদ্ধিমত্তার বাজারে বিগ টেকের আচরণ সম্পর্কে একটি সতর্কতা জারি করেছে। সেখানে…
ভবনগুলির শক্তি দক্ষতা বাড়ানোর জন্য ইউরোপীয় ইউনিয়ন দ্বারা প্রণয়ন করা "গ্রিন হাউস" ডিক্রি, এর আইনী প্রক্রিয়া শেষ করেছে...
ইতালিতে ইকমার্সের উপর Casaleggio Associati এর বার্ষিক প্রতিবেদন উপস্থাপন করা হয়েছে। "এআই-কমার্স: কৃত্রিম বুদ্ধিমত্তার সাথে ইকমার্সের সীমান্ত" শিরোনামের প্রতিবেদন।
ধ্রুবক প্রযুক্তিগত উদ্ভাবন এবং পরিবেশ এবং মানুষের মঙ্গলের প্রতি অঙ্গীকারের ফলাফল। Bandalux উপস্থাপন করে Airpure®, একটি তাঁবু...
