পদ্ধতিতে অনেক আর্গুমেন্ট পাস করার জন্য সেরা অনুশীলন?

Question

মাঝে মধ্যে, আমাদের এমন পদ্ধতিগুলি লিখতে হয় যা অনেকগুলি আর্গুমেন্ট গ্রহণ করে, উদাহরণস্বরূপ:

public void doSomething(Object objA , Object objectB ,Date date1 ,Date date2 ,String str1 ,String str2 )
{
}

আমি যখন এই ধরণের সমস্যার মুখোমুখি হই তখন আমি প্রায়শই একটি মানচিত্রে যুক্তিগুলি ঝাপিয়ে পড়ে।

Map<Object,Object> params = new HashMap<Object,Object>();
params.put("objA",ObjA) ;

......

public void doSomething(Map<Object,Object> params)
{
 // extracting params 
 Object objA = (Object)params.get("objA");
 ......
 }

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

Answer 1

ইন কার্যকরী জাভা , অধ্যায় 7 (পদ্ধতি), আইটেম 40 (নকশা পদ্ধতি স্বাক্ষর সাবধানে), ব্লচ লিখেছেন:

অতিরিক্ত দীর্ঘ প্যারামিটার তালিকা সংক্ষিপ্ত করার জন্য তিনটি কৌশল রয়েছে:

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

আরও তথ্যের জন্য, আমি আপনাকে বইটি কিনতে উত্সাহিত করি, এটি সত্যিই মূল্যবান।

Comments

"অতিরিক্ত দীর্ঘ পরামিতি" কী? আমরা কখন বলতে পারি যে কোনও পদ্ধতিতে অনেকগুলি পরামিতি রয়েছে? একটি নির্দিষ্ট নম্বর বা একটি পরিসীমা আছে?

— রেড এম

আমি সবসময় বেশি 3 বা 4 পরামিতি "মাত্রাতিরিক্ত দীর্ঘ" হতে কিছু বিবেচনা করে থাকেন @RedM

— jtate

@ জজেটটি কি এটি ব্যক্তিগত পছন্দ বা আপনি কোনও অফিসিয়াল ডক অনুসরণ করছেন?

— রেড এম

@ রেডএম ব্যক্তিগত পছন্দ :)

— শে

কার্যকর জাভার তৃতীয় সংস্করণ সহ, এটি অধ্যায় 8 (পদ্ধতি), আইটেম 51

— গ্যারেথউইন

Answer 2

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

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

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

Answer 3

আপনার যদি অনেক alচ্ছিক প্যারামিটার থাকে তবে আপনি সাবলীল এপিআই তৈরি করতে পারেন: পদ্ধতির শৃঙ্খলে একক পদ্ধতি প্রতিস্থাপন করুন

exportWithParams().datesBetween(date1,date2)
                  .format("xml")
                  .columns("id","name","phone")
                  .table("angry_robots")
                  .invoke();

স্থিতিশীল আমদানি ব্যবহার করে আপনি অভ্যন্তরীণ সাবলীল এপিআই তৈরি করতে পারেন:

... .datesBetween(from(date1).to(date2)) ...

Comments

Paraচ্ছিক না হলে প্রতিটি পরামিতিগুলি কী প্রয়োজন?

— পান্না

আপনারও এভাবে ডিফল্ট প্যারামিটার থাকতে পারে। এছাড়াও, নির্মাতা প্যাটার্ন সাবলীল ইন্টারফেসের সাথে সম্পর্কিত। এটি সত্যই উত্তর হওয়া উচিত, আমি মনে করি। লম্বা কনস্ট্রাক্টরকে ছোট আরম্ভের পদ্ধতিতে ভাঙ্গা ছাড়াও যা fromচ্ছিক।

— এহতেশ চৌধুরী

Answer 4

এটিকে "প্যারামিটার অবজেক্টটি পরিচিত করা" বলা হয়। যদি আপনি নিজেকে বেশ কয়েকটি স্থানে একই পরামিতি তালিকাটি পাস করতে দেখেন তবে কেবল একটি শ্রেণি তৈরি করুন যা সেগুলি সব ধারণ করে।

XXXParameter param = new XXXParameter(objA, objB, date1, date2, str1, str2);
// ...
doSomething(param);

এমনকি যদি আপনি নিজেকে প্রায়শই একই প্যারামিটারের তালিকাটি পাস করতে না পান, তবে সহজেই পুনরুদ্ধার করা আপনার কোডের পাঠযোগ্যতার উন্নতি করবে, যা সর্বদা ভাল good আপনি যদি 3 মাস পরে আপনার কোডটি দেখে থাকেন তবে আপনার যখন কোনও বাগ ঠিক করতে বা কোনও বৈশিষ্ট্য যুক্ত করার প্রয়োজন হয় তখন তা বোঝা সহজ।

