যুগল না বাড়িয়ে ডিআরওয়াই প্রয়োগ করা কি সম্ভব?


14

ধরুন আমাদের কাছে একটি সফ্টওয়্যার মডিউল আছে যা একটি ফাংশন এফ প্রয়োগ করে Another

সদৃশ কোড থেকে মুক্তি পাওয়ার বিভিন্ন উপায় রয়েছে:

  1. বি থেকে একটি এফ ব্যবহার করুন।
  2. খ কে এ থেকে এফ ব্যবহার করতে দিন B
  3. এফটিকে তার নিজস্ব মডিউল সি-তে রাখুন এবং এ এবং বি উভয়কে এটি ব্যবহার করতে দিন।

এই সমস্ত বিকল্প মডিউলগুলির মধ্যে অতিরিক্ত নির্ভরতা তৈরি করে। তারা সংযোজন বৃদ্ধির ব্যয়ে DRY নীতি প্রয়োগ করে।

আমি যতদূর দেখতে পাচ্ছি, ডিআরওয়াই প্রয়োগ করার সময় দম্পতি সর্বদা বৃদ্ধি বা লিজ নেওয়া হয় higher সফ্টওয়্যার ডিজাইনের সবচেয়ে দুটি মূল নীতির মধ্যে বিরোধ রয়েছে বলে মনে হচ্ছে।

(আসলে আমি বিস্ময়কর বলে মনে করি না যে এরকম দ্বন্দ্ব রয়েছে। সম্ভবত এটিই ভাল সফটওয়্যার ডিজাইনকে এত কঠিন করে তুলেছে I আমি বিস্ময়কর বলে মনে করি যে সাধারণত এই দ্বন্দ্বগুলি প্রাথমিকভাবে পাঠ্যসূত্রগুলিতে সম্বোধন করা হয়নি))

সম্পাদনা (স্পষ্টকরণের জন্য): আমি ধরে নিয়েছি যে F এবং F এর সমতা কেবল একটি কাকতালীয় ঘটনা নয়। যদি F কে সংশোধন করতে হয় তবে F 'সম্ভবত একইভাবে সংশোধন করতে হবে।


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

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

2
@ টিমোথিট্রাকল: আমাদের তাদের ওও নীতিগুলি বলা উচিত নয় কারণ তারা অন্যান্য প্রোগ্রামিং দৃষ্টান্তগুলিতেও প্রয়োগ করে। এবং হ্যাঁ, ডিআরওয়াই মূল্যবান তবে ওভারডোন হলেও বিপজ্জনক। এটি নির্ভরতা এবং এইভাবে জটিলতা তৈরি করতে ঝোঁক না কেবল তাই। এটি প্রায়শই কাকতালীয় কারণে ডুপ্লিকেটগুলির ক্ষেত্রেও প্রয়োগ করা হয় যার পরিবর্তনের বিভিন্ন কারণ রয়েছে।
ফ্রাঙ্ক পাফার 19

1
... এছাড়াও কখনও কখনও যখন আমি এই দৃশ্যের দিকে দৌড়েছি তখন আমি এফটি এমন অংশগুলিতে বিভক্ত করতে সক্ষম হয়েছি যা এগুলির কী প্রয়োজন এবং কী খ প্রয়োজন তার জন্য ব্যবহারযোগ্য হতে পারে।
15'18

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

উত্তর:


14

এই সমস্ত বিকল্প মডিউলগুলির মধ্যে অতিরিক্ত নির্ভরতা তৈরি করে। তারা সংযোজন বৃদ্ধির ব্যয়ে DRY নীতি প্রয়োগ করে।

হ্যাঁ তারা কেন। তবে তারা লাইনের মধ্যে সংযোগ কমে যায়। আপনি যা পান তা হ'ল কাপলিং পরিবর্তন করার শক্তি। মিলন বিভিন্ন আকারে আসে। কোড এক্সট্র্যাক্টিং ইন্ডিরেশন এবং বিমূর্ততা বাড়িয়ে তোলে। এটি বাড়ানো ভাল বা খারাপ হতে পারে। এক নম্বর জিনিস যা সিদ্ধান্ত নেয় তা হল আপনি এটির জন্য নামটি ব্যবহার করুন। আমি ভিতরে তাকিয়ে যখন নামটির দিকে তাকানো আমাকে অবাক করে দেয় তবে আপনি কারও পক্ষে কোন লাভ করেন নি।

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

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


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

