একক হিসাবে স্ট্যাটিক কারখানা বনাম কারখানা

আমার কিছু কোডে, আমার কাছে এটির মতো একটি স্ট্যাটিক কারখানা রয়েছে:

public class SomeFactory {

    // Static class
    private SomeFactory() {...}

    public static Foo createFoo() {...}

    public static Foo createFooerFoo() {...}
}

কোড পর্যালোচনা চলাকালীন প্রস্তাব দেওয়া হয়েছিল যে এটি সিঙ্গলটন এবং ইনজেকশন হওয়া উচিত। সুতরাং, এটি দেখতে এইরকম হওয়া উচিত:

public class SomeFactory {

    public SomeFactory() {}

    public Foo createFoo() {...}

    public Foo createFooerFoo() {...}
}

হাইলাইট করার জন্য কয়েকটি বিষয়:

দুটি কারখানাই রাষ্ট্রহীন।
পদ্ধতির মধ্যে একমাত্র পার্থক্য হ'ল তাদের স্কোপগুলি (উদাহরণস্বরূপ স্থিতিশীল)। বাস্তবায়নও একই রকম।
ফু একটি মটরশুটি যা একটি ইন্টারফেস নেই।

স্থির হওয়ার জন্য আমার যে যুক্তি ছিল তা হ'ল:

বর্গটি রাষ্ট্রহীন, সুতরাং তাত্ক্ষণিক হওয়ার দরকার নেই
কারখানাটি ইনস্ট্যান্ট করার চেয়ে স্থিতিশীল পদ্ধতিটি কল করতে সক্ষম হওয়া আরও স্বাভাবিক বলে মনে হয়

সিঙ্গেলটন হিসাবে কারখানার পক্ষে যুক্তিগুলি ছিল:

সব কিছু ইনজেক্ট করা ভাল
কারখানার রাজ্যহীনতা সত্ত্বেও, ইঞ্জেকশন দিয়ে টেস্টিং করা সহজ (উপহাস করা সহজ)
ভোক্তার পরীক্ষা করার সময় এটি উপহাস করা উচিত

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

সম্প্রদায় কী মনে করে? যদিও আমি সিঙ্গলটনের পদ্ধতির পছন্দ করি না, যদিও এর বিরুদ্ধে আমার ভীষণ দৃ strong় যুক্তি রয়েছে বলে মনে হয় না।

— bstempi
সূত্র

কারখানাটি কোনও কিছু দ্বারা ব্যবহৃত হচ্ছে । এই জিনিসটি বিচ্ছিন্নভাবে পরীক্ষা করতে আপনার এটি আপনার কারখানার একটি বিদ্রূপ সরবরাহ করতে হবে। আপনি যদি নিজের কারখানাকে উপহাস না করেন তবে সেখানে কোনও বাগ একটি ব্যর্থ ইউনিট পরীক্ষার কারণ হতে পারে যখন তা না করা উচিত।

— মাইক

সুতরাং, আপনি সাধারণভাবে স্থিতিশীল ইউটিলিটিগুলির বিরুদ্ধে, বা কেবল স্থিতিশীল কারখানার বিরুদ্ধে পরামর্শ করছেন?

— বুস্তেম্পি

আমি সাধারণভাবে তাদের বিরুদ্ধে আইনজীবী করছি। সি # তে উদাহরণস্বরূপ DateTimeএবং Fileক্লাসগুলি ঠিক একই কারণে পরীক্ষা করা বেশ কুখ্যাত। যদি আপনার কাছে উদাহরণস্বরূপ কোনও শ্রেণি থাকে যা নির্ধারকটিতে Createdতারিখ নির্ধারণ করে DateTime.Nowআপনি 5 মিনিটের ব্যবধানে তৈরি হওয়া এই দুটি বস্তুর সাথে ইউনিট পরীক্ষা তৈরির বিষয়ে কীভাবে যান? বছরের পর বছর কী? আপনি সত্যিই এটি করতে পারবেন না (প্রচুর কাজ ছাড়াই)।

