কনস্ট্রাক্টরে "নতুন" ব্যবহার করা কি সবসময়ই খারাপ?

Question

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

Comments

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

— ডেভিড আরনো

"সর্বদা" সর্বদা ভুল। :) সেরা অনুশীলন আছে, কিন্তু ব্যতিক্রম প্রচুর।

— পল

এই কি ভাষা? newবিভিন্ন ভাষায় বিভিন্ন জিনিস।

— ইউজার 2357112 মনিকাকে

এই প্রশ্নটি ভাষার উপর কিছুটা নির্ভর করে, তাই না? সমস্ত ভাষার এমনকি একটি newকীওয়ার্ড নেই। আপনি কোন ভাষা সম্পর্কে জিজ্ঞাসা করছেন?

— ব্রায়ান ওকলে 22

নির্বোধ নিয়ম। "নতুন" কীওয়ার্ডটির সাথে আপনার খুব কম ব্যবহার করা উচিত যখন নির্ভরতা ইনজেকশন ব্যবহার করতে ব্যর্থ । "আপনি যদি নির্ভরতা বিপরীতমুখীতা ভাঙতে ব্যবহার করেন তবে নতুন ব্যবহার করা একটি সমস্যা" এর পরিবর্তে কেবল "নির্ভরতা বিপর্যয় ভাঙবেন না" বলুন।

— ম্যাট টিমারম্যানস

Answer 1

সর্বদা ব্যতিক্রম আছে, এবং আমি শিরোনামে 'সর্বদা' নিয়ে বিষয়টি নিয়ে থাকি, তবে হ্যাঁ, এই নির্দেশিকাটি সাধারণত বৈধ এবং এটি নির্মাণকারীর বাইরেও প্রযোজ্য।

কনস্ট্রাক্টরে নতুন ব্যবহার করা সলাইডে ডি লঙ্ঘন করে (নির্ভরতা বিপরীত নীতি)। এটি আপনার কোডটিকে পরীক্ষা করা শক্ত করে তোলে কারণ ইউনিট টেস্টিং সমস্ত বিচ্ছিন্নতা সম্পর্কে; শ্রেণিটির বিচ্ছিন্নকরণ যদি এটির নিবিড় উল্লেখ থাকে তবে তা শক্ত।

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

কনস্ট্রাক্টরে নতুন ব্যবহার না করা আপনার কোডটিকে আরও নমনীয় করে তোলে। এটি সেই ভাষাগুলিতেও প্রযোজ্য যা newঅবজেক্ট ইনিশিয়েশন ব্যতীত অন্য নির্মাণগুলি ব্যবহার করতে পারে ।

তবে, স্পষ্টতই, আপনার ভাল রায় ব্যবহার করা দরকার। প্রচুর সময় ব্যবহার করা ঠিক হয় new, বা যেখানে এটি না করাই ভাল হবে তবে আপনার নেতিবাচক পরিণতি হবে না। কোথাও কোথাও কোথাও ফোন newকরতে হবে। newএকটি ক্লাসের ভিতরে কল করার বিষয়ে খুব সতর্কতা অবলম্বন করুন যা অন্যান্য অনেক শ্রেণীর উপর নির্ভর করে।

আপনার কনস্ট্রাক্টরের খালি ব্যক্তিগত সংগ্রহের সূচনা করার মতো কিছু করা ঠিক আছে, এবং এটি ইনজেকশন করা অযৌক্তিক হবে।

কোনও শ্রেণীর কাছে এটির যত বেশি রেফারেন্স রয়েছে, ততই সতর্কতার সাথে আপনার এর newমধ্যে থেকে কল না দেওয়া উচিত ।

Comments

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

— ভু

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

— ভু

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

— ভু

আমি হ্রাস পেয়েছি কারণ এটি প্রচুর পরিমাণে বুজওয়ার্ড স্যুপ এবং ব্যবহারিক বিবেচনার বিষয়ে খুব বেশি আলোচনা নয়। দুটি ডিবিতে রেপো সম্পর্কে কিছু আছে, তবে সত্যি কথা, এটি সত্যিকারের বিশ্ব উদাহরণ নয়।

— jpmc26

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

— আর শ্মিটজ

Answer 2

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

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

---

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

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

Comments

+1 টি। এটা ঠিক ঠিক। শ্রেণীর 'উদ্দেশ্যমূলক আচরণ কী' তা আপনাকে সনাক্ত করতে হবে এবং এটি নির্ধারণ করে যে কোন প্রয়োগের বিবরণ প্রকাশ করা দরকার এবং কোনটি নয়। ক্লাসের "দায়িত্ব" কী, তা নির্ধারণের সাথে আপনাকে খেলতে হবে এক ধরণের সূক্ষ্ম অন্তর্নিহিত খেলা।

