স্ট্যাটিক তৈরি পদ্ধতি - কনস্ট্রাক্টরের সাথে তুলনা করে ভাল ও কনস

Question

কনস্ট্রাক্টরদের উপর স্থির অবজেক্ট তৈরির পদ্ধতি থাকার পক্ষে কি কি?

class Foo {
  private Foo(object arg) { }

  public static Foo Create(object arg) {
    if (!ValidateParam(arg)) { return null; }
    return new Foo(arg);
  }
}

আমি ভাবতে পারি যে খুব কম:

পেশাদাররা:

• ব্যতিক্রম নিক্ষেপের পরিবর্তে নাল ফেরান (নাম দিন TryCreate)। এটি ক্লায়েন্টের পক্ষে কোডটিকে আরও পরিস্কার করে এবং পরিষ্কার করতে পারে। ক্লায়েন্টরা খুব কমই কোনও নির্মাণকারীকে ব্যর্থ হওয়ার আশা করে।
• পরিষ্কার শব্দার্থক, যেমন CreatFromName(String name)এবং সহ বিভিন্ন ধরণের অবজেক্ট তৈরি করুনCreateFromCsvLine(String csvLine)
• প্রয়োজনে কোনও ক্যাশেড অবজেক্ট, বা প্রাপ্ত কোনও বাস্তবায়ন ফিরে আসতে পারে।

কনস:

• কম আবিষ্কারযোগ্য, স্কিম কোড করা আরও কঠিন।
• সিরিয়ালাইজেশন বা প্রতিবিম্বের মতো কিছু নিদর্শন আরও কঠিন (উদাঃ Activator<Foo>.CreateInstance())

Comments

এটা ধীর। আপনাকে যাইহোক নাল রেফারেন্স পরিচালনা করতে হবে।

— আমির রেজায়ে

@ আমির হ্যান্ডলিং নাল হল ( Foo x = Foo.TryCreate(); if (x == null) { ... })। একটি ctor ব্যতিক্রম হ্যান্ডেল করা হয় ( Foo x; try { x = new Foo(); } catch (SomeException e) { ... })। একটি সাধারণ পদ্ধতি কল করার সময়, আমি ত্রুটি কোডগুলিতে ব্যতিক্রম পছন্দ করি তবে অবজেক্ট তৈরির সাথে আরও TryCreateপরিষ্কার মনে হয়।

— dbkk

আপনি কি আপনার বৈধতাতে কোনও ধরণের চেকিং করবেন?

— আমির রেজায়ে

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

— bentayloruk

Answer 1

স্থির ' স্রষ্টাদের ' সাথে সবচেয়ে বড় অসুবিধা সম্ভবত উত্তরাধিকারকে সীমাবদ্ধ করে দিচ্ছে। আপনি বা আপনার লাইব্রেরির ব্যবহারকারী যদি আপনার কাছ থেকে কোনও ক্লাস পান Fooতবে তা Foo::Create()অনেকটা অকেজো হয়ে যায়। সেখানে সংজ্ঞায়িত সমস্ত যুক্তি উত্তরাধিকারসূত্রে আবার লিখতে হবে Create()।

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

Comments

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

— ডোভাল

Answer 2

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