সি # তে কনস্ট্রাক্টর প্যারামিটারের বৈধতা - সেরা অনুশীলন


34

কনস্ট্রাক্টর প্যারামিটার বৈধতার জন্য সর্বোত্তম অনুশীলন কী?

ধরুন একটি সাধারণ বিট সি #:

public class MyClass
{
    public MyClass(string text)
    {
        if (String.IsNullOrEmpty(text))
            throw new ArgumentException("Text cannot be empty");

        // continue with normal construction
    }
}

এটি একটি ব্যতিক্রম নিক্ষেপ গ্রহণযোগ্য হবে?

বিকল্পটির সাথে আমার মুখোমুখি হওয়ার আগে প্রাক-বৈধতা ছিল:

public class CallingClass
{
    public MyClass MakeMyClass(string text)
    {
        if (String.IsNullOrEmpty(text))
        {
            MessageBox.Show("Text cannot be empty");
            return null;
        }
        else
        {
            return new MyClass(text);
        }
    }
}

10
"একটি ব্যতিক্রম নিক্ষেপ গ্রহণযোগ্য?" বিকল্প কি?
এস .লট

10
@ এসলট: কিছুই করবেন না। একটি ডিফল্ট মান সেট করুন। কনসোল / লগফাইলে একটি বার্তা প্রিন্ট করুন। ঘণ্টা বাজান. একটি আলোক ঝলকান।
হতাশ

3
@ ফ্রাস্ট্রেটেড উইথফর্মস ডিজাইনার: "কিছুই করবেন না?" কীভাবে "পাঠ্য খালি নয়" সীমাবদ্ধ হবে? "একটি ডিফল্ট মান সেট করুন"? কিভাবে পাঠ্য আর্গুমেন্ট মান ব্যবহার করা হবে? অন্যান্য ধারণাগুলি ঠিক আছে, তবে এই দু'টি এই শ্রেণীর সীমাবদ্ধতা লঙ্ঘন করে এমন একটি রাজ্যে এমন কোনও জিনিসের দিকে পরিচালিত করবে।
এস .লট

1
@ এসলট নিজেকে পুনরাবৃত্তি করার ভয়ে আমি অন্য কোনও পদ্ধতির সম্ভাবনা প্রকাশ করতে পেরেছিলাম, যা আমি জানতাম না। আমি বিশ্বাস করি যে আমি সকলেই জানি না, এটাই আমি নিশ্চিতভাবে জানি।
এমপিলেটিয়ার

3
@ মেলপ্লেয়ার, সময়ের আগে প্যারামিটারগুলি বৈধকরণের মাধ্যমে ডিআরওয়াই লঙ্ঘন করা শেষ হবে। (নিজেকে পুনরাবৃত্তি করবেন না) যেহেতু আপনাকে এই শ্রেণিটি ইনস্ট্যান্ট করার চেষ্টা করে এমন কোনও কোডে সেই প্রাক-বৈধতা অনুলিপি করতে হবে।
ক্যাফগেক

উত্তর:


26

আমি কনস্ট্রাক্টরে আমার বৈধতা সমস্ত সম্পাদন করার ঝোঁক। এটি একটি আবশ্যক কারণ আমি প্রায় সবসময় অপরিবর্তনীয় বস্তু তৈরি করি। আপনার নির্দিষ্ট ক্ষেত্রে আমি মনে করি এটি গ্রহণযোগ্য।

if (string.IsNullOrEmpty(text))
    throw new ArgumentException("message", "text");

আপনি যদি নেট 4 ব্যবহার করেন তবে আপনি এটি করতে পারেন। অবশ্যই এটি নির্ভর করে যে আপনি এমন একটি স্ট্রিংকে অবৈধ বলে বিবেচনা করছেন যাতে কেবলমাত্র সাদা স্থান রয়েছে।

if (string.IsNullOrWhiteSpace(text))
    throw new ArgumentException("message", "text");

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

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

2
আমি প্রথম কেসটিকে দুটি পৃথক ব্যতিক্রমের মধ্যে বিভক্ত করার ঝোঁক রাখি: একটি যা নালার জন্য পরীক্ষা করে এবং একটি নিক্ষেপ করে ArgumentNullExceptionএবং অন্যটি যা খালি পরীক্ষা করে এবং একটি নিক্ষেপ করে ArgumentException। কলকারী যদি এর ব্যতিক্রম হ্যান্ডলিং করতে চান তবে আরও পিক হওয়ার অনুমতি দিন।
জেসি সি স্লিকার

1
@ জেসি - আমি সেই কৌশলটি ব্যবহার করেছি তবে এখনও এর সামগ্রিক উপযোগিতা সম্পর্কে বেড়াতে রয়েছি।
কেওসপ্যান্ডিয়ন