— মাইক

আপনার সিঙ্গলটন কারখানায় privateকনস্ট্রাক্টর এবং একটি getInstance()পদ্ধতি থাকা উচিত নয়? দুঃখিত, অযোগ্য-নিট-পিকার!

— টিএমএন

@ মাইক - স্বীকৃত - আমি প্রায়শই একটি ডেটটাইমপ্রাইভেটর ক্লাস ব্যবহার করেছি যা তুচ্ছভাবে ডেটটাইম.নিউ দেয়। তারপরে আপনি এটিকে একটি মক যা আপনার পরীক্ষাগুলিতে একটি পূর্ব নির্ধারিত সময় ফেরত দেয় তার জন্য অদলবদল করতে পারেন। এটি সমস্ত নির্মাণকারীর কাছে অতিরিক্ত কাজ করা - সবচেয়ে বড় মাথা ব্যথা হয় যখন সহকর্মীরা এটি 100% না কিনে এবং অলসতার বাইরে ডেটটাইম-এ স্পষ্ট উল্লেখগুলি পিছলে যায় ... :)

— জুলিয়া হ্যাওয়ার্ড

উত্তর:

আপনি কেন আপনার কারখানার তৈরি করা অবজেক্ট-টাইপ থেকে আলাদা করবেন?

public class Foo {

    // Private constructor
    private Foo(...) {...}

    public static Foo of(...) { return new Foo(...); }
}

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

জোশুয়া ব্লচের আইটেম 1 প্যারাফ্রেস করতে, নির্মাণকারীদের মতো নয়, স্থির কারখানার পদ্ধতিগুলি:

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

অসুবিধা:

পাবলিক বা সুরক্ষিত কনস্ট্রাক্টর ছাড়াই ক্লাসগুলি সাবক্ল্যাস করা যাবে না (তবে আপনি সুরক্ষিত কনস্ট্রাক্টর এবং / অথবা আইটেম 16 ব্যবহার করতে পারেন: উত্তরাধিকারের চেয়ে কমপোজিশনের পক্ষে)
স্ট্যাটিক কারখানার পদ্ধতিগুলি অন্যান্য স্থিতিশীল পদ্ধতিগুলি থেকে আলাদা হয় না (যেমন একটি মানক (যেমন) বা মান ওফ () ব্যবহার করে)

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

— GlenPeterson
সূত্র

আমি এটি সম্পর্কেও ভেবে দেখেছি এবং আমি মনে করি এটি আমার পছন্দ হয়েছে। আমি কেন তাদের প্রথম স্থানে আলাদা করেছিলাম তা মনে নেই।

— বুস্টেম্পি

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

— বুস্টেম্পি

তবে ... এটা ভয়াবহ। আপনি সম্ভবত একটি ক্লাস চান যা IFoo প্রয়োগ করে এবং এটি পাস করেছে this এই প্যাটার্নটি ব্যবহার করে, এটি আর সম্ভব নয়; দৃষ্টান্তগুলি পেতে আপনাকে Foo বলতে হার্ডকোড করতে হবে। আপনার যদি আইফুফ্যাক্টরি থাকে যাতে একটি আইএফও তৈরি () থাকে, ক্লায়েন্ট কোডে কোন কংক্রিট ফুকে আইএফও হিসাবে বেছে নেওয়া হয়েছিল তার বাস্তবায়ন বিশদটি জানতে হবে না।

— উইলবার্ট

@ উইলবার্ট public static IFoo of(...) { return new Foo(...); } কী সমস্যা? ব্লচ এই নকশার অন্যতম সুবিধা (উপরে দ্বিতীয় বুলেট পয়েন্ট) হিসাবে আপনার উদ্বেগকে সন্তুষ্ট করে তালিকাবদ্ধ করে। আমি আপনার মন্তব্য বুঝতে হবে না।