1
কিছু মনে করবেন না, আমার খারাপ: meta.stackexchange.com/a/263672/143358
Basilevs

@ ফ্র্যাঙ্কপুফার আরও ভাল?
candied_orange

3

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

শিরোনামটির উত্তর দিতে - হ্যাঁ, এটি সম্ভব, তবে রানটাইম প্রেরণের ফলাফলের জন্য প্রস্তুত থাকুন।

  • এফের কার্যকারিতা সরবরাহ করে এ- তে ইন্টারফেস এফ এটিকে সংজ্ঞায়িত করুন
  • বি তে ইন্টারফেস এফ বি সংজ্ঞা দিন
  • সি এফ রাখুন
  • সমস্ত নির্ভরতা পরিচালনা করতে মডিউল ডি তৈরি করুন (এটি এ, বি এবং সি নির্ভর করে)
  • এফ এফ খাপ খাওয়ানো একজন এবং এফ বি D এর
  • এ এবং বি তে ইনপ্রেস (পাস) মোড়ক দিন

এইভাবে, আপনার একমাত্র ধরণের নির্ভরতা হ'ল একে অপর মডিউলের উপর নির্ভর করে।

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


1
+1, তবে স্পষ্টত সাবধানতার সাথে যে এটি সাধারণত খারাপ ট্রেড অফ। স্থিতিশীল সুরক্ষাটি আপনার সুরক্ষার জন্য রয়েছে, এবং আপনার প্রকল্পের জটিলতা কিছুটা বাড়লে লাইনের আরও নিচে হার্ড-ট্র্যাক-ডাউন বাগগুলি জিজ্ঞাসা করা হচ্ছে ...
ম্যাসন হুইলার

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

@ সর্বাধিক 30৩০ এটি চুক্তিভিত্তিক বাস্তবায়ন নির্ভরতা প্রতিস্থাপন করে, যা দুর্বল।
বাসিলিভস

@ max630- কে আপনি সঠিক বলেছেন। ডিআই-কে নির্ভরতা ভাঙার কথা বলা যায় না। ডিআই প্রকৃতপক্ষে নির্ভরতা প্রবর্তনের একটি পদ্ধতি এবং সংযোগের বিষয়ে জিজ্ঞাসা করা প্রশ্নটির সত্যই সংলগ্ন। এফ পরিবর্তন (বা ইন্টারফেসটি এটি encapsulating) এখনও এ এবং বি উভয় পরিবর্তন প্রয়োজন
কিং-সাইড-স্লাইড

1

আমি নিশ্চিত নই যে আরও প্রসঙ্গ ছাড়াই উত্তরটি অর্থবোধ করে।

না Aইতিমধ্যে উপর নির্ভর করে Bবা বিপরীতভাবে ভাইস? - এই ক্ষেত্রে আমাদের কাছে বাড়ির একটি সুস্পষ্ট পছন্দ থাকতে পারে F

না Aএবং Bইতিমধ্যে ভাগ কোনো সাধারণ নির্ভরতা একটি ভাল বাসা হতে পারে যে F?

কত বড় / জটিল F? আর কিসের Fউপর নির্ভর করে?

মডিউল পারে Aএবং Bএকই প্রকল্পে ব্যবহার করেন নি?

উইল Aএবং Bভাগ করে নেওয়ার কিছু সাধারণ নির্ভরতা যাহাই হউক না কেন শেষ পর্যন্ত?

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

অন্যদিকে আপনি যদি জাভা বা সি # ডিএলএলগুলির কথা বলছেন যা একক কার্যকর পরিবেশে নির্বিঘ্নে একত্রিত হয় তবে এটি অন্য একটি বিষয়।


একটি ফাংশন একটি বিমূর্ততা, এবং DRY সমর্থন করে supports

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

সুতরাং, আমি যুক্তি করব যে কেবলমাত্র একটি একক ক্রিয়াকলাপকে নতুন মডিউলে স্থানান্তরিত করার চেয়ে আরও ভাল বিমূর্ততা তৈরি করতে Aএবং Bতার উপর নির্ভর করতে C। 

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


