আমি জানি যে পদ্ধতিটি খারাপ ইনপুটটি ফিরিয়ে দিতে পারে না এমন কি আমি যদি কোনও পদ্ধতি কলের রিটার্ন মানটি যাচাই করেছিলাম?

Question

আমি ভাবছি যে আমি যে পদ্ধতিতে কল করছি সে পদ্ধতিটি এই ধরনের প্রত্যাশা পূরণ করবে কিনা তা জানার পরেও যদি আমি জানতে পারি যে কোনও পদ্ধতি কলের রিটার্ন মানটির সাথে বৈধতা দিয়ে তারা আমার প্রত্যাশা পূরণ করে?

GIVEN

User getUser(Int id)
{
    User temp = new User(id);
    temp.setName("John");

    return temp;
}

আমি কি উচিত

void myMethod()
{
    User user = getUser(1234);
    System.out.println(user.getName());
}

অথবা

void myMethod()
{
    User user = getUser(1234);

    // Validating
    Preconditions.checkNotNull(user, "User can not be null.");
    Preconditions.checkNotNull(user.getName(), "User's name can not be null.");

    System.out.println(user.getName());
}

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

---

সমস্ত উত্তর থেকে আমার উপসংহার (আপনার নিজের কাছে আসা নির্দ্বিধায়):

দৃsert়তা যখন

• পদ্ধতিটি অতীতে দুর্ব্যবহার দেখিয়েছে
• পদ্ধতিটি একটি অবিশ্বস্ত উত্স থেকে
• পদ্ধতিটি অন্য জায়গা থেকে ব্যবহৃত হয় এবং এটি স্পষ্টভাবে তার পোস্ট-শর্তগুলির বিবরণ দেয় না

যখন দাবী করবেন না:

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

Comments

% 100 কোড কভারেজের জন্য লক্ষ্য!

— জ্যারেড বুরোস 3

আপনি কেন কেবল একটি সমস্যার দিকে মনোযোগ দিচ্ছেন ( Null)? নামটি ""(নাল নয়, খালি স্ট্রিং) বা হয় তবে এটি সম্ভবত সমান সমস্যাযুক্ত "N/A"। হয় আপনি ফলাফলটি বিশ্বাস করতে পারেন, বা আপনাকে যথাযথভাবে ভ্রান্ত হতে হবে।

— MSalters

আমাদের কোডবেসে আমাদের একটি নামকরণের পরিকল্পনা রয়েছে: getFoo () শূন্য না ফেরার প্রতিশ্রুতি দেয় এবং getFooIfPstream () নਾਲ ফিরে আসতে পারে।

— pjc50

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

— জিব্ববজ

@ এসএমএলটাররা যদি মানটি থাকে তবে তা বৈধ করবেন না ;)

— ইজকাটা

Answer 1

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

যদি আপনি কোনওভাবে নিশ্চিতভাবে জানতে পারেন যে getUser ভবিষ্যতে কখনই, কখনই, কখনও পরিবর্তন হতে পারে না, তবে হ্যাঁ এটি যাচাই করা সময়ের অপচয়, যতক্ষণ না iকোনও i = 3;বিবৃতি দেওয়ার পরপরই 3 এর মান থাকে যা যাচাইয়ের সময় নষ্ট করে । বাস্তবে, আপনি এটি জানেন না। তবে কিছু জিনিস যা আপনি জানেন:

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

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

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

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

Comments

এছাড়াও: আপনি যদি getUserপরে পরিবর্তন করতে চান , যাতে এটি বাতিল হয়ে যায়, সুস্পষ্ট চেকটি আপনাকে "নালপয়েন্টারএক্সেপশন" এবং লাইন নম্বর থেকে প্রাপ্ত তথ্য সরবরাহ করতে পারে?

— ব্যবহারকারী 253751