3
অপরিবর্তনীয় বস্তুর জন্য +1! আমি যেখানেই সম্ভব এগুলি ব্যবহার করি (আমি ব্যক্তিগতভাবে প্রায় সবসময় খুঁজে পাই)।

22

প্রচুর লোকেরা বলে যে নির্মাতাদের ব্যতিক্রম ছোঁড়া উচিত নয়। এই পৃষ্ঠায় কাইলজি উদাহরণস্বরূপ, এটি করে। সত্য, আমি কেন কারণ না তা ভাবতে পারি না।

সি ++ এ, কনস্ট্রাক্টরের কাছ থেকে ব্যতিক্রম ছুঁড়ে ফেলা একটি খারাপ ধারণা, কারণ এটি আপনাকে বরাদ্দ মেমরির সাথে অবিচ্ছিন্ন অবজেক্টের সাথে ছেড়ে দেয় যা আপনার কোনও রেফারেন্স নেই (অর্থাত্ এটি ক্লাসিক মেমরি ফুটো)। সম্ভবত এটি থেকেই কলঙ্কটি এসেছে - একগুচ্ছ পুরাতন স্কুলের সি ++ বিকাশকারীরা তাদের সি # শেখার অর্ধেক আর্স করেছে এবং কেবল তারা সি ++ থেকে যা জানত তা প্রয়োগ করেছে। বিপরীতে, অবজেক্টিভ-সি অ্যাপল বন্টন পদক্ষেপটি আরম্ভের পদক্ষেপ থেকে আলাদা করেছে, সুতরাং সেই ভাষায় নির্মাতারা ব্যতিক্রম ছুঁড়ে ফেলতে পারে

সি # কোনও কনস্ট্রাক্টরের কাছে ব্যর্থ কল থেকে মেমরি ফাঁস করতে পারে না। এমনকি .NET কাঠামোর কিছু শ্রেণি তাদের নির্মাতাদের ব্যতিক্রম ছুঁড়ে ফেলবে।


আপনি তাই আপনার সাথে C ++ মন্তব্য নিয়ে কিছু পালক নিয়ে উঠবেন। :)
কেওসপ্যান্ডিয়ন

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

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

6
অঁ্যা? সিটি থেকে ব্যতিক্রম ছুঁড়ে ফেলা কেবলমাত্র আপনি সি ++ এ করতে পারেন যদি আপনি অবজেক্টটি নির্মাণ করতে না পারেন, এবং এর কোনও কারণ নেই যার ফলে এটি একটি মেমরি ফাঁস হওয়ার কারণ রয়েছে (যদিও এটি অবশ্যই আপাতত আপ)।
জে কে।

@ জে কে: হুম, ঠিক বলেছেন! যদিও এটির বিকল্পটি খারাপ জিনিসগুলিকে "জম্বি" হিসাবে পতাকাঙ্কিত করা, যা এসটিএল স্পষ্টতই ব্যতিক্রম ছুঁড়ে ফেলার পরিবর্তে করে: yosefk.com/c++fqa/exferences.html#fqa-17.2 উদ্দেশ্য-সি এর সমাধানটি অনেক পরিপাটি।
পিঁপড়া

12

একটি ব্যতিক্রম আইএফএফ নিক্ষেপ করুন ক্লাসটিকে এর শব্দার্থক ব্যবহারের ক্ষেত্রে সামঞ্জস্যপূর্ণ অবস্থায় স্থাপন করা যাবে না। অন্যথায় না। অসামঞ্জস্য অবস্থায় কোনও বস্তুর অস্তিত্ব থাকতে দেয় না। এর মধ্যে সম্পূর্ণ কন্সট্রাক্টর সরবরাহ না করা (যেমন আপনার অবজেক্টটি সম্পূর্ণরূপে নির্মিত হওয়ার আগে একটি খালি কনস্ট্রাক্টর + ইনিশিয়াল () করা) ... ঠিক নেই বলুন!

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

আমার নোট করা উচিত "কন্সট্রাক্টর" দ্বারা ক্লায়েন্টটি যে জিনিসটি তৈরি করতে ডাকে তার অর্থ। এটি ঠিক সহজেই একটি সত্যিকারের নির্মাণ ছাড়া অন্য কিছু হতে পারে যা "কনস্ট্রাক্টর" নামে চলে। উদাহরণস্বরূপ, সি ++ তে এর মতো কিছু আইএমএনএসএইও নীতি লঙ্ঘন করবে না:

struct funky_object
{
  ...
private:
  funky_object();
  bool initialize(std::string);

  friend boost::optional<funky_object> build_funky(std::string);
};
boost::optional<funky_object> build_funky(std::string str)
{
  funky_object fo;
  if (fo.initialize(str)) return fo;
  return boost::optional<funky_object>();
}

