কোডিং নিয়ম: একটি সিস্টেম তৈরি করা থেকে অবজেক্টের সাথে কাজ করা

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

সিস্টেম

নিম্নলিখিতগুলি সাধারণত একটি সিস্টেমের পছন্দসই বৈশিষ্ট্য:

• ন্যূনতম জটিলতা। অত্যধিক জটিল প্রকল্পগুলি এড়িয়ে চলতে হবে। সবচেয়ে গুরুত্বপূর্ণ বিষয় হল সরলতা এবং স্বচ্ছতা (সহজ = ভাল)।
• রক্ষণাবেক্ষণ সহজ. একটি অ্যাপ্লিকেশন তৈরি করার সময়, আপনাকে অবশ্যই মনে রাখতে হবে যে এটি রক্ষণাবেক্ষণ করতে হবে (এমনকি যদি আপনি ব্যক্তিগতভাবে এটি রক্ষণাবেক্ষণের জন্য দায়ী না হন)। এর মানে কোডটি অবশ্যই পরিষ্কার এবং সুস্পষ্ট হতে হবে।
• আলগা সংযোজন. এর মানে হল যে আমরা প্রোগ্রামের বিভিন্ন অংশের মধ্যে নির্ভরতার সংখ্যা হ্রাস করি (OOP নীতিগুলির সাথে আমাদের সম্মতি সর্বাধিক করে)।
• পুনর্ব্যবহারযোগ্যতা। আমরা অন্যান্য অ্যাপ্লিকেশনগুলিতে উপাদানগুলি পুনঃব্যবহারের ক্ষমতা সহ আমাদের সিস্টেম ডিজাইন করি।
• বহনযোগ্যতা। একটি সিস্টেমকে অন্য পরিবেশে মানিয়ে নেওয়া সহজ হওয়া উচিত।
• অভিন্ন শৈলী। আমরা আমাদের সিস্টেমের বিভিন্ন উপাদানে একটি অভিন্ন শৈলী ব্যবহার করে ডিজাইন করি।
• এক্সটেনসিবিলিটি (স্কেলযোগ্যতা)। আমরা সিস্টেমটিকে এর মৌলিক কাঠামো লঙ্ঘন না করেই উন্নত করতে পারি (একটি উপাদান যোগ করা বা পরিবর্তন করা অন্য সকলকে প্রভাবিত করা উচিত নয়)।

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

ইমেজ সোর্স

একটি সিস্টেম ডিজাইন করার পর্যায়

1. সফটওয়্যার সিস্টেম। অ্যাপ্লিকেশনটি সামগ্রিকভাবে ডিজাইন করুন।
2. সাবসিস্টেম/প্যাকেজে বিভাজন। যৌক্তিকভাবে স্বতন্ত্র অংশগুলি সংজ্ঞায়িত করুন এবং তাদের মধ্যে মিথস্ক্রিয়া করার নিয়মগুলি সংজ্ঞায়িত করুন।
3. ক্লাসে সাবসিস্টেমের বিভাজন। সিস্টেমের অংশগুলিকে নির্দিষ্ট শ্রেণী এবং ইন্টারফেসে ভাগ করুন এবং তাদের মধ্যে মিথস্ক্রিয়া সংজ্ঞায়িত করুন।
4. পদ্ধতিতে ক্লাস বিভাজন। একটি ক্লাসের জন্য প্রয়োজনীয় পদ্ধতির একটি সম্পূর্ণ সংজ্ঞা তৈরি করুন, তার নির্ধারিত দায়িত্বের উপর ভিত্তি করে।
5. পদ্ধতি নকশা। পৃথক পদ্ধতির কার্যকারিতার একটি বিস্তারিত সংজ্ঞা তৈরি করুন।

সাধারণত সাধারণ বিকাশকারীরা এই নকশাটি পরিচালনা করে, যখন অ্যাপ্লিকেশনটির স্থপতি উপরে বর্ণিত পয়েন্টগুলি পরিচালনা করে।

সিস্টেম ডিজাইনের সাধারণ নীতি এবং ধারণা

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

AOP

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

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

সলিড

একটি সিস্টেম ডিজাইন করার সময়, সুপরিচিত সলিড নীতিগুলি বিবেচনা করা উচিত:

S (একক দায়িত্ব), O (খোলা-বন্ধ), L (লিসকভ প্রতিস্থাপন), I (ইন্টারফেস বিভাজন), D (নির্ভরতা বিপরীত)।

আমরা প্রতিটি পৃথক নীতিতে বাস করব না। এটি এই নিবন্ধের সুযোগের বাইরে কিছুটা হবে, তবে আপনি এখানে আরও পড়তে পারেন ।

ইন্টারফেস

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

ক্লাস

ইমেজ সোর্স

অভ্যন্তরীণভাবে ক্লাসগুলি কীভাবে সাজানো হয় তা দেখে নেওয়া যাক। অথবা বরং, কিছু দৃষ্টিকোণ এবং নিয়ম যা ক্লাস লেখার সময় অনুসরণ করা উচিত। একটি নিয়ম হিসাবে, একটি ক্লাস একটি নির্দিষ্ট ক্রমে ভেরিয়েবলের তালিকা দিয়ে শুরু করা উচিত:

1. পাবলিক স্ট্যাটিক ধ্রুবক;
2. ব্যক্তিগত স্ট্যাটিক ধ্রুবক;
3. ব্যক্তিগত উদাহরণ ভেরিয়েবল।

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

শ্রেনীর ধরণ

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

বস্তু

এনক্যাপসুলেশন

এখানে আমরা প্রথমে একটি OOP নীতি সম্পর্কে কথা বলব: encapsulation. বাস্তবায়ন লুকিয়ে রাখা ভেরিয়েবলগুলিকে অন্তরক করার জন্য একটি পদ্ধতি তৈরি করার সমান নয় (বিবেচনাহীনভাবে পৃথক পদ্ধতি, গেটার এবং সেটারের মাধ্যমে অ্যাক্সেস সীমাবদ্ধ করা, যা ভাল নয়, যেহেতু এনক্যাপসুলেশনের পুরো পয়েন্টটি হারিয়ে গেছে)। অ্যাক্সেস লুকানোর উদ্দেশ্য হল বিমূর্ততা তৈরি করা, অর্থাৎ, ক্লাসটি শেয়ার করা কংক্রিট পদ্ধতিগুলি সরবরাহ করে যা আমরা আমাদের ডেটা নিয়ে কাজ করতে ব্যবহার করি। এবং ব্যবহারকারীর সঠিকভাবে জানার প্রয়োজন নেই যে আমরা এই ডেটার সাথে কীভাবে কাজ করছি - এটি কাজ করে এবং এটি যথেষ্ট।

ডিমিটারের আইন

আমরা ডিমিটারের আইনটিও বিবেচনা করতে পারি: এটি নিয়মের একটি ছোট সেট যা ক্লাস এবং পদ্ধতি স্তরে জটিলতা পরিচালনা করতে সহায়তা করে। ধরুন আমাদের একটি কার অবজেক্ট আছে, এবং এটির একটি সরানো (অবজেক্ট arg1, অবজেক্ট arg2) পদ্ধতি রয়েছে। ডিমিটারের আইন অনুসারে, এই পদ্ধতিটি কল করার মধ্যে সীমাবদ্ধ:

• কার বস্তুর নিজেই পদ্ধতি (অন্য কথায়, "এই" বস্তুটি);
• সরানো পদ্ধতির মধ্যে তৈরি বস্তুর পদ্ধতি ;
• আর্গুমেন্ট হিসাবে পাস করা বস্তুর পদ্ধতি ( arg1 , arg2 );
• অভ্যন্তরীণ গাড়ী বস্তুর পদ্ধতি (আবার, "এই")।

অন্য কথায়, ডিমিটারের আইন এমন কিছু যা বাবা-মা একটি শিশুকে বলতে পারেন: "আপনি আপনার বন্ধুদের সাথে কথা বলতে পারেন, কিন্তু অপরিচিতদের সাথে নয়"।

তথ্য কাঠামো