এটি অবশ্যই একটি সাধারণ দর্শন, এবং যেহেতু আপনি কোনও বিবরণ দেননি, তাই আমি আপনাকে আরও বিশদ পরামর্শ দিতে পারি না। :-)

Comments

আবর্জনা সংগ্রহের সমস্যা হবে?

— রুপিন্দরজিট

আপনি যদি কলার ফাংশনে প্যারামিটার অবজেক্টের স্থানীয় সুযোগ তৈরি করেন, এবং যদি আপনি এটি পরিবর্তন না করেন তবে। এটি সম্ভবত সংগ্রহ করা হবে এবং এরকম পরিস্থিতিতে এর স্মৃতি খুব দ্রুত ব্যবহার করা হবে।

— Dimitarvp

তবে, আপনারও একটি XXXParameter param = new XXXParameter();উপলভ্য হওয়া উচিত , এবং তারপরে ব্যবহার করুন XXXParameter.setObjA(objA); ইত্যাদি ...

— satibel

Answer 5

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

Answer 6

অবজেক্ট তৈরি করার সময় এটি প্রায়শই সমস্যা হয়।

সেক্ষেত্রে বিল্ডার অবজেক্ট প্যাটার্নটি ব্যবহার করুন , যদি আপনার পরামিতিগুলির বড় তালিকা থাকে এবং সর্বদা তাদের সমস্তের প্রয়োজন না হয় তবে এটি ভাল কাজ করে।

আপনি এটি পদ্ধতি আহ্বানের সাথেও মানিয়ে নিতে পারেন।

এটি পাঠযোগ্যতাও অনেক বাড়ায়।

public class BigObject
{
  // public getters
  // private setters

  public static class Buider
  {
     private A f1;
     private B f2;
     private C f3;
     private D f4;
     private E f5;

     public Buider setField1(A f1) { this.f1 = f1; return this; }
     public Buider setField2(B f2) { this.f2 = f2; return this; }
     public Buider setField3(C f3) { this.f3 = f3; return this; }
     public Buider setField4(D f4) { this.f4 = f4; return this; }
     public Buider setField5(E f5) { this.f5 = f5; return this; }

    public BigObject build()
    {
      BigObject result = new BigObject();
      result.setField1(f1);
      result.setField2(f2);
      result.setField3(f3);
      result.setField4(f4);
      result.setField5(f5);
      return result;
    }
  }
}

// Usage:
BigObject boo = new BigObject.Builder()
  .setField1(/* whatever */)
  .setField2(/* whatever */)
  .setField3(/* whatever */)
  .setField4(/* whatever */)
  .setField5(/* whatever */)
  .build();

আপনি বিল্ডার সেট .. () এবং বিল্ড () পদ্ধতিতে যাচাইয়ের যুক্তিও রাখতে পারেন।

Comments

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

— ragerdl

Answer 7

প্যারামিটার অবজেক্ট নামে পরিচিত একটি প্যাটার্ন রয়েছে ।

আইডিয়া হ'ল সমস্ত পরামিতিগুলির স্থানে একটি অবজেক্ট ব্যবহার করা। আপনার পরে যদি প্যারামিটার যুক্ত করার প্রয়োজন হয় তবে আপনাকে কেবল এটিতে যুক্ত করতে হবে। পদ্ধতি ইন্টারফেস একই থাকে।

Answer 8

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

Comments

আমি মনে করি না যে কোনও পদ্ধতি প্যারামিটার ধরে রাখার জন্য এটি ক্লাস তৈরি করা দরকার।

— সোয়ায়ার

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

— tvanfosson

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

— জোসকে

আমি যা বলতে চাইছিলাম তা অবশ্যই যথেষ্ট অর্থপূর্ণ হতে হবে।

— জোহানেস রুডল্ফ

Answer 9

কোড কমপ্লিট * কয়েকটি জিনিস প্রস্তাব করে:

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

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

Answer 10

ভাল অনুশীলন হবে চুল্লী। এই বিষয়গুলি সম্পর্কে কী বোঝাতে হবে যে তাদের এই পদ্ধতিতে প্রবেশ করা উচিত? সেগুলি কি কোনও একক বস্তুতে আবদ্ধ হওয়া উচিত?

Comments

