10 অবজেক্ট ওরিয়েন্টেড প্রোগ্রামিং নীতি প্রতিটি বিকাশকারীর সম্পর্কে জানা উচিত

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

আমরা মনে করিয়ে দিচ্ছি: হাবরের সকল পাঠকদের জন্য - Habr প্রচারমূলক কোড ব্যবহার করে যেকোন স্কিলবক্স কোর্সে নথিভুক্ত করার সময় একটি 10 রুবেল ছাড়।

Skillbox সুপারিশ করে: শিক্ষাগত অনলাইন কোর্স "জাভা ডেভেলপার".

শুকনো (নিজেকে পুনরাবৃত্তি করবেন না)

একটি মোটামুটি সহজ নীতি, যার সারাংশ নাম থেকে স্পষ্ট: "নিজেকে পুনরাবৃত্তি করবেন না।" একজন প্রোগ্রামারের জন্য, এর মানে ডুপ্লিকেট কোড এড়ানোর প্রয়োজন, সেইসাথে তাদের কাজে বিমূর্ততা ব্যবহার করার সুযোগ।

যদি কোডে দুটি পুনরাবৃত্তিমূলক বিভাগ থাকে তবে সেগুলিকে একটি পদ্ধতিতে একত্রিত করা উচিত। যদি একটি হার্ডকোডেড মান একাধিকবার ব্যবহার করা হয়, তবে এটিকে একটি পাবলিক কনস্ট্যান্টে রূপান্তর করা মূল্যবান।

কোডটি সহজ করার জন্য এবং এটি বজায় রাখা সহজ করার জন্য এটি প্রয়োজনীয়, যা OOP এর মূল লক্ষ্য। আপনারও ইউনিয়নের অতিরিক্ত ব্যবহার করা উচিত নয়, যেহেতু একই কোডটি OrderId এবং SSN উভয়ের সাথেই যাচাইকরণ পাস করবে না।

এনক্যাপসুলেটিং পরিবর্তন

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

আপনি যদি জাভাতে লিখবেন, তাহলে ডিফল্টরূপে ব্যক্তিগত পদ্ধতি এবং ভেরিয়েবল বরাদ্দ করুন.

খোলা/বন্ধ নীতি

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

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

এখানে কোডের একটি উদাহরণ যা এই নীতি লঙ্ঘন করে।

আপনার যদি এটিতে কিছু পরিবর্তন করতে হয় তবে এটি অনেক সময় নেবে, যেহেতু পছন্দসই খণ্ডের সাথে সংযোগ রয়েছে এমন কোডের সমস্ত বিভাগ পরিবর্তন করতে হবে।

যাইহোক, উন্মুক্ততা-বন্ধতা হল SOLID-এর অন্যতম নীতি।

একক দায়িত্ব নীতি (এসআরপি)

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

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

নির্ভরতা বিপরীত নীতি (DIP)

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

ডিআইপি ব্যবহার করে সমস্যাটি সমাধান করা যেতে পারে। সুতরাং, AppManager-এর পরিবর্তে, আমরা একটি EventLogWriter অনুরোধ করছি, যা ফ্রেমওয়ার্ক ব্যবহার করে প্রবেশ করা হবে।

ডিআইপি নির্ভরতা মডিউল পরিবর্তন করে সহজেই পৃথক মডিউল অন্যদের সাথে প্রতিস্থাপন করা সম্ভব করে। এটি অন্যদের প্রভাবিত না করে একটি মডিউল পরিবর্তন করা সম্ভব করে তোলে।

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

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

কম্পোজিশন আপনাকে একটি ক্লাসের বৈশিষ্ট্য সেট করে রানটাইমে তার আচরণ পরিবর্তন করার ক্ষমতা দেয়। ইন্টারফেস বাস্তবায়ন করার সময়, পলিমরফিজম ব্যবহার করা হয়, যা আরও নমনীয় বাস্তবায়ন দেয়।

এমনকি জোশুয়া ব্লচের কার্যকরী জাভা উত্তরাধিকারের চেয়ে রচনা বেছে নেওয়ার পরামর্শ দেয়।

বারবারা লিসকভ প্রতিস্থাপন নীতি (এলএসপি)

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

LSP একক দায়িত্ব নীতি এবং ভাগ করা দায়িত্ব নীতি উভয়ের সাথেই যুক্ত। যদি একটি ক্লাস একটি সাবক্লাসের চেয়ে বেশি কার্যকারিতা প্রদান করে, তবে পরবর্তীটি এই নীতি লঙ্ঘন করে কিছু কার্যকারিতা সমর্থন করবে না।

এখানে কোডের একটি অংশ যা LSP এর সাথে বিরোধিতা করে।

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

এই নীতি, যা একটি সাব-টাইপের একটি নির্দিষ্ট সংজ্ঞা, বারবারা লিসকভ 1987 সালের "ডেটা অ্যাবস্ট্রাকশন এবং হায়ারার্কি" শিরোনামের একটি সম্মেলনের মূল বক্তব্যে প্রস্তাব করেছিলেন, তাই এর নাম।

ইন্টারফেস বিভক্ত নীতি (ISP)

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

প্রায়শই, এই পরিস্থিতিটি ঘটে যখন ইন্টারফেসে একবারে বেশ কয়েকটি ফাংশন থাকে এবং ক্লায়েন্টের শুধুমাত্র একটির প্রয়োজন হয়।

যেহেতু একটি ইন্টারফেস লেখা একটি কঠিন কাজ, তাই কাজ শেষ হওয়ার পরে কিছু না ভেঙে এটি পরিবর্তন করা একটি চ্যালেঞ্জ হবে।

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

ইন্টারফেসের জন্য প্রোগ্রামিং, বাস্তবায়ন নয়

শিরোনাম থেকে এখানে সবকিছু পরিষ্কার। এই নীতিটি প্রয়োগ করা নমনীয় কোড তৈরির দিকে নিয়ে যায় যা ইন্টারফেসের যেকোনো নতুন বাস্তবায়নের সাথে কাজ করতে পারে।

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

যে:

তালিকা সংখ্যা = getNumbers();

কিন্তু না:

অ্যারেলিস্ট সংখ্যা = getNumbers();

উপরে যা আলোচনা করা হয়েছে তার একটি বাস্তব বাস্তবায়ন এখানে।

প্রতিনিধিত্বের নীতি

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

নীতির সুবিধা হল কোডের কোন সদৃশতা নেই এবং আচরণ পরিবর্তন করা তুলনামূলকভাবে সহজ। এটি ইভেন্ট প্রতিনিধিদের ক্ষেত্রেও প্রযোজ্য।

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

Skillbox সুপারিশ করে:

• ব্যবহারিক কোর্স "মোবাইল ডেভেলপার প্রো".
• অনলাইন কোর্সের আবেদন করা হয়েছে "পাইথন ডেটা বিশ্লেষক".
• দুই বছরের ব্যবহারিক কোর্স "আমি একজন প্রো ওয়েব ডেভেলপার".

উত্স: www.habr.com