একটি ডেটা স্ট্রাকচার হল সম্পর্কিত উপাদানগুলির একটি সংগ্রহ। একটি বস্তুকে ডেটা স্ট্রাকচার হিসেবে বিবেচনা করার সময়, ডেটা উপাদানগুলির একটি সেট থাকে যেগুলি পদ্ধতিগুলি কাজ করে। এই পদ্ধতিগুলির অস্তিত্ব অন্তর্নিহিতভাবে অনুমান করা হয়। অর্থাৎ, একটি ডেটা স্ট্রাকচার হল একটি বস্তু যার উদ্দেশ্য হল সঞ্চিত ডেটা সংরক্ষণ করা এবং কাজ করা (প্রসেস) করা। একটি নিয়মিত অবজেক্ট থেকে এর মূল পার্থক্য হল যে একটি সাধারণ বস্তু হল পদ্ধতির একটি সংগ্রহ যা ডেটা উপাদানগুলির উপর কাজ করে যা অন্তর্নিহিতভাবে অনুমান করা হয়। তুমি কি বুঝতে পেরেছো? একটি সাধারণ বস্তুর প্রধান দিক হল পদ্ধতি। অভ্যন্তরীণ ভেরিয়েবল তাদের সঠিক অপারেশন সহজতর. কিন্তু একটি ডেটা স্ট্রাকচারে, সঞ্চিত ডেটা উপাদানগুলির সাথে আপনার কাজকে সমর্থন করার জন্য পদ্ধতিগুলি রয়েছে, যা এখানে সর্বাধিক গুরুত্বপূর্ণ। এক ধরনের ডেটা স্ট্রাকচার হল ডেটা ট্রান্সফার অবজেক্ট (DTO)। এটি এমন একটি ক্লাস যেখানে পাবলিক ভেরিয়েবল রয়েছে এবং কোন পদ্ধতি নেই (বা শুধুমাত্র পড়ার/লেখার পদ্ধতি) যা ডেটাবেসগুলির সাথে কাজ করার সময়, সকেট থেকে বার্তাগুলি পার্স করার সময় ডেটা স্থানান্তর করতে ব্যবহৃত হয়৷ ডেটা সাধারণত দীর্ঘ সময়ের জন্য এই ধরনের বস্তুগুলিতে সংরক্ষণ করা হয় না৷ এটি প্রায় সঙ্গে সঙ্গে আমাদের অ্যাপ্লিকেশন কাজ করে যে ধরনের সত্তা রূপান্তরিত হয়. একটি সত্তা, ঘুরে, একটি ডেটা কাঠামো, কিন্তু এর উদ্দেশ্য হল অ্যাপ্লিকেশনের বিভিন্ন স্তরে ব্যবসায়িক যুক্তিতে অংশগ্রহণ করা। একটি DTO এর উদ্দেশ্য হল অ্যাপ্লিকেশন থেকে/থেকে ডেটা পরিবহন করা। একটি DTO এর উদাহরণ: এটি একটি ডেটা স্ট্রাকচারও, তবে এর উদ্দেশ্য হল অ্যাপ্লিকেশনের বিভিন্ন স্তরে ব্যবসায়িক যুক্তিতে অংশগ্রহণ করা। একটি DTO এর উদ্দেশ্য হল অ্যাপ্লিকেশন থেকে/থেকে ডেটা পরিবহন করা। একটি DTO এর উদাহরণ: এটি একটি ডেটা স্ট্রাকচারও, তবে এর উদ্দেশ্য হল অ্যাপ্লিকেশনের বিভিন্ন স্তরে ব্যবসায়িক যুক্তিতে অংশগ্রহণ করা। একটি DTO এর উদ্দেশ্য হল অ্যাপ্লিকেশন থেকে/থেকে ডেটা পরিবহন করা। একটি DTO এর উদাহরণ:

@Setter
@Getter
@NoArgsConstructor
public class UserDto {
    private long id;
    private String firstName;
    private String lastName;
    private String email;
    private String password;
}

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

ভেরিয়েবল তৈরির নীতি

চলক সম্পর্কে একটু চিন্তা করা যাক. আরও সুনির্দিষ্টভাবে, এগুলি তৈরি করার সময় কী নীতিগুলি প্রযোজ্য তা নিয়ে চিন্তা করা যাক:

1. আদর্শভাবে, আপনি একটি ভেরিয়েবল ব্যবহার করার ঠিক আগে ঘোষণা এবং শুরু করতে হবে (একটি তৈরি করবেন না এবং এটি সম্পর্কে ভুলে যাবেন না)।
2. যখনই সম্ভব, ভেরিয়েবলগুলিকে চূড়ান্ত হিসাবে ঘোষণা করুন যাতে আরম্ভ করার পরে তাদের মান পরিবর্তন করা না হয়।
3. কাউন্টার ভেরিয়েবল সম্পর্কে ভুলবেন না, যা আমরা সাধারণত কিছু ধরনের লুপে ব্যবহার করি । অর্থাৎ, তাদের শূন্য করতে ভুলবেন না। অন্যথায়, আমাদের সমস্ত যুক্তি ভেঙ্গে যেতে পারে।
4. আপনি কনস্ট্রাক্টরে ভেরিয়েবল শুরু করার চেষ্টা করুন।
5. যদি একটি রেফারেন্স সহ বা ( new SomeObject() ব্যতীত একটি বস্তু ব্যবহার করার মধ্যে একটি পছন্দ থাকে তবে তা ছাড়াই বেছে নিন, যেহেতু অবজেক্টটি ব্যবহার করার পরে এটি পরবর্তী আবর্জনা সংগ্রহ চক্রের সময় মুছে ফেলা হবে এবং এর সংস্থানগুলি নষ্ট হবে না।
6. একটি ভেরিয়েবলের লাইফটাইম (ভেরিয়েবলের সৃষ্টি এবং শেষ বার উল্লেখ করার মধ্যে দূরত্ব) যতটা সম্ভব ছোট রাখুন।
7. লুপের ঠিক আগে একটি লুপে ব্যবহৃত ভেরিয়েবল শুরু করুন, লুপ ধারণকারী পদ্ধতির শুরুতে নয়।
8. সর্বদা সবচেয়ে সীমিত সুযোগ দিয়ে শুরু করুন এবং যখন প্রয়োজন তখনই প্রসারিত করুন (আপনার যতটা সম্ভব স্থানীয় হিসাবে একটি পরিবর্তনশীল করার চেষ্টা করা উচিত)।
9. প্রতিটি ভেরিয়েবল শুধুমাত্র একটি উদ্দেশ্যে ব্যবহার করুন।
10. একটি লুকানো উদ্দেশ্য সহ ভেরিয়েবল এড়িয়ে চলুন, যেমন দুটি কাজের মধ্যে একটি পরিবর্তনশীল বিভাজন - এর মানে হল যে এটির ধরন তাদের একটি সমাধান করার জন্য উপযুক্ত নয়।

পদ্ধতি

"স্টার ওয়ার্স: পর্ব III - রিভেঞ্জ অফ দ্য সিথ" (2005) চলচ্চিত্র থেকে

আসুন সরাসরি আমাদের যুক্তির বাস্তবায়নে এগিয়ে যাই, অর্থাৎ পদ্ধতিতে।

1. নিয়ম #1 — কম্প্যাক্টনেস। আদর্শভাবে, একটি পদ্ধতি 20 লাইনের বেশি হওয়া উচিত নয়। এর মানে হল যে যদি একটি পাবলিক পদ্ধতি উল্লেখযোগ্যভাবে "স্ফীত" হয়, তাহলে আপনাকে যুক্তিটিকে আলাদা করে আলাদা ব্যক্তিগত পদ্ধতিতে স্থানান্তরিত করার বিষয়ে চিন্তা করতে হবে।

2. নিয়ম #2 — if , else , while এবং অন্যান্য স্টেটমেন্টে ভারী নেস্টেড ব্লক থাকা উচিত নয়: প্রচুর নেস্টিং কোডের পঠনযোগ্যতা উল্লেখযোগ্যভাবে হ্রাস করে। আদর্শভাবে, আপনার দুটির বেশি নেস্টেড {} ব্লক থাকা উচিত নয়।

   এবং এই ব্লকগুলিতে কোডগুলি কমপ্যাক্ট এবং সহজ রাখাও বাঞ্ছনীয়।

3. নিয়ম #3 — একটি পদ্ধতি শুধুমাত্র একটি অপারেশন সঞ্চালন করা উচিত। অর্থাৎ, যদি একটি পদ্ধতি সব ধরণের জটিল যুক্তি সঞ্চালন করে, আমরা এটিকে সাবমেথডে বিভক্ত করি। ফলস্বরূপ, পদ্ধতিটি নিজেই একটি সম্মুখভাগ হবে যার উদ্দেশ্য হল অন্য সমস্ত ক্রিয়াকলাপগুলিকে সঠিক ক্রমে কল করা।

   কিন্তু যদি অপারেশনটি একটি পৃথক পদ্ধতিতে করা খুব সহজ বলে মনে হয়? সত্য, কখনও কখনও এটি চড়ুইদের দিকে একটি কামান চালানোর মতো মনে হতে পারে, তবে ছোট পদ্ধতিগুলি বেশ কয়েকটি সুবিধা প্রদান করে:

   • উন্নত কোড বোঝা;
   • বিকাশের অগ্রগতির সাথে সাথে পদ্ধতিগুলি আরও জটিল হয়ে উঠতে থাকে। যদি একটি পদ্ধতি শুরু করা সহজ হয়, তবে এটির কার্যকারিতা জটিল করা একটু সহজ হবে;
   • বাস্তবায়ন বিবরণ লুকানো হয়;
   • সহজ কোড পুনঃব্যবহার;
   • আরও নির্ভরযোগ্য কোড।

4. স্টেপডাউন নিয়ম — কোডটি উপরে থেকে নীচে পড়তে হবে: আপনি যত নীচে পড়বেন, ততই আপনি যুক্তির গভীরে প্রবেশ করবেন। এবং তদ্বিপরীত, আপনি উচ্চতর যান, আরো বিমূর্ত পদ্ধতি. উদাহরণস্বরূপ, সুইচ স্টেটমেন্টগুলি বরং অ-কম্প্যাক্ট এবং অবাঞ্ছিত, কিন্তু আপনি যদি একটি সুইচ ব্যবহার করা এড়াতে না পারেন, তাহলে আপনার এটিকে যতটা সম্ভব কম, সর্বনিম্ন-স্তরের পদ্ধতিতে নিয়ে যাওয়ার চেষ্টা করা উচিত।

5. পদ্ধতি যুক্তি — আদর্শ সংখ্যা কি? আদর্শভাবে, সব কিছুই :) কিন্তু যে সত্যিই ঘটবে? এটি বলেছিল, আপনার যতটা সম্ভব কম আর্গুমেন্ট রাখার চেষ্টা করা উচিত, কারণ যত কম আছে, একটি পদ্ধতি ব্যবহার করা তত সহজ এবং এটি পরীক্ষা করা তত সহজ। সন্দেহ হলে, বিপুল সংখ্যক ইনপুট পরামিতি সহ পদ্ধতিটি ব্যবহার করার জন্য সমস্ত পরিস্থিতি অনুমান করার চেষ্টা করুন।

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