দেখে মনে হচ্ছে আপনি দুটি জিনিস যাচাই করতে পারেন: (1) যে পদ্ধতিটি সঠিকভাবে কাজ করে, যেমন এটির কোনও বাগ নেই। (২) পদ্ধতিটি আপনার চুক্তিকে সম্মান করে। আমি ওভারকিল হওয়ার জন্য # 1 এর জন্য বৈধতা দেখতে পাচ্ছি। পরিবর্তে আপনার # 1 করার পরীক্ষা করা উচিত। যে কারণে আমি i = 3; যাচাই করবো না। সুতরাং আমার প্রশ্ন # 2 এর সাথে সম্পর্কিত। আমি এর জন্য আপনার উত্তরটি পছন্দ করি তবে একই সাথে এটি আপনার রায় সংক্রান্ত উত্তরটিও ব্যবহার করে। আপনার চুক্তি স্পষ্টভাবে বৈধকরণের পরে উত্থাপনটি লেখার জন্য কিছুটা সময় নষ্ট করা থেকে শুরু করে অন্য কোনও সমস্যা দেখছেন?

— দিদিয়ের এ।

কেবলমাত্র অন্য একটি "সমস্যা" হ'ল যদি আপনার চুক্তির ব্যাখ্যাটি ভুল হয় বা ভুল হয়ে যায় তবে আপনাকে সমস্ত বৈধতা পরিবর্তন করতে হবে। তবে এটি অন্যান্য সমস্ত কোডের ক্ষেত্রেও প্রযোজ্য।

— Ixrec

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

— দিদিয়ার এ।

Answer 2

Ixrec এর উত্তর ভাল, তবে আমি একটি ভিন্ন পদ্ধতির গ্রহণ করব কারণ আমি বিশ্বাস করি যে এটি বিবেচনাযোগ্য। এই আলোচনার উদ্দেশ্যে আমি দৃser়তার সাথে কথা বলব, যেহেতু এটিই আপনার নামটি Preconditions.checkNotNull()traditionতিহ্যগতভাবে পরিচিত।

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

আমার উদ্দেশ্য:

আপনার যে প্রশ্নটি সর্বদা নিজেকে জিজ্ঞাসা করা উচিত তা হ'ল "আমি কি এটিকে জোর দেওয়া উচিত?" তবে "আমি এমন কিছু বলতে চাই যা ভুলে যেতে ভুলে গেছি?"

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

তবে এই নিয়মের ব্যতিক্রমও রয়েছে। অদ্ভুতভাবে যথেষ্ট, Ixrec উদাহরণ নেওয়া, সেখানে পরিস্থিতি এক ধরনের যেখানে এটি পুরোপুরি অনুসরণ করতে কাম্য বিদ্যমান int i = 3;একটি বিবৃতি দিয়ে iএকটি নির্দিষ্ট পরিসীমা মধ্যে পতিত হয়। এটি এমন পরিস্থিতি যেখানে iকোনও ব্যক্তি যদি বিভিন্ন কী-যদি পরিস্থিতি চেষ্টা করে যাচ্ছেন এবং তারপরে কোডটি iএকটি নির্দিষ্ট পরিসরের মধ্যে একটি মান থাকার উপর নির্ভর করে এবং তারপরে নিম্নলিখিত কোডটি দেখে কী তাড়াতাড়ি স্পষ্ট হয় না তা পরিবর্তনের জন্য দায়বদ্ধ গ্রহণযোগ্য পরিসীমা হয়। সুতরাং, int i = 3; assert i >= 0 && i < 5;প্রথমে অযৌক্তিক মনে হতে পারে তবে আপনি যদি এটির বিষয়ে চিন্তা করেন তবে এটি আপনাকে বলে যে আপনি খেলতে পারেন i, এবং এটি আপনাকে আপনাকে অবশ্যই থাকতে হবে যে পরিসীমাটির মধ্যে আপনাকে থাকতে হবে tells একটি দৃ .়তা হ'ল ডকুমেন্টেশনের সেরা ধরণ, কারণএটি মেশিন দ্বারা প্রয়োগ করা হয় , সুতরাং এটি একটি নিখুঁত গ্যারান্টি, এবং এটি কোডের সাথে একসাথে রিফেক্টর হয় , তাই এটি সর্বদা প্রাসঙ্গিক থাকে remains