— jpmc26

Answer 3

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

Comments

Not all collaborators are interesting enough to unit-test separatelyগল্পের শেষ :-), এই মামলাটি সম্ভব এবং কেউ উল্লেখ করার সাহস পেল না। @ জোপ্পে আমি আপনাকে উত্তরটি কিছুটা বিস্তৃত করতে উত্সাহিত করি। উদাহরণস্বরূপ, আপনি ক্লাসগুলির কয়েকটি উদাহরণ যুক্ত করতে পারেন যা নিছক বাস্তবায়নের বিবরণ (প্রতিস্থাপনের জন্য উপযুক্ত নয়) এবং যদি আমরা এটি প্রয়োজনীয় মনে করি তবে কীভাবে সেগুলি উত্তোলন করা যায়।

— লাইভ

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

— জোপ্পে

+1, একেবারে। একটি ভাষা আপনি যাতে আপ সেট করা থাকে আছে ডাকতে new File()কিছু ফাইল সংক্রান্ত করতে, যে কল বাধা দিত কোন মানে নেই। আপনি কী করতে যাচ্ছেন, stdlib এর Fileমডিউলের বিরুদ্ধে রিগ্রেশন টেস্ট লিখুন ? তেমন কিছু নাহ. অন্যদিকে, newএকটি স্ব-উদ্ভাবিত শ্রেণিতে কল করা আরও সন্দেহজনক।

— কিলিয়ান ফট

@ কিলিয়ানফথ: শুভকামনা ইউনিট যেকোনো কিছু যা সরাসরি কল করে new File()তা পরীক্ষা করে।

— ফোশি

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

— লাইভ

Answer 4

যেহেতু আমি ইউনিট পরীক্ষায় সত্যই অভিজ্ঞ নই, তাই আমি কিছু নিয়ম সংগ্রহ করার চেষ্টা করছি যা আমি প্রথমে শিখব।

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

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

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

---

আপনার প্রকৃত প্রশ্নের হিসাবে, আমি একটি বন্দর এবং অ্যাডাপ্টারের পদ্ধতির পক্ষে থাকি, যেখানে আমরা "কোর লজিক" এবং "পরিষেবাদি" (এটি খাঁটি ফাংশন এবং কার্যকর পদ্ধতিগুলির মধ্যে পার্থক্য করার মতো) similar

মূল যুক্তি সমস্যাটি ডোমেনের উপর ভিত্তি করে অ্যাপ্লিকেশনটির "অভ্যন্তর" গণনা করা। মনে হচ্ছে ক্লাস থাকতে পারে User, Document, Order, Invoice, ইত্যাদিতে এর জরিমানা কোর শ্রেণীর কল করতে newঅন্য কোর শ্রেণীর জন্য, যেহেতু তারা "অভ্যন্তরীণ" বাস্তবায়ন বিবরণ। উদাহরণস্বরূপ, একটি Orderশক্তি তৈরি করা একটি আদেশ তৈরি করে Invoiceএবং Documentকী অর্ডার দেওয়া হয়েছিল তার বিশদও তৈরি করে । পরীক্ষার সময় এগুলি উপহাস করার দরকার নেই, কারণ এটি হ'ল প্রকৃত জিনিস যা আমরা পরীক্ষা করতে চাই!

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

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

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

Answer 5

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

সর্বদা ব্যতিক্রম রয়েছে, তবে হ্যাঁ, এই নিয়মটি সাধারণত বৈধ এবং এটি নির্মাণকারীর বাইরেও প্রযোজ্য।

একটি কন্সট্রাকটর নতুন ব্যবহার লঙ্ঘন ডি এ কঠিন (নির্ভরতা বিপর্যয় প্রধান)। এটি আপনার কোডটিকে পরীক্ষা করা শক্ত করে তোলে কারণ ইউনিট টেস্টিং সমস্ত বিচ্ছিন্নতা সম্পর্কে; শ্রেণিটির বিচ্ছিন্নকরণ যদি এটির নিবিড় উল্লেখ থাকে তবে তা শক্ত।

-TheCatWhisperer-

হ্যাঁ, newঅভ্যন্তরীণ কনস্ট্রাক্টর ব্যবহার করে প্রায়শই ডিজাইনের ত্রুটি বাড়ে (উদাহরণস্বরূপ টাইট-কাপলিং) যা আমাদের নকশাটি অনমনীয় করে তোলে। হ্যাঁ পরীক্ষা করা শক্ত , তবে অসম্ভব নয়। এখানে খেলার সম্পত্তি হ'ল স্থিতিস্থাপকতা (পরিবর্তনের প্রতি সহনশীলতা) ¹ ।