7. যদি একটি পদ্ধতিতে প্রচুর পরিমাণে ইনপুট প্যারামিটার থাকে (একটি চরম 7, কিন্তু আপনার সত্যিই 2-3 পরে চিন্তা করা শুরু করা উচিত), কিছু আর্গুমেন্টকে একটি পৃথক বস্তুতে গোষ্ঠীভুক্ত করা উচিত।

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

9. আপনি যখন একটি পদ্ধতিতে পরামিতিগুলি পাস করেন, তখন আপনাকে অবশ্যই নিশ্চিত হতে হবে যে সেগুলি সবই ব্যবহৃত হয়েছে, অন্যথায় আপনার কেন সেগুলি দরকার? ইন্টারফেস থেকে কোনো অব্যবহৃত পরামিতি কেটে ফেলুন এবং এটি দিয়ে সম্পন্ন করুন।

10. ট্রাই/ক্যাচ প্রকৃতিতে খুব সুন্দর দেখায় না, তাই এটিকে একটি পৃথক মধ্যবর্তী পদ্ধতিতে (ব্যতিক্রম পরিচালনার জন্য একটি পদ্ধতি) নিয়ে যাওয়া ভাল ধারণা হবে:

    
    public void exceptionHandling(SomeObject obj) {
        try {  
            someMethod(obj);
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
    

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