কোনও নির্মাণকারীর মধ্যে কোনও বস্তুর সমস্ত কাজ করার কি কোনও কারণ আছে?


49

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

আমাদের সংস্থা যেমন বড় হয়েছে, আমরা ঘরে বসে আমাদের আরও বিকাশ করার চেষ্টা করেছি। এই বিশেষ প্রকল্পটি আমার কোলে পৌঁছেছে তাই আমি এটির উপর দিয়ে যাচ্ছি, এটি পরিষ্কার করছি, পরীক্ষা যোগ করছি, ইত্যাদি etc.

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

উদাহরণস্বরূপ, (কোডটি জাভাতে রয়েছে, যদি তা গুরুত্বপূর্ণ হয় তবে আমি আশা করি এটি আরও সাধারণ প্রশ্ন হবে):

public class Foo {
  private int bar;
  private String baz;

  public Foo(File f) {
    execute(f);
  }

  private void execute(File f) {
     // FTP the file to some hardcoded location, 
     // or parse the file and commit to the database, or whatever
  }
}

যদি আপনি ভাবছেন, এই ধরণের কোডটি প্রায়শই নিম্নলিখিত পদ্ধতিতে কল করা হয়:

for(File f : someListOfFiles) {
   new Foo(f);
}

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

আমি কেন ঠিকাদারটিকে জিজ্ঞাসা করেছি যে এটি কেন এইভাবে করা হয়েছিল এবং আমি যে প্রতিক্রিয়া পেয়েছি তা হ'ল "আপনি চাইলে আমরা এটি পরিবর্তন করতে পারি"। যা সত্যই সহায়ক ছিল না।

যাইহোক, কোনও প্রোগ্রামিং ভাষায় এই জাতীয় কিছু করার কোনও কারণ আছে, নাকি ডেইলি ডব্লিউটিএফের কাছে এটি কেবল অন্য জমা?


18
আমার কাছে দেখে মনে হচ্ছে এটি এটি এমন বিকাশকারীদের দ্বারা লিখেছিল যারা জানেন public static void main(string[] args)এবং যারা বস্তুর কথা শুনেছেন, তারপরে সেগুলি একসাথে ম্যাশ করার চেষ্টা করেছিলেন।
অ্যান্ডি হান্ট

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

4
সম্পর্কিত প্রশ্ন: এর নির্মাণকারীর একটি শ্রেণির মূল কাজটি করতে কোনও সমস্যা? । এটির থেকে কিছুটা আলাদা, যদিও তৈরি উদাহরণটি পরে ব্যবহার করা হয়।
sleske


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

উত্তর:


60

ঠিক আছে, তালিকার নীচে যাচ্ছি:

আমাকে অনেক আগেই শিখানো হয়েছিল যে একটি লুপে ইনস্ট্যান্টেটেড অবজেক্টগুলি সাধারণত একটি খারাপ ধারণা

আমি যে কোনও ভাষা ব্যবহার করেছি তা নয়।

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

সাধারণভাবে, যদি কোনও লুপের মধ্যে আপনার কোনও প্রয়োজন হয় তবে একটি তৈরি করুন।

নির্মাণকারীদের ন্যূনতম কাজ করা উচিত

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

কোনও প্রোগ্রামিং ভাষায় এই জাতীয় কিছু করার কি কখনও কারণ আছে, নাকি ডেইলি ডব্লিউটিএফের কাছে এটি কেবল অন্য জমা?

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

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

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

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

3
সংক্ষিপ্ত সংস্করণ: বস্তু ইনস্ট্যান্টেশনগুলি যেমন কোনও ফাংশন ছিল সেগুলি ব্যবহার করবেন না।
এরিক রেপেন

27

আমার জন্য, আপনি যখন কনস্ট্রাক্টরে কোনও কাজ করার মতো কোনও জিনিস পান তখন এটি অবাক হওয়ার মতো বিষয় মাত্র, তবে কেবলমাত্র আমি এর বিরুদ্ধে সুপারিশ করব (অন্তত বিস্ময়ের নীতি)।

একটি ভাল উদাহরণ এ চেষ্টা :

আমি নিশ্চিত না যে এই ব্যবহারটি কোনও বিরোধী-প্যাটার্ন কিনা, তবে সি # তে আমি কোডটি দেখেছি যা কিছুটা উদাহরণস্বরূপ তৈরি করা হয়েছে:

using (ImpersonationContext administrativeContext = new ImpersonationContext(ADMIN_USER))
{
    // Perform actions here under the administrator's security context
}
// We're back to "normal" privileges here

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

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

আপনার উদাহরণে মন্তব্য:

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

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


1
আপনার ভাল উদাহরণ রিসোর্স বরাদ্দকরণের একটি উদাহরণ হ'ল সূচনা । এটি সি ++ এ প্রস্তাবিত প্যাটার্ন কারণ এটি ব্যতিক্রম-নিরাপদ কোড লিখতে অনেক সহজ করে তোলে। যদিও এটি সি # তে বহন করে কিনা জানি না। (এক্ষেত্রে বরাদ্দ করা "সম্পদ" হ'ল প্রশাসনিক সুযোগ-সুবিধা))
zwol

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

14

না।

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

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


7

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

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

এটি আরও ভাল হবে যদি ফাংশনটি কোনও পাবলিক পদ্ধতিতে স্থানান্তরিত করা হয় এবং তারপরে ক্লাসের কোনও উদাহরণ দেওয়া হয়, তবে বার বার লুপ কল করতে হবে।