2
দুজনের বিমূর্ততা এবং নির্ভরতা গ্রাফটি কি বিপজ্জনক নয়?
বেসিলিভ

Does A already depend on B or vice versa? — in which case we might have an obvious choice of home for F.এটি ধরে নিয়েছে যে এ সর্বদা বি (বা বিপরীতে) এর উপর নির্ভর করবে যা একটি খুব বিপজ্জনক ধারণা um ওপিকে এফ (বা বি) এর অন্তর্নিহিত অংশ হিসাবে এফ দেখতে পাওয়া যায় তা প্রমাণ করে যে এফ কোনও লাইব্রেরির সহজাত না হয়েই বিদ্যমান। যদি এফ একটি লাইব্রেরির (উদাহরণস্বরূপ একটি ডিবিকন্টেক্সট এক্সটেনশন পদ্ধতি (এফ) এবং একটি সত্তা ফ্রেমওয়ার্ক র‌্যাপার লাইব্রেরি (এ বা বি)) এর অন্তর্ভুক্ত থাকে, তবে ওপির প্রশ্নটি মোটা হবে।
ফ্লাটার

0

এই উত্তরগুলি যেগুলি আপনি এই সমস্যাটিকে "কমাতে" পারেন তার সমস্ত উপায়কে কেন্দ্র করে আপনাকে অস্বীকার করছে। এবং "সমাধানগুলি" কেবল যুগল তৈরির বিভিন্ন উপায়ে অফার করা সত্যই কোনও সমাধান নয়।

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

নিজেকে জিজ্ঞাসা করুন কেন মডিউল A এবং B উভয়ই একই ফাংশনের উপর নির্ভর করে যদি আলাদা হয়? অবশ্যই আপনার যদি নির্ভরযোগ্যতা পরিচালন / অ্যাবস্ট্রাকশন / কাপলিং / আপনার নাম-এর সাথে সমস্যা থাকে তবে আপনি যদি একটি খারাপ ডিজাইনের প্রতিশ্রুতিবদ্ধ হন।

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

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

এবিসি এর অন্যান্য নকশা প্রিন্সিপাল (ঘন পদার্থ, শুষ্ক, ইত্যাদি) সেখানে করছে সব করতে ব্যবহার পরিবর্তন (refactoring সহ) আরো যন্ত্রণাহীন একটি অ্যাপ্লিকেশন। ফোকাস যে , এবং অন্যান্য সমস্যার সব অদৃশ্য হয়ে শুরু।


আপনি কি প্রতিটি অ্যাপ্লিকেশনটিতে ঠিক একটি মডিউল রাখার পরামর্শ দিচ্ছেন?
বেসিলিভ

@ বাসিলিভগুলি একেবারে নয় (যতক্ষণ না এটি অনুমোদিত)। আমি যতটা সম্ভব সম্পূর্ণরূপে decoupled মডিউল থাকার পরামর্শ দিই। সর্বোপরি, এটি মডিউলটির পুরো উদ্দেশ্য।
কিং-সাইড-স্লাইড

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

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

সম্পূর্ণ ভিন্ন নির্ভরতা সহ একাধিক অন্যান্য পদ্ধতি কী খারাপ মডেলিং হয়েছিল এবং কেবল এই একক-অ-দুর্ঘটনার কারণে তা আবার করতে হয়েছিল? বা আপনি কি ধরে নিয়েছেন যে, মডিউল এ এবং বি এর প্রতিটি একক পদ্ধতি রয়েছে?
বেসিলিভ

0

এই সমস্ত বিকল্প মডিউলগুলির মধ্যে অতিরিক্ত নির্ভরতা তৈরি করে। তারা সংযোজন বৃদ্ধির ব্যয়ে DRY নীতি প্রয়োগ করে।

অন্তত তৃতীয় বিকল্পের জন্য আমার আলাদা মতামত রয়েছে:

আপনার বিবরণ থেকে:

  • একটি প্রয়োজন এফ
  • খ প্রয়োজন খ
  • A বা B উভয়েরই একে অপরের দরকার নেই।

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

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.