হ্যাঁ তারা উচিত . উদাহরণস্বরূপ, একটি বৃহত অনুসন্ধান ফর্মটিতে অনেক সম্পর্কিত নয় const আপনি currentPageNumber, searchCriteria, pageSize ... পাস প্রয়োজন

— Sawyer কর্তৃক

Answer 11

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

একটি ক্লিনার উপায় হ'ল একটি অবজেক্টের বিনের সমস্ত পরামিতিগুলিকে গ্রুপ করা কিন্তু এটি এখনও পুরোপুরি সমস্যার সমাধান করে না।

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

প্রচুর পরামিতি প্রেরণের জন্য আপনার অ্যাপ্লিকেশনটির আরও ভাল নকশা দরকার practice

Answer 12

একটি শিম শ্রেণি তৈরি করুন, এবং সমস্ত পরামিতি (সেটার পদ্ধতি) সেট করুন এবং এই বিন বিনটিকে পদ্ধতিতে পাস করুন।

Answer 13

• আপনার কোডটি দেখুন এবং দেখুন কেন এই সমস্ত পরামিতিগুলি পাস হয়েছে Sometimes

• মানচিত্র ব্যবহার করা আপনার পদ্ধতিটিকে দুর্বল করে leaves যদি কেউ আপনার পদ্ধতি ব্যবহার করে কোনও পরামিতিটির নাম ভুল বানান করে থাকে বা আপনার পদ্ধতিটি ইউডিটি প্রত্যাশা করে এমন স্ট্রিং পোস্ট করে তবে কী হবে?

• একটি স্থানান্তর অবজেক্টের সংজ্ঞা দিন । এটি আপনাকে খুব কম সময়ে টাইপ-চেকিং সরবরাহ করবে; এমনকি আপনার পদ্ধতির পরিবর্তে আপনার ব্যবহারের স্থানে কিছু বৈধতা কার্যকর করা সম্ভবও হতে পারে।

Answer 14

এটি প্রায়শই ইঙ্গিত হয় যে আপনার ক্লাসে একের বেশি দায়িত্ব রয়েছে (যেমন, আপনার শ্রেণি খুব বেশি করে)।

দেখুন একক দায়িত্ব নীতি

বিস্তারি তথ্যের জন্য.

Answer 15

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

Answer 16

আপনি আগে যেভাবে কাজটি করেছিলেন তার সাথে আমি লাঠি বলব। আপনার উদাহরণে পরামিতিগুলির সংখ্যা খুব বেশি নয়, তবে বিকল্পগুলি আরও ভয়ঙ্কর।

1. মানচিত্র - আপনি উল্লেখ করেছেন এমন দক্ষতার জিনিসটি এখানে রয়েছে তবে এখানে আরও বড় সমস্যা হ'ল:

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

2. মোড়ানো বস্তু - এটি কেবল সমস্যাটি সরিয়ে দেয় যেহেতু আপনাকে প্রথমে র‌্যাপার বস্তুটি পূরণ করতে হবে - সরাসরি আপনার পদ্ধতির পরিবর্তে, এটি প্যারামিটার অবজেক্টের নির্মাতার কাছে হবে। সমস্যাটি সরানো উপযুক্ত কিনা তা নির্ধারণের জন্য উক্ত অবজেক্টটির পুনঃব্যবহারের উপর নির্ভর করে। এই ক্ষেত্রে:

এটি ব্যবহার করবে না: এটি শুধুমাত্র প্রথম কলটিতে একবার ব্যবহার করা হবে, তাই 1 লাইন মোকাবেলায় প্রচুর অতিরিক্ত কোড ...?

{
    AnObject h = obj.callMyMethod(a, b, c, d, e, f, g);
    SomeObject i = obj2.callAnotherMethod(a, b, c, h);
    FinalResult j = obj3.callAFinalMethod(c, e, f, h, i);
}

এটি ব্যবহার করতে পারে: এখানে, এটি আরও কিছু করতে পারে। প্রথমত, এটি 3 পদ্ধতি কলের জন্য পরামিতিগুলি ফ্যাক্টর করতে পারে। এটি নিজেও 2 টি লাইন সম্পাদন করতে পারে ... সুতরাং এটি একটি অর্থে রাষ্ট্র পরিবর্তনশীল হয়ে ওঠে ...

{
    AnObject h = obj.callMyMethod(a, b, c, d, e, f, g);
    e = h.resultOfSomeTransformation();
    SomeObject i = obj2.callAnotherMethod(a, b, c, d, e, f, g);
    f = i.somethingElse();
    FinalResult j = obj3.callAFinalMethod(a, b, c, d, e, f, g, h, i);
}

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

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

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