আপনার getUser(int id)উদাহরণ উদাহরণের খুব দূরবর্তী ধারণাগত আপেক্ষিক নয় assign-constant-and-assert-in-range। আপনি দেখুন, সংজ্ঞা অনুসারে, বাগগুলি ঘটে যখন জিনিসগুলি এমন আচরণ প্রদর্শন করে যা আমাদের প্রত্যাশিত আচরণের থেকে পৃথক। সত্য, আমরা সবকিছু দৃsert় করতে পারি না, তাই কখনও কখনও কিছু ডিবাগ হবে। তবে এটি শিল্পের একটি সুপ্রতিষ্ঠিত সত্য যে আমরা যত দ্রুত ত্রুটি ধরি ততই কম ব্যয় হয়। আপনার যে প্রশ্নগুলি জিজ্ঞাসা করা উচিত সেগুলি কেবলমাত্র আপনিই নিশ্চিত যে getUser()এটি কখনই শূন্য হয় না, (এবং কোনও নাল নাম দিয়ে কোনও ব্যবহারকারীকে কখনই ফেরত দেবে না), তবে কোডের বাকী অংশে যদি কী ঘটে থাকে তবে কী ধরণের খারাপ জিনিস ঘটবে তা নয় are আসলে একদিন অপ্রত্যাশিত কিছু প্রত্যাবর্তন করে এবং কী কোডটি প্রত্যাশিত ছিল তা সুনির্দিষ্টভাবে জানতে বাকি কোডটি দ্রুত দেখলে এটি কতটা সহজ getUser()।

যদি অপ্রত্যাশিত আচরণের ফলে আপনার ডাটাবেসটি দুর্নীতিগ্রস্থ হয়ে পড়ে, তবে সম্ভবত আপনি 101% নিশ্চিত হওয়া সত্ত্বেও এটি দৃ won't়ভাবে করা উচিত should যদি কোনও nullব্যবহারকারীর নাম হাজার হাজার লাইন আরও নিচে এবং কয়েক বিলিয়ন ঘড়ির চক্র পরে কিছু অদ্ভুত ক্রিপ্টিক আনসারসযোগ্য ত্রুটির কারণ হয়ে থাকে, তবে সম্ভবত যত তাড়াতাড়ি সম্ভব ব্যর্থ হওয়া ভাল।

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

Comments

হ্যাঁ। এটি জোড়। আমি এখানে কম-বেশি এই উত্তর দিতে এসেছি। ++

— রাবারডাক

@SteveJessop আমি এই সংশোধন হবে ... && sureness < 1)।

— মাইক নাকিস

@ মাইকনাকিস: ইউনিট টেস্টগুলি লেখার সময় এটি সর্বদা একটি দুঃস্বপ্ন, ইন্টারফেসের মাধ্যমে অনুমোদিত রিটার্ন মান যা কোনও ইনপুট থেকে পাওয়া অসম্ভব ;-) যাইহোক, আপনি যখন ১০১% নিশ্চিত হন যে আপনি ঠিক আছেন তবে আপনি অবশ্যই ভুল !

— স্টিভ জেসোপ

জিনিসগুলিকে নির্দেশ করার জন্য +1 আমি আমার উত্তরে উল্লেখ করতে ভুলে গেছি।

— Ixrec

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

— দিদিয়ের এ।

Answer 3

একটি নির্দিষ্ট নম্বর।

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

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

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

Comments

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

— AK_

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

— দিদিয়ের এ।

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

— পল

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

— পল 11

Answer 4

যদি নালটি getUser পদ্ধতির বৈধ রিটার্ন মান হয়, তবে আপনার কোডটি যদি একটি ব্যতিক্রম নয় তবে একটি যদি এটি দিয়ে পরিচালনা করে তবে এটি ব্যতিক্রমী কেস নয়।

যদি নালটি গেট ইউজার পদ্ধতির বৈধ রিটার্ন মান না হয় তবে গেট ইউজারে একটি বাগ রয়েছে - গেট ইউজার পদ্ধতিটি একটি ব্যতিক্রম ছোঁড়া উচিত বা অন্যথায় স্থির করা উচিত।

যদি getUser পদ্ধতিটি একটি বাহ্যিক গ্রন্থাগারের অংশ হয় বা অন্যথায় পরিবর্তন করা যায় না এবং আপনি ব্যর্থতা নাল ফেরার ক্ষেত্রে নিক্ষেপ করতে চান, চেকটি সম্পাদন করার জন্য ক্লাস এবং পদ্ধতিটি মোড়ক করুন এবং ব্যতিক্রমটি ছুঁড়ে দিন যাতে প্রতিটি উদাহরণ getUser- এ কল আপনার কোডের সাথে সামঞ্জস্যপূর্ণ।