4

কোনও নির্মাণকারীর মধ্যে কোনও বস্তুর সমস্ত কাজ করার কি কোনও কারণ আছে?

না।

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

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

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

1
"যদি না তাদের বলা না করা হয় তবে ভবিষ্যতের প্রোগ্রামাররা এই কনস্ট্রাক্টর কলগুলিকে ডিফেন্সিভ কোডের সাথে ঘিরে রাখতে আগ্রহী হবে না।" - ভাল যুক্তি.
গ্রাহাম 18

2

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

সুতরাং আমি অনুমান করি যে তিনি কেবল একটি শর্টকাট ব্যবহার করেছেন এবং একটি ফাংশন প্রতিস্থাপন হিসাবে সরাসরি একটি ক্লাস ব্যবহার করেছিলেন। আপনি যখনই ফাংশনটি সম্পাদন করতে চান, আপনি কেবল ক্লাসটি ইনস্ট্যান্ট করুন।

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


3
আমি নিশ্চিত যে এই বিশেষ প্রোগ্রামার 'ফাংশনাল প্রোগ্রামিং' শব্দটি কখনও শুনেনি pretty
কেনে

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

1

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


1

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

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

এমনকি কোনও ইউটিলিটি শ্রেণি সহ, বেশিরভাগ লোকেরা নেস্টেড স্ট্যাটিক ক্লাসগুলি ভাবেন না (এবং এটি ভাষার উপর নির্ভর করে সম্ভবত সম্ভবও হবে না)।

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

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


1

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

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

var parser = XMLParser()
var x = parser.parse(string)
string a = x.LookupTag(s)

আসলে এর চেয়ে ভাল আর কিছু নয়

 var x = ParsedXML(string)
 string a = x.LookupTag(s)

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

x.UpdateView(v)

আপনি অবজেক্টে অ্যাকসেসরের মাধ্যমে একাধিক রিটার্ন মান তৈরি করতে পারেন। সমস্ত কাজ সম্পন্ন হয়েছে, তবে আমি সমস্ত কিছু প্রসঙ্গে চাই এবং আমি আমার ফাংশনে একাধিক তথ্য উল্লেখ করতে চাই না।

var x = new ComputeStatistics(inputFile)
int max = x.MaxOptions;
int mean = x.AverageOption;
int sd = x.StandardDeviation;
int k = x.Kurtosis;
...

সুতরাং একটি যৌথ পাইথন / সি # প্রোগ্রামার হিসাবে, এটি আমার কাছে সমস্ত অদ্ভুত বলে মনে হয় না।


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

1

একটি কেস মনে আসে যেখানে কনস্ট্রাক্টর / ডেস্ট্রাক্টর সমস্ত কাজ করে:

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

রানটাইম লাইব্রেরি বাগ প্যাচ করার জন্য আমি কেবল কনস্ট্রাক্টর-বিট কোডের পরিমাণের জন্য যা লিখেছি। (প্রকৃতপক্ষে কোড ঠিক করার ফলে অন্যান্য সমস্যা দেখা দিতে পারে There) প্যাচটি পূর্বাবস্থায় ফেরানোর প্রয়োজন নেই বলে কোনও ডেস্ট্রাক্টর ছিল না।


-1

আমি অ্যান্ডি বুশের সাথে একমত এটি জ্ঞানের কিছু অভাব বলে মনে হচ্ছে।

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


-4

"আমাকে অনেক আগেই শিখানো হয়েছিল যে একটি লুপে ইনস্ট্যান্টেটেড অবজেক্টগুলি সাধারণত একটি খারাপ ধারণা"

হ্যাঁ, আপনি হয়ত স্মরণ করছেন যে কেন আমাদের স্ট্রিংবিল্ডার প্রয়োজন।

জাভা দুটি স্কুল আছে।

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

এইটা খারাপ

byte[] array = new byte[kilos or megas]
for_loop:
  use(array)

এটা ভাল.

for_loop:
  byte[] array = new byte[kilos or megas]
  use(array)

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

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

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

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

এখন, যখন ফাংশনাল প্রোগ্রামিং প্লে হয়, অবজেক্ট তৈরি করা আরও সহজ হয়ে যায়। আপনি প্রতিটি পদক্ষেপে শ্বাসকষ্ট হিসাবে অবজেক্ট তৈরি করবেন, এমনকি এটিকে লক্ষ্য না করে। সুতরাং, আমি আশা করি আপনার কোডটি নতুন যুগে আরও "দক্ষ" হয়ে উঠবে

"আপনার কনস্ট্রাক্টরে কিছু করবেন না এটি কেবল আরম্ভের জন্য"

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


3
ব্যাখ্যাটি সুসংগঠিত নয় এবং অনুসরণ করা শক্ত। আপনি কেবল প্রতিযোগিতামূলক দৃser়তার সাথে পুরো জায়গা জুড়ে যান যার প্রসঙ্গে কোনও লিঙ্ক নেই।
নিউ আলেকজান্দ্রিয়া

সত্যিকারের প্রতিযোগিতামূলক বক্তব্যটি হ'ল "কনস্ট্রাক্টরগণকে কোনও বস্তুর ক্ষেত্রগুলি ইনস্ট্যান্ট করতে হবে এবং অবজেক্টটি ব্যবহারের জন্য প্রস্তুত করার জন্য প্রয়োজনীয় অন্য কোনও সূচনা করা উচিত"। এটি সর্বাধিক জনপ্রিয় অবদানকারীকে বলুন।
Val,
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.