— গ্লেনপিটারসন

একটি উদাহরণ তৈরি করতে, এই নকশাটি আশা করে: Foo.of (...)। তবে ফু এর অস্তিত্ব কখনই প্রকাশ করা উচিত নয়, কেবল আইএফইউকেই জানা উচিত (যেমন ফু কেবল আইএফওর একটি কংক্রিট ইমপ্ল) l কংক্রিট ইমপ্লের উপর একটি স্থিতিশীল কারখানার পদ্ধতি হ'ল এটি ভেঙে যায় এবং ক্লায়েন্ট কোড এবং কংক্রিটের প্রয়োগের মধ্যে সংযোগ ঘটায়।

— উইলবার্ট

আমার মাথার ঠিক উপরে, জাভাতে স্ট্যাটিক্স নিয়ে কিছু সমস্যা রয়েছে:

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

তুমি উল্লেখ করেছিলে:

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

যা আপনাকে জিজ্ঞাসা করতে আগ্রহী করে তোলে:

আপনার মতে, স্থির পদ্ধতিগুলির সুবিধা কী?
আপনি কি বিশ্বাস করেন যে StringUtilsএটি সঠিকভাবে ডিজাইন এবং বাস্তবায়িত হয়েছে?
কেন আপনি মনে করেন কারখানাটি কখনই আপনাকে উপহাস করার দরকার নেই?

আরে, উত্তরের জন্য ধন্যবাদ! আপনি যে ক্রমে জিজ্ঞাসা করেছেন: (1) স্থির পদ্ধতিগুলির সুবিধাগুলি সিনট্যাকটিক চিনি এবং একটি অপ্রয়োজনীয় উদাহরণের অভাব। স্থিতিশীল আমদানি রয়েছে এমন কোডটি পড়তে এবং Foo f = createFoo();নাম দেওয়া উদাহরণ না দিয়ে কিছু বলা ভাল । উদাহরণটি নিজেই কোনও ইউটিলিটি সরবরাহ করে না। (2) আমি তাই মনে করি। Stringক্লাসের মধ্যে methods পদ্ধতিগুলির মধ্যে অনেকগুলি বিদ্যমান না এই সত্যটি কাটিয়ে ওঠার জন্য এটি তৈরি করা হয়েছিল । Stringকোনও মৌলিক হিসাবে প্রতিস্থাপন করা কোনও বিকল্প নয়, সুতরাং ব্যবহারগুলি হ'ল উপায়। (

— cont'd

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

— বুস্টেম্পি

তারা উপহাস করে না StringUtilsকারণ একটি যুক্তিসঙ্গত নিশ্চয়তা রয়েছে যে সেখানকার পদ্ধতিগুলিতে কোনও পার্শ্ব-প্রতিক্রিয়া নেই।

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

@ রবার্ট হার্ভে আমি মনে করি আমি আমার কারখানা সম্পর্কে একই দাবি করছি - এটি কোনও পরিবর্তন করে না। StringUtilsইনপুটগুলি পরিবর্তন না করে যেমন কিছু ফলাফল ফেরত দেয়, তেমনই আমার কারখানাটিও কিছুই পরিবর্তন করে না।

— বুস্টেম্পি

@bstempi আমি সেখানে কিছুটা সাকরাটিক পদ্ধতিতে যাচ্ছিলাম। আমার ধারণা আমি এটাকে চুষছি।

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

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

এখন ভাবুন আপনি যদি এমন একটি তৈরি করে থাকেন IFooFactoryযা একটি তৈরি করে IFoo। এখন, একটি পৃথক সাবক্লাস উত্পাদন করা বা সম্পূর্ণ আলাদা বাস্তবায়ন হ'ল সন্তানের খেলা - আপনি কেবল সঠিক আইফুফ্যাক্টরিতে উচ্চ চেইনটি খাওয়ান এবং তারপরে যখন ক্লায়েন্টটি এটি পেয়ে যায়, তখন এটি কল করে ডান ফুও gimmeAFoo()পাবেন কারণ এটি সঠিক কারখানা পেয়েছে got ।

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