Comments

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

— দিদিয়ের এ।

এবং getUser বা user.getName ব্যতিক্রম ছোঁড়ার পরিবর্তন হলে কী হবে? আপনার একটি চেক থাকা উচিত, তবে ব্যবহারকারীর ব্যবহার পদ্ধতি হিসাবে নয়। আপনার চুক্তি কার্যকর করতে গেট ইউজার পদ্ধতিটি - এমনকি ব্যবহারকারীর শ্রেণি মোড়ক করুন, যদি আপনি getUser কোড ব্রেকিংয়ের ভবিষ্যতে পরিবর্তনগুলি নিয়ে উদ্বিগ্ন হন। শ্রেণীর আচরণ সম্পর্কে আপনার অনুমানগুলি পরীক্ষা করতে ইউনিট পরীক্ষাও তৈরি করুন।

— ম্যাথিউসি

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

— ভিন্স ও'সুলিভান

@ ভিনসো'সুলিভান মনে হচ্ছে "চুক্তি" ইস্যুটির কেন্দ্রবিন্দুতে রয়েছে। এবং যে আমার প্রশ্ন অন্তর্নিহিত চুক্তি সম্পর্কে, সুস্পষ্ট বনাম। এমন একটি পদ্ধতি যা পূর্বাবস্থায় ফিরে আসে আমি দৃ as়তার সাথে বলব না যে আমি স্ট্রিং পাচ্ছি না। তবে, আমি যদি কেবল ইতিবাচক অন্তর্চিহ্নগুলি চাই তবে আমার উচিত? এটি কেবল অন্তর্নিহিত যে পদ্ধতিটি নেতিবাচক কোনটি ফেরায় না, কারণ আমি এটি পরিদর্শন করেছি। স্বাক্ষর বা ডকুমেন্টেশন যা এটি দেয় না তা থেকে এটি পরিষ্কার নয়।

— দিদিয়ার এ।

চুক্তিটি অন্তর্নিহিত বা স্পষ্ট কিনা তা বিবেচ্য নয়। বৈধ ডেটা দেওয়ার সময় কল পদ্ধতিটি বৈধ ডেটা ফেরত দেয় যাচাই করা কলিং কোডের কাজ নয়। উদাহরণস্বরূপ, আপনি জানেন যে negativeণাত্মক inits ভুল উত্তর নয় তবে আপনি কি জানেন যে ইতিবাচক int সঠিক কিনা? পদ্ধতিটি কাজ করছে তা প্রমাণ করার জন্য আপনার সত্যিকার অর্থে কতগুলি পরীক্ষা দরকার? একমাত্র সঠিক কোর্সটি অনুমান করা যে পদ্ধতিটি সঠিক is

— ভিন্স ও'সুলিভান

Answer 5

আমি তর্ক করব যে আপনার প্রশ্নের ভিত্তি বন্ধ আছে: কেন শুরু করার জন্য একটি নাল রেফারেন্স ব্যবহার করবেন?

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

এই ব্যবহারকারীটি নিষ্ক্রিয় হবে, একটি ফাঁকা নাম থাকবে এবং অন্যান্য নন-মানগুলি "এখানে কিছুই নেই" নির্দেশ করে। প্রাথমিক উপকারটি হ'ল আপনার প্রোগ্রামে ক্রেটার দরকার নেই আপনার চেক, লগিং ইত্যাদি নষ্ট করে দেবে আপনি কেবল নিজের অবজেক্ট ব্যবহার করেন।

কেন একটি অ্যালগরিদম নাল মান সম্পর্কে যত্ন করা উচিত? পদক্ষেপগুলি একই হওয়া উচিত। নাল বস্তুটি শূন্য, ফাঁকা স্ট্রিং ইত্যাদি প্রদান করে এমনটি সহজেই সহজ এবং সুস্পষ্ট cle

এখানে নাল জন্য কোড চেকিংয়ের একটি উদাহরণ:

User u = getUser();
String displayName = "";
if (u != null) {
  displayName = u.getName();
}
return displayName;