তবুও, উপরোক্ত উদ্ধৃতি সর্বদা সত্য নয়। কিছু ক্ষেত্রে, এমন ক্লাস থাকতে পারে যা বোঝার জন্য দৃly়তার সাথে মিলিত হয় । ডেভিড আরনো একটি দম্পতি মন্তব্য করেছেন।

এখানে অবশ্যই ব্যতিক্রম রয়েছে যেখানে শ্রেণিটি একটি অপরিবর্তনীয় মান বস্তু, একটি বাস্তবায়ন বিশদ ইত্যাদি Where যেখানে তাদের দৃ tight়ভাবে মিলিত হওয়ার কথা ।

-ডেভিড আরনো-

যথাযথভাবে। কিছু শ্রেণি (উদাহরণস্বরূপ অভ্যন্তরীণ-শ্রেণি) মূল শ্রেণীর কেবল প্রয়োগের বিবরণ হতে পারে। এগুলি মূল শ্রেণীর পাশাপাশি পরীক্ষা করার জন্য বোঝানো হয় এবং এগুলি অগত্যা প্রতিস্থাপনযোগ্য বা প্রসারিত হয় না।

তদুপরি, যদি আমাদের সলিড কাল্ট আমাদের এই ক্লাসগুলি উত্তোলন করে তোলে , আমরা অন্য একটি ভাল নীতি লঙ্ঘন করতে পারি। ডেমিটারের তথাকথিত আইন । যা অন্যদিকে, আমি এটি ডিজাইনের দৃষ্টিকোণ থেকে সত্যই গুরুত্বপূর্ণ বলে মনে করি।

সুতরাং যথারীতি সম্ভবত উত্তরটি নির্ভর করে । অভ্যন্তর নির্মাণকারীদের ব্যবহার newকরা একটি খারাপ অভ্যাস হতে পারে। কিন্তু নিয়মিতভাবে সবসময় না।

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

---

^{1: SOLID এর মূল লক্ষ্যটি আমাদের কোডটিকে আরও পরীক্ষামূলক করে তোলা না। এটি আমাদের কোডকে পরিবর্তনের প্রতি আরও সহনশীল করে তোলা। আরও নমনীয় এবং ফলস্বরূপ, পরীক্ষা করা সহজ}

^{দ্রষ্টব্য: ডেভিড আরনো, দ্য হুইসারকিট, আমি আশা করি আপনার আপত্তি নেই আমি আপনাকে উদ্ধৃত করেছি।}

Answer 6

একটি সাধারণ উদাহরণ হিসাবে, নিম্নলিখিত সিউডোকোড বিবেচনা করুন

class Foo {
  private:
     class Bar {}
     class Baz inherits Bar {}
     Bar myBar
  public:
     Foo(bool useBaz) { if (useBaz) myBar = new Baz else myBar = new Bar; }
}

যেহেতু এর newবিশুদ্ধ বাস্তবায়ন বিশদ Foo, এবং উভয়ই Foo::Barএবং Foo::Bazএর অংশ Foo, যখন এর ইউনিট পরীক্ষার Fooঅংশগুলি উপহাস করার কোনও মানে হয় না Foo। ইউনিট-টেস্টিংয়ের সময় আপনি কেবল বাহিরের অংশগুলি উপহাস করেন ।FooFoo

Answer 7

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

সম্পাদনা: ডাউনভোটারদের জন্য - সম্ভাব্য কোডের গন্ধ হিসাবে 'নতুন' পতাকাঙ্কিত একটি সফ্টওয়্যার বিকাশের বইয়ের লিঙ্কটি এখানে রয়েছে: https://books.google.com/books?id=18SuDgAAQBAJ&lpg=PT169&dq=new%20keyword%20code%20smell&pg=PT169 # বনাম = onepage & Q = নতুন% 20keyword% 20code% 20smell & F = মিথ্যা

Comments

Yes, using 'new' in your non-root classes is a code smell. It means you are locking the class into using a specific implementation, and will not be able to substitute another.কেন এটি একটি সমস্যা? নির্ভরতা গাছের প্রতিটি একক নির্ভরতা প্রতিস্থাপনের জন্য উন্মুক্ত হওয়া উচিত নয়

— লাইব

@ পল: একটি ডিফল্ট বাস্তবায়ন হওয়ার অর্থ আপনি ডিফল্ট হিসাবে নির্দিষ্ট কংক্রিটের ক্লাসের জন্য দৃ .়ভাবে আবদ্ধ রেফারেন্স গ্রহণ করেন। যদিও এটি তথাকথিত "কোড গন্ধ" করে না।

— রবার্ট হার্ভে

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

— রবার্ট হার্ভে 16

"আরও নমনীয়" স্বয়ংক্রিয়ভাবে "আরও ভাল" হয় না।

— 1'18 এ হোয়াজসাম

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

— রবার্ট হার্ভে