প্রশ্নগুলি নির্দেশ বা অনুশীলনে উভয় উপস্থাপন করা যেতে পারে (যা উভয়ই প্রয়োগ করে IContentBlock), সুতরাং প্রতিটি InstructionsFactoryবা ExerciseFactoryপ্রশ্নকেন্দ্রম্যাপের একটি অনুলিপি পাবেন। তারপরে, বিভিন্ন নির্দেশাবলী এবং অনুশীলন কারখানাগুলি হস্তান্তর করা হয় ContentBlockBuilderযা আবার কখন কোন হ্যাশ ব্যবহার করে তা বজায় রাখে। এবং তারপরে যখন এক্সএমএল লোড করা হয় তখন কন্টেন্টব্লকবিল্ডার হ্যাশ থেকে অনুশীলন বা নির্দেশাবলী কারখানাকে ডেকে জিজ্ঞাসা করে createContent()এবং তারপরে কারখানাটি তার অভ্যন্তরীণ প্রশ্ন-ফ্যাক্টরিপ্যাপটি কীসের ভিত্তিতে টেনে নিয়ে যায় প্রশ্নগুলির বিল্ডিংকে প্রতিনিধিত্ব করে what প্রতিটি এক্সএমএল নোডে বনাম হ্যাশটিতে রয়েছে। দুর্ভাগ্যক্রমে , জিনিসটি একটি BaseQuestionপরিবর্তে একটিIQuestion, তবে এটি কেবল এটি দেখায় যে আপনি ডিজাইনের বিষয়ে সতর্ক থাকাকালীনও আপনি এমন ভুল করতে পারেন যা আপনাকে লাইন থেকে ফেলে দিতে পারে।

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

— অ্যামি ব্ল্যানকেনশীপ
সূত্র

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

— বুস্টেম্পি

এছাড়াও, অ্যাপ্লিকেশন সম্পর্কে আপনার অনুমানগুলি বন্ধ রয়েছে। আবেদন মোটামুটি জড়িত। এটি Fooঅবশ্য ক্লাসের অনেকের চেয়ে অনেক সহজ। এটি কেবল একটি সাধারণ পোজো।

— বুস্টেম্পি

যদি ফু বলতে বোঝানো হয় তবে কারখানার একটি উদাহরণ হওয়ার সঠিক কারণ রয়েছে - আপনি if (this) then {makeThisFoo()} else {makeThatFoo()}আপনার কোডের মাধ্যমে সমস্ত কল করার চেয়ে সঠিক সাবক্লাস দেওয়ার জন্য কারখানার সঠিক উদাহরণ সরবরাহ করেন । কালীনভাবে খারাপ স্থাপত্যের লোকদের সম্পর্কে একটি জিনিস আমি লক্ষ্য করেছি যে তারা দীর্ঘস্থায়ী ব্যথার মতো লোক। তারা আসলে জানে না যে বেদনা না হওয়ার মতো এটি কী অনুভব করে, তাই তারা যে ব্যথা করছে তা এত খারাপ বলে মনে হচ্ছে না।

— অ্যামি ব্লাকনশিপ

এছাড়াও, আপনি স্থির পদ্ধতিগুলির (এমনকি ম্যাথগুলিও!) সমস্যাগুলি সম্পর্কে এই লিঙ্কটি পরীক্ষা করে দেখতে চান

— এমি ব্লাকনশিপ

আমি প্রশ্ন আপডেট করেছি। আপনি এবং অন্য এক ব্যক্তি প্রসারিত উল্লেখ করেছেন Foo। ঠিক তাই - আমি কখনই এটি চূড়ান্ত ঘোষণা করিনি। Fooএমন একটি শিম যা বাড়ানো নয় to

— বুস্টেম্পি