নাল অবজেক্ট ব্যবহার করে এখানে কোডের একটি উদাহরণ দেওয়া হয়েছে:

return getUser().getName();

কোনটি পরিষ্কার? আমি বিশ্বাস করি দ্বিতীয়টি।

---

প্রশ্নটি জাভা ট্যাগ করা অবস্থায় , এটি উল্লেখ করার মতো যে রেফারেন্সগুলি ব্যবহার করার সময় নাল অবজেক্ট প্যাটার্নটি সি ++ তে সত্যই কার্যকর। জাভা রেফারেন্সগুলি আরও সি ​​++ পয়েন্টারগুলির মতো এবং নালার অনুমতি দেয়। সি ++ রেফারেন্সগুলি ধরে রাখতে পারে না nullptr। যদি কারও কাছে সি ++ এ নাল রেফারেন্সের সাথে সামঞ্জস্যপূর্ণ কিছু থাকতে চান তবে নাল অবজেক্ট প্যাটার্নটি আমি এটি সম্পাদন করার একমাত্র উপায়।

Comments

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

— দিদিয়ার এ।

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

আমার কল্পনা করুন: int i = getCount; ভাসা x = 100 / i; যদি আমি জানি যে গেটকাউন্ট 0 ফেরত দেয় না, কারণ আমি হয় পদ্ধতিটি লিখেছি বা এটি পরিদর্শন করেছি, আমি কি 0 এর জন্য চেকটি এড়ানো উচিত?

— দিদিয়ার এ।

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

— স্টিভ জেসোপ

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

— sdenham

Answer 6

সাধারণত, আমি বলব যা মূলত নিম্নলিখিত তিনটি দিকের উপর নির্ভর করে:

1. দৃust়তা: কলিং পদ্ধতিটি nullমানটি সহ্য করতে পারে? যদি nullমানটির ফলাফল হিসাবে RuntimeExceptionআমি একটি চেকের প্রস্তাব দিতে পারি - যদি জটিলতা কম না হয় এবং কল / কলিং পদ্ধতিগুলি একই লেখক তৈরি না করে এবং nullপ্রত্যাশিত না হয় (যেমন উভয় privateএকই প্যাকেজটিতে)।

2. কোডের দায়বদ্ধতা: যদি বিকাশকারী এ getUser()পদ্ধতির জন্য দায়বদ্ধ হন এবং বিকাশকারী বি এটি ব্যবহার করে (যেমন একটি লাইব্রেরির অংশ হিসাবে) তবে আমি দৃ strongly়তার সাথে এর মানটি বৈধ করার জন্য সুপারিশ করব। কেবলমাত্র বিকাশকারী বি এমন কোনও পরিবর্তন সম্পর্কে জানেন না যার ফলস্বরূপ সম্ভাব্য nullপ্রত্যাবর্তনের মান হয়।

3. জটিলতা: প্রোগ্রাম বা পরিবেশের সামগ্রিক জটিলতা তত বেশি, আমি রিটার্নের মানটি বৈধ করার জন্য সুপারিশ করব। nullকলিং পদ্ধতির প্রেক্ষাপটে এটি আজ নাও হতে পারে এমন বিষয়ে আপনি যদি নিশ্চিত হন তবে এটি getUser()অন্য কোনও ব্যবহারের ক্ষেত্রে আপনাকে পরিবর্তন করতে হবে । কয়েক মাস বা বছর কেটে গেলে এবং কয়েক হাজার লাইন কোড যুক্ত করা হয়েছে, এটি বেশ ফাঁদ পেতে পারে।

nullতদতিরিক্ত , আমি একটি জাভাডক মন্তব্যে সম্ভাব্য রিটার্ন মানগুলি দলিল করার পরামর্শ দেব recommend সর্বাধিক আইডিইগুলিতে জাভাডক বর্ণনাকে হাইলাইট করার কারণে, এটি যে কেউ ব্যবহার করে তাদের পক্ষে এটি একটি সহায়ক সতর্কতা হতে পারে getUser()।

/** Returns ....
  * @param: id id of the user
  * @return: a User instance related to the id;
  *          null, if no user with identifier id exists
 **/
User getUser(Int id)
{
    ...
}

Answer 7

আপনি অবশ্যই করবেন না।

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

Comments

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

— দিদিয়ের এ।