যেহেতু প্রকৃত "নির্মাণকারী" কাজ শেষ না করে সত্ত্বেও কোনও অবৈধ বস্তুর অস্তিত্ব না রাখার নীতিটি funky_objectকল build_funkyকরে একটি তৈরি করার একমাত্র উপায় ।

সন্দেহজনক লাভের জন্য যদিও এটি অনেক অতিরিক্ত কাজ (এমনকি ক্ষতিও)। আমি এখনও ব্যতিক্রম পথ পছন্দ করি।


9

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

public class MyClass
{
    private MyClass(string text)
    {
        //normal construction
    }

    public static MyClass MakeMyClass(string text)
    {
        if (String.IsNullOrEmpty(text))
            return null;
        else
            return new MyClass(text);
    }
}
public class CallingClass
{
    public MyClass MakeMyClass(string text)
    {
        var cls = MyClass.MakeMyClass(text);
        if(cls == null)
             //show messagebox or throw exception
        return cls;
    }
}

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


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

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

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

কেউ এই নির্দেশিকাগুলি যুক্তিসঙ্গতভাবে প্রশ্ন করতে পারে এবং বলতে পারে, "তবে আমি এই বিধিগুলি অনুসরণ করি না, এবং আমার কোডটি কার্যকর হয়!" সেদিকে আমি জবাব দেব, "এটি ঠিক না হওয়া অবধি সত্য হতে পারে" "

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

0

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

সুতরাং এটি নির্ভর করে যে প্যারামিটারের পাঠ্যটি পদ্ধতিতে কীভাবে প্রয়োজনীয় - এটি কী শূন্য বা ফাঁকা মান দিয়ে বস্তুটি বোঝায়?


2
আমি মনে করি যে প্রশ্নটি বোঝায় যে ক্লাসটি আসলে স্ট্রিংটি খালি না হওয়া দরকার। আপনার স্ট্রিংবিল্ডারের উদাহরণে এটি নয়।
সার্জিও আকোস্টা

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

0

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


-1

আমি যখন সি ++ এ কাজ করতাম, তখন আমি মেমরি ফাঁস হওয়ার কারণে কন্সট্রাক্টর ব্যতিক্রম করতে পারি না কারণ এটি শক্তভাবে শিখেছি। সি ++ এর সাথে কাজ করা যে কেউ জানেন যে মেমরি ফাঁস কতটা কঠিন এবং সমস্যাযুক্ত হতে পারে।

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

public class MyClass
{
    private string _text;
    public string Text 
    {
        get
        {
            return _text;
        } 
        set
        {
            if (string.IsNullOrWhiteSpace(value))
                throw new ArgumentException("Text cannot be empty");
            _text = value;
        } 
    }

    public MyClass(string text)
    {
        Text = text;
        // continue with normal construction
    }
}

-3

ব্যতিক্রম নিক্ষেপ করা আপনার শ্রেণীর ব্যবহারকারীদের জন্য আসল ব্যথা হবে। যদি বৈধতা কোনও সমস্যা হয় তবে আমি সাধারণত 2 টি পদক্ষেপ প্রক্রিয়াটি অবজেক্ট তৈরি করি।

1 - উদাহরণটি তৈরি করুন

2 - একটি রিটার্ন ফলাফল সহ একটি ইনিশিয়াল পদ্ধতি কল করুন।

অথবা

এমন একটি পদ্ধতি / ফাংশন কল করুন যা আপনার জন্য শ্রেণি তৈরি করে যা যাচাইকরণ করতে পারে।

অথবা

একটি ইস্পালিড পতাকা রাখুন, যা আমি বিশেষত পছন্দ করি না তবে কিছু লোক এটি করেন।


3
@ ডাঙ্ক, এটা ঠিক ভুল
ক্যাফগিকে

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

5
পয়েন্টটি হ'ল আমি কোনও কনস্ট্রাক্টরকে কল করার পরে যদি এটি তৈরি না করে কারণ কোনও ইনপুট অবৈধ হয়, তবে এটি একটি ছাড় P আমি যদি সহজভাবে অবজেক্টটি তৈরি করি এবং একটি পতাকা বলি সেট করি তবে অ্যাপটির ডেটা এখন বেমানান / অবৈধ অবস্থায় রয়েছে isValid = false। কোনও শ্রেণি তৈরি হওয়ার পরে পরীক্ষা করা যদি এটি বৈধ হয় তবে তা ভয়াবহ, খুব ত্রুটির প্রবণ নকশা। এবং, আপনি বলেছিলেন, একজন কনস্ট্রাক্টর আছে, তারপরে কল আরম্ভ করুন ... আমি যদি আরম্ভ না করি? তখন কি? আর কি যদি ইনিশিয়েল করা খারাপ ডেটা পায় তবে আমি কি এখনই একটি ব্যতিক্রম ছুঁড়ে ফেলতে পারি? আপনার ক্লাসটি ব্যবহার করা কঠিন হবে না।
ক্যাফগিকে

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

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