"উত্তরাধিকারের তুলনায় রচনা পছন্দ করুন" কেবলমাত্র একটি উত্তম তাত্ত্বিক
আপনার প্রসঙ্গটি বিবেচনা করা উচিত, কারণ এটি কোনও সর্বজনীন নিয়ম নয়। যখন আপনি রচনাটি করতে পারেন তখন উত্তরাধিকার কখনও ব্যবহার করবেন না বলে মনে করবেন না। যদি ঘটনাটি ঘটে থাকে তবে আপনি উত্তরাধিকার নিষিদ্ধ করে এটি ঠিক করবেন would
আমি এই পোস্টটি বরাবর এই পয়েন্টটি পরিষ্কার করতে আশা করি।
আমি নিজেই রচনাটির গুণাগুণ রক্ষার চেষ্টা করব না। যা আমি বিষয় বিবেচ্য। পরিবর্তে, আমি এমন কিছু পরিস্থিতি সম্পর্কে কথা বলব যখন বিকাশকারী উত্তরাধিকার বিবেচনা করতে পারেন যা রচনা ব্যবহারের চেয়ে ভাল হবে। এই নোটটিতে, উত্তরাধিকারের নিজস্ব গুণ রয়েছে, যা আমি বিষয়টিকেও বিবেচনা করি।
গাড়ির উদাহরণ
আমি বিকাশকারীদের সম্পর্কে লিখছি যারা গল্পের উদ্দেশ্যে বোবা পথে চেষ্টা করে
যে কিছু গলি কোর্স ব্যবহার আমাদের শাস্ত্রীয় উদাহরণ একটি বৈকল্পিক জন্য যাই ... আমরা একটি আছে Vehicle, বর্গ তারপর আমরা আহরণ Car, Airplane, Balloonএবং Ship।
দ্রষ্টব্য : আপনার যদি এই উদাহরণটি গ্রাউন্ড করার দরকার হয় তবে ভিডিও গেমের মধ্যে এগুলি ধরণের জিনিস।
তারপরে Carএবং Airplaneকিছু সাধারণ কোড থাকতে পারে, কারণ তারা উভয়ই জমিতে চাকা চালাতে পারে। বিকাশকারীরা এর জন্য উত্তরাধিকার শৃঙ্খলে মধ্যস্থতাকারী শ্রেণি তৈরি বিবেচনা করতে পারে। তবুও, আসলে সেখানে কিছু মধ্যে ভাগ করা আছে কোড Airplaneএবং Balloon। তারা এর জন্য উত্তরাধিকার শৃঙ্খলে অন্য মধ্যস্থতাকারী শ্রেণি তৈরি বিবেচনা করতে পারে।
সুতরাং, বিকাশকারী একাধিক উত্তরাধিকার সন্ধান করবে। যেখানে বিকাশকারীরা একাধিক উত্তরাধিকার সন্ধান করছেন, সেখানে নকশাটি ইতিমধ্যে ভুল হয়ে গেছে।
এই আচরণটি ইন্টারফেস এবং রচনা হিসাবে মডেল করা আরও ভাল, তাই আমরা একাধিক শ্রেণির উত্তরাধিকারে না গিয়েই এটি পুনরায় ব্যবহার করতে পারি। যদি ডেভেলপারগণ, উদাহরণস্বরূপ, FlyingVehiculeবর্গ তৈরি করুন । তারা বলবে যে Airplaneএটি একটি FlyingVehicule(শ্রেণির উত্তরাধিকার), তবে আমরা পরিবর্তে বলতে পারি যে Airplaneএর একটি Flyingউপাদান (রচনা) রয়েছে এবং Airplaneএটি একটি IFlyingVehicule(ইন্টারফেস উত্তরাধিকার)।
ইন্টারফেস ব্যবহার করে, প্রয়োজনে আমাদের একাধিক উত্তরাধিকার (ইন্টারফেসের) থাকতে পারে। তদতিরিক্ত, আপনি একটি নির্দিষ্ট বাস্তবায়নে সংযুক্ত হচ্ছেন না। আপনার কোডের পুনঃব্যবহারযোগ্যতা এবং পরীক্ষাযোগ্যতা বাড়ছে।
মনে রাখবেন যে উত্তরাধিকার বহুবচন জন্য একটি সরঞ্জাম। এছাড়াও, পলিমারফিজম পুনরায় ব্যবহারযোগ্যতার একটি সরঞ্জাম। আপনি যদি রচনাটি ব্যবহার করে আপনার কোডটির পুনঃব্যবহারযোগ্যতা বাড়াতে পারেন তবে তা করুন। আপনি যদি নিশ্চিত না হন যে যাই হোক না কেন কম্পোজিশন আরও ভাল পুনঃব্যবহারযোগ্যতা সরবরাহ করে, "উত্তরাধিকারের চেয়ে কমপোজিশন পছন্দ করুন" একটি ভাল ধর্মতাত্ত্বিক।
উল্লেখ না করে সব Amphibious।
আসলে, আমাদের সম্ভবত এমন জিনিসগুলির প্রয়োজন হবে না যা মাটি থেকে যায়। স্টিফেন হার্নের তার "" অংশীদারিত্বের পক্ষে ফেভারিটে কম্বিনেশন " অংশ 1 এবং অংশ 2 এর আরও নিখুঁত উদাহরণ রয়েছে ।
সাবস্টিটিউটেবিলিটি এবং এনক্যাপসুলেশন
করা উচিত Aউত্তরাধিকারী বা রচনাতে B?
যদি এর Aকোনও বিশেষত্ব হয় Bতবে লিসকোভ প্রতিস্থাপনের নীতিটি পূরণ করা উচিত , উত্তরাধিকার টেকসই, এমনকি কাম্য। যদি এমন পরিস্থিতিতে থাকে যেখানে Aবৈধ প্রতিস্থাপন না হয় Bতবে আমাদের উত্তরাধিকার ব্যবহার করা উচিত নয়।
উদ্ভূত শ্রেণীর প্রতিরক্ষা করতে আমরা রক্ষণাত্মক প্রোগ্রামিংয়ের একটি রূপ হিসাবে রচনায় আগ্রহী হতে পারি । বিশেষত, একবার আপনি Bঅন্য বিভিন্ন উদ্দেশ্যে ব্যবহার করা শুরু করার পরে , এই উদ্দেশ্যেগুলি আরও উপযুক্ত হওয়ার জন্য এটি পরিবর্তন বা প্রসারিত করার চাপ হতে পারে। যদি ঝুঁকি থাকে যা Bএমন পদ্ধতিগুলি উন্মোচিত করতে পারে যা পরিণতিতে একটি অবৈধ রাষ্ট্র Aহতে পারে আমাদের উত্তরাধিকারের পরিবর্তে রচনাটি ব্যবহার করা উচিত। এমনকি যদি আমরা উভয়েরই লেখক Bএবং A, এটি নিয়ে চিন্তিত হওয়া কম জিনিস, তাই রচনাটি পুনরায় ব্যবহারযোগ্যতা হ্রাস করে B।
আমরা এমনকি তর্ক করতে পারি যে যদি এর মধ্যে Bএমন বৈশিষ্ট্যগুলির Aপ্রয়োজন না হয় (এবং আমরা জানি না যে এই বৈশিষ্ট্যগুলি Aবর্তমান প্রয়োগে বা ভবিষ্যতে কোনও অবৈধ অবস্থার কারণ হতে পারে ), এটি রচনাটি ব্যবহার করা ভাল ধারণা উত্তরাধিকার পরিবর্তে।
রচনাতে বাস্তবায়নগুলি স্যুইচ করার অনুমতি এবং মশকরা সহজ করার সুবিধাও রয়েছে।
দ্রষ্টব্য : এমন পরিস্থিতি রয়েছে যেখানে আমরা বিকল্পটি বৈধ হওয়া সত্ত্বেও রচনা ব্যবহার করতে চাই। আমরা ইন্টারফেস বা অ্যাবস্ট্রাক্ট ক্লাস (যা অন্য কোনও বিষয় যখন ব্যবহার করা উচিত) ব্যবহার করে সেই পরিবর্তনযোগ্যতা সংরক্ষণাগারভুক্ত করি এবং তারপরে বাস্তব বাস্তবায়নের নির্ভরতা ইনজেকশন সহ রচনাটি ব্যবহার করি।
অবশেষে অবশ্যই তর্ক রয়েছে যে আমাদের পিতামাত্ত শ্রেণির প্রতিরক্ষা করার জন্য রচনাটি ব্যবহার করা উচিত কারণ উত্তরাধিকার পিতা-মাতার শ্রেণির এনক্যাপসুলেশনকে ভেঙে দেয়:
উত্তরাধিকার তার পিতামাতার বাস্তবায়নের বিশদে একটি সাবক্লাস উন্মোচিত করে, প্রায়ই বলা হয় যে 'উত্তরাধিকার এনক্যাপসুলেশন ভেঙে যায়'
- নকশার ধরণগুলি: পুনরায় ব্যবহারযোগ্য অবজেক্ট-ওরিয়েন্টড সফ্টওয়্যার এর উপাদানসমূহ, চারটি গ্যাং
ওয়েল, এটি একটি খারাপভাবে ডিজাইন করা পিতাম শ্রেণীর। যে কারণে আপনার উচিত:
উত্তরাধিকারের জন্য ডিজাইন করুন বা এটি নিষিদ্ধ করুন।
- কার্যকর জাভা, জোশ ব্লচ
ইয়ো-ইও সমস্যা
আরও একটি ক্ষেত্রে যেখানে রচনাটি হ'ল ইয়ো-ইও সমস্যা । এটি উইকিপিডিয়া থেকে উদ্ধৃত:
সফ্টওয়্যার বিকাশে, ইয়ো-ইয়ো সমস্যাটি একটি বিরোধী-প্যাটার্ন যা ঘটে যখন কোনও প্রোগ্রামার এমন একটি প্রোগ্রাম পড়তে এবং বুঝতে হয় যার উত্তরাধিকারের গ্রাফটি এত দীর্ঘ এবং জটিল যে প্রোগ্রামারকে অনুসরণ করতে বিভিন্ন শ্রেণীর সংজ্ঞাগুলির মধ্যে ফ্লিপিং রাখতে হয় প্রোগ্রাম নিয়ন্ত্রণ প্রবাহ।
আপনি সমাধান করতে পারেন, উদাহরণস্বরূপ: আপনার ক্লাসটি Cক্লাস থেকে উত্তরাধিকারী হবে না B। পরিবর্তে আপনার ক্লাসে Cটাইপের সদস্য থাকবেন A, যা কোনও ধরণের অবজেক্ট (বা থাকতে পারে) থাকতে পারে বা নাও থাকতে পারে B। এইভাবে আপনি প্রয়োগের বিশদটির বিরুদ্ধে প্রোগ্রামিং করবেন না B, তবে ইন্টারফেসের (অফ) Aঅফার করে এমন চুক্তির বিরুদ্ধে ।
পাল্টা উদাহরণ
অনেক কাঠামো রচনার চেয়ে উত্তরাধিকারের পক্ষে (যা আমরা বিতর্ক করছি তার বিপরীতে)। বিকাশকারী এটি করতে পারে কারণ তারা তাদের বেস ক্লাসে প্রচুর কাজ ফেলেছে যে এটি রচনাটি প্রয়োগ করে ক্লায়েন্ট কোডের আকার বাড়িয়ে তুলবে। কখনও কখনও এটি ভাষার সীমাবদ্ধতার কারণে হয়।
উদাহরণস্বরূপ, একটি পিএইচপি ওআরএম কাঠামো একটি বেস ক্লাস তৈরি করতে পারে যা ম্যাজিক পদ্ধতি ব্যবহার করে কোড লেখার অনুমতি দেওয়ার জন্য যেমন বস্তুর আসল বৈশিষ্ট্য রয়েছে। পরিবর্তে যাদু পদ্ধতিগুলির দ্বারা পরিচালিত কোডটি ডাটাবেসে যাবে, নির্দিষ্ট অনুরোধ করা ক্ষেত্রের জন্য ক্যোয়ারী (সম্ভবত ভবিষ্যতের অনুরোধের জন্য এটি ক্যাশে করবে) এবং এটিকে ফিরিয়ে দেবে। কম্পোজিশনের সাথে এটি করার জন্য ক্লায়েন্টকে প্রতিটি ক্ষেত্রের জন্য বৈশিষ্ট্য তৈরি করতে হবে বা যাদু পদ্ধতিগুলির কোডের কিছু সংস্করণ লিখতে হবে।
সংযোজন : অন্য কিছু উপায় রয়েছে যেগুলি ওআরএম অবজেক্টগুলিকে প্রসারিত করতে পারে। সুতরাং, আমি মনে করি না যে এই ক্ষেত্রে উত্তরাধিকার প্রয়োজন। এটা সস্তা.
অন্য উদাহরণের জন্য, একটি ভিডিও গেম ইঞ্জিন একটি বেস ক্লাস তৈরি করতে পারে যা থ্রিডি রেন্ডারিং এবং ইভেন্ট হ্যান্ডলিংয়ের জন্য লক্ষ্য প্ল্যাটফর্মের উপর নির্ভর করে নেটিভ কোড ব্যবহার করে। এই কোড জটিল এবং প্ল্যাটফর্ম নির্দিষ্ট। ইঞ্জিনের বিকাশকারী ব্যবহারকারীর পক্ষে এই কোডটি মোকাবেলা করা ব্যয়বহুল এবং ত্রুটিযুক্ত হবে, প্রকৃতপক্ষে, এটি ইঞ্জিনটি ব্যবহারের কারণের একটি অংশ।
তদুপরি, 3 ডি রেন্ডারিং অংশ ব্যতীত এটি কতগুলি উইজেট ফ্রেমওয়ার্ক কাজ করে। এটি আপনাকে ওএস বার্তাগুলি পরিচালনা করার বিষয়ে উদ্বেগ থেকে মুক্তি দেয় ... বাস্তবে, অনেক ভাষায় আপনি কোনও স্থানীয় নেটিভ বিডিং ছাড়া এই জাতীয় কোড লিখতে পারবেন না। তদুপরি, আপনি যদি এটি করেন তবে এটি আপনার বহনযোগ্যতা শক্ত করে তুলবে। পরিবর্তে, উত্তরাধিকার সহ, বিকাশকারী সামঞ্জস্যতা (খুব বেশি) ভঙ্গ না করে; ভবিষ্যতে তারা যে কোনও নতুন প্ল্যাটফর্ম সমর্থন করে আপনি সহজেই আপনার কোডটি পোর্ট করতে সক্ষম হবেন।
তদতিরিক্ত, বিবেচনা করুন যে অনেক সময় আমরা কেবল কয়েকটি পদ্ধতি ওভাররাইড করতে চাই এবং অন্য সব কিছু ডিফল্ট বাস্তবায়নগুলি দিয়ে রেখে যাই। যদি আমরা কম্পোজিশন ব্যবহার করতাম তবে আমাদের কেবল এই সমস্ত পদ্ধতি তৈরি করতে হবে, এমনকি যদি কেবল মোড়ানো বস্তুতে প্রতিনিধি দেওয়া হয়।
এই যুক্তি দ্বারা, একটি পয়েন্ট রয়েছে যেখানে রচনা উত্তরাধিকারের চেয়ে রক্ষণাবেক্ষণের পক্ষে সবচেয়ে খারাপ হতে পারে (যখন বেস শ্রেণিটি খুব জটিল)। তবুও, মনে রাখবেন যে উত্তরাধিকারের রক্ষণাবেক্ষণ রচনাটির চেয়েও খারাপ হতে পারে (যখন উত্তরাধিকার গাছ খুব জটিল), যা আমি ইয়ো-ই সমস্যার ক্ষেত্রে উল্লেখ করি।
উপস্থাপিত উদাহরণগুলিতে, বিকাশকারীরা খুব কমই অন্যান্য প্রকল্পে উত্তরাধিকারের মাধ্যমে উত্পন্ন কোডটি পুনরায় ব্যবহার করার ইচ্ছা পোষণ করে। এটি রচনার পরিবর্তে উত্তরাধিকার ব্যবহারের হ্রাসযোগ্য পুনঃব্যবহারযোগ্যতা হ্রাস করে। তদুপরি, উত্তরাধিকার ব্যবহার করে ফ্রেমওয়ার্ক বিকাশকারীগণ প্রচুর সহজেই ব্যবহারযোগ্য এবং কোড আবিষ্কার করা সহজ সরবরাহ করতে পারেন।
সর্বশেষ ভাবনা
আপনি দেখতে পাচ্ছেন, কিছু পরিস্থিতিতে রচনাটির উত্তরাধিকারের কিছুটা সুবিধা রয়েছে, সবসময় নয়। সিদ্ধান্ত গ্রহণের জন্য প্রসঙ্গে এবং জড়িত বিভিন্ন কারণগুলির (যেমন পুনঃব্যবহারযোগ্যতা, রক্ষণাবেক্ষণযোগ্যতা, পরীক্ষাযোগ্যতা ইত্যাদি…) বিবেচনা করা গুরুত্বপূর্ণ। প্রথম বিন্দু ফিরে যান: "উত্তরাধিকার উপর রচনা পছন্দ" একটি হল শুধু ভাল অনুসন্ধানমূলক।
আপনার বিজ্ঞপ্তিও থাকতে পারে যে আমি বর্ণিত পরিস্থিতিগুলির অনেকগুলি বৈশিষ্ট্য বা মিক্সিন দিয়ে কিছুটা হলেও সমাধান করা যেতে পারে। দুঃখের বিষয়, ভাষাগুলির দুর্দান্ত তালিকার মধ্যে এগুলি সাধারণ বৈশিষ্ট্য নয় এবং এগুলি সাধারণত কিছু কর্মক্ষমতা ব্যয় করে আসে। ধন্যবাদ, তাদের জনপ্রিয় কাজিন এক্সটেনশন পদ্ধতি এবং ডিফল্ট বাস্তবায়ন কিছু পরিস্থিতি প্রশমিত করে।
আমার একটি সাম্প্রতিক পোস্ট রয়েছে যেখানে আমি ইন্টারফেসের কিছু সুবিধা সম্পর্কে কথা বলি কেন আমাদের সিআই-তে ইউআই, ব্যবসা এবং ডেটা অ্যাক্সেসের মধ্যে ইন্টারফেসের প্রয়োজন হয় । এটি ডিকপলিংয়ে সহায়তা করে এবং পুনরায় ব্যবহারযোগ্যতা এবং টেস্টাবিলিটি সহজ করে দেয়, আপনি আগ্রহী হতে পারেন।