আচরণ নির্ধারণের জন্য বুলিয়ান প্যারামিটার ব্যবহার করা কি ভুল?

Question

আমি সময়ে সময়ে একটি অনুশীলন দেখেছি যা ভুল "অনুভব" করে, তবে এটি সম্পর্কে কী ভুল তা আমি খুব একটা উচ্চারণ করতে পারি না। অথবা এটি কেবল আমার কুসংস্কার। এখানে যায়:

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

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

Comments

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

: মার্টিন জালিয়া এই সম্পর্কে একটি নিবন্ধ আছে martinfowler.com/bliki/FlagArgument.html

— Christoffer Hammarström

এছাড়াও স্ট্যাকওভারফ্লো / প্রশ্নগুলি

— ক্রিস্টোফার হ্যামারস্ট্রিম

ক্রিস্টোফারহ্যামারস্ট্রিম ভাল লিঙ্ক link আমি আমার উত্তরে সেটিকে অন্তর্ভুক্ত করব কারণ এটি আমার বিবরণটির একই ধারণাটি বিশদভাবে ব্যাখ্যা করে।

— অ্যালেক্স

নিকের যা বলার আছে আমি তার সাথে সর্বদা একমত নই, তবে এই ক্ষেত্রে আমি 100% সম্মত: বুলিয়ান প্যারামিটার ব্যবহার করবেন না ।

— মার্জন ভেনেমা

Answer 1

হ্যাঁ, এটি সম্ভবত একটি কোডের গন্ধ, যা অনিবার্য কোডে পৌঁছায় যা বোঝা মুশকিল এবং সহজেই পুনরায় ব্যবহারের সম্ভাবনা কম রয়েছে।

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

সুতরাং একটি অত্যন্ত সমন্বিত ফাংশন কি?

এটি একটি ফাংশন যা কেবল একটি কাজ করে এবং কেবল একটি কাজ করে।

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

টাস্ক, অ্যাকশন বা কমান্ডের উদ্বেগ থেকে অ্যাক্সেস নিয়ন্ত্রণের উদ্বেগগুলি আলাদা করা ভাল।

আপনি ইতিমধ্যে উল্লেখ করেছেন যে, এই উদ্বেগগুলির মধ্যে জড়িয়ে পড়া বন্ধ মনে হচ্ছে।

সুতরাং একত্রীকরণের ধারণাটি আমাদের শনাক্ত করতে সহায়তা করে যে প্রশ্নে ফাংশনটি খুব সম্মিলিত নয় এবং আমরা আরও সংহত ফাংশনগুলির একটি সেট তৈরি করতে কোডটি রিফ্যাক্টর করতে পারি।

সুতরাং প্রশ্ন পুনরায় করা যেতে পারে; দেওয়া হয়েছে যে আমরা সকলেই আচরণগত নির্বাচনের পরামিতিগুলি পাস করার বিষয়ে একমত হয়েছি কীভাবে আমরা বিষয়গুলিতে উন্নতি করব?

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

রেফ: সংহতি (কম্পিউটার বিজ্ঞান)

Comments

রব, আপনি কি সংহততা এবং এটি কীভাবে প্রযোজ্য তার কিছু ব্যাখ্যা দেবেন?

— রায়

রায়, আমি এই সম্পর্কে যত বেশি ভাবি ততই আমার মনে হয় যে অ্যাপ্লিকেশনটিতে অ্যাক্সেস নিয়ন্ত্রণের পরিবর্তনের জন্য বুলিয়ান সুরক্ষা গর্তের উপর ভিত্তি করে আপনার কোডটিতে আপত্তি করা উচিত। কোড বেসে গুণমানের উন্নতি একটি দুর্দান্ত পার্শ্ব প্রতিক্রিয়া হবে;)

— রব

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

— রে

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

— রব

"

— কল্পনাশক্তিহীন

Answer 2

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

তবে এই নির্দিষ্ট সমস্যাটি মৌলিকভাবে পদ্ধতির পরিবর্তন না করেই খুব সহজে সমাধান করা যায়:

enum FrobnicationDirection {
  FrobnicateForwards,
  FrobnicateBackwards;
};

void frobnicate(Object what, FrobnicationDirection direction);

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

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

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

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

Comments

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

— রায়

+1 টি। আমি এটির জন্য যতটা সম্ভব এনাম ব্যবহার করি। আমি ফাংশনগুলি দেখেছি যেখানে boolপরে অতিরিক্ত পরামিতি যুক্ত করা হয়েছে এবং কলগুলি দেখতে দেখতে শুরু হয় DoSomething( myObject, false, false, true, false )। অতিরিক্ত বুলিয়ান যুক্তিগুলির অর্থ কী তা নির্ধারণ করা অসম্ভব, যদিও অর্থপূর্ণ-নামযুক্ত এনাম মান সহ এটি সহজ।

— গ্রীম পেরো

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

— অ্যালেক্স প্রিচার্ড

Answer 3

এটি অগত্যা ভুল নয় তবে এটি একটি কোড গন্ধ উপস্থাপন করতে পারে ।

বুলিয়ান প্যারামিটারগুলি সম্পর্কে যে মূল দৃশ্যটি এড়ানো উচিত তা হ'ল:

public void foo(boolean flag) {
    doThis();
    if (flag)
        doThat();
}

তারপরে কল করার সময় আপনি সাধারণত কল করতে চান foo(false)এবং foo(true)আপনার সঠিক আচরণের উপর নির্ভর করে।

এটি সত্যই সমস্যা কারণ এটি খারাপ সংহরণের ঘটনা। আপনি এমন পদ্ধতির মধ্যে নির্ভরতা তৈরি করছেন যা সত্যিই প্রয়োজনীয় নয়।

এই ক্ষেত্রে আপনার যা করা উচিত তা ছাড়ছেন doThisএবং doThatপৃথক এবং সর্বজনীন পদ্ধতি হিসাবে এটি করছেন:

doThis();
doThat();

অথবা

doThis();

এইভাবে আপনি কলিংয়ের কাছে সঠিক সিদ্ধান্তটি ছেড়ে যান (ঠিক যেন আপনি কোনও বুলিয়ান প্যারামিটারটি পার করছেন) কাপলিং তৈরি না করেই।

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

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

মার্টিন ফাউলারের একটি ভাল নিবন্ধ রয়েছে যা আরও বিশদে একই ধারণাটি ব্যাখ্যা করে।

পিএস: যদি fooদুটি সহজ পদ্ধতির কল করার পরিবর্তে পদ্ধতিটির আরও জটিল বাস্তবায়ন হয় তবে আপনাকে যা করতে হবে তা হল একটি ছোট রিফ্যাক্টরিং এক্সট্র্যাক্টিং পদ্ধতি প্রয়োগ করা যাতে ফলস্বরূপ কোডটি fooআমি লিখেছিলাম এর বাস্তবায়নের অনুরূপ ।

Comments

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

— রায়

এমন অনেকগুলি পরিস্থিতি রয়েছে যেখানে if (flag) doThat()অভ্যন্তরটি foo()বৈধ। doThat()প্রতিটি কলারকে পুনরাবৃত্তি করতে অনুরোধ করার সিদ্ধান্তকে চাপ দেওয়া যা আপনাকে পরে কিছু পদ্ধতির জন্য সন্ধান করতে পারলে অপসারণ করতে হবে, flagআচরণটিও কল করা প্রয়োজন doTheOther()। আমি পরে বরং সমস্ত কলকারীদের ঘৃণা করার চেয়ে একই ক্লাসের পদ্ধতির মধ্যে নির্ভরতা রাখি।

— blrfl

@ ব্লারফ্লাল: হ্যাঁ, আমি মনে করি যে আরও সোজা রিফ্যাক্টরিংগুলি হয় একটি পদ্ধতি doOneএবং doBothপদ্ধতি তৈরি করবে (যথাক্রমে মিথ্যা ও সত্য মামলার জন্য) বা জেমস ইয়ংম্যানের পরামর্শ অনুসারে একটি পৃথক এনাম টাইপ ব্যবহার করা

— হুগমগ

@missingno: আপনি এখনও কলারের কাছে অপ্রয়োজনীয় কোড ঠেলাঠেলি করতে এর একই সমস্যা আছে চাই doOne()বা doBoth()সিদ্ধান্ত। সাবরুটাইনস / ফাংশন / পদ্ধতিগুলির মধ্যে আর্গুমেন্ট রয়েছে যাতে তাদের আচরণে বৈচিত্র্য ঘটে। সত্যিকারের বুলিয়ান অবস্থার জন্য এনাম ব্যবহার করা নিজেকে প্রচুর পুনরাবৃত্তি করার মতো মনে হয় যদি যুক্তির নাম ইতিমধ্যে এটি কী করে তা ব্যাখ্যা করে।

— blrfl

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

— অ্যালেক্স

Answer 4

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

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

Comments

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

— রে

আপনার উত্তরটি আমাকে একটি উক্তিটির কথা মনে করিয়ে দিচ্ছে - "যদি আপনার ফাংশনটিতে 17 টি পরামিতি থাকে তবে আপনি সম্ভবত একটি অনুপস্থিত" of

— জোরিস টিমারম্যানস

আমি এর সাথে একমত হতে পারি এবং এই প্রশ্নের জন্য এই

— প্রয়োগটি

Answer 5

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

Comments

@ ড্রিজা আপনি কোঁকড়ানো আইন উল্লেখ করছেন ।

— ম্যাটডেভি

অবশ্যই অভিজ্ঞতার সাথে আপনার জানা উচিত কখন এ জাতীয় যুক্তি উপেক্ষা করবেন।

— gnasher729

Answer 6

আমি মনে করি এখানে সর্বাধিক গুরুত্বপূর্ণ জিনিসটি ব্যবহারিক হওয়া উচিত।

বুলিয়ান যখন পুরো আচরণটি নির্ধারণ করে তখন কেবল একটি দ্বিতীয় পদ্ধতি তৈরি করুন।

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

উদাহরণ স্বরূপ:

private void FooInternal(bool flag)
{
  //do work
}

public void Foo1()
{
  FooInternal(true);
}

public void Foo2()
{
  FooInternal(false);
}

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

Comments

আমি ব্যক্তিগত পদ্ধতিতে (যেমন এখানে দেখানো হয়েছে) নিয়ন্ত্রণ করতে শুধুমাত্র বুলিয়ান যুক্তি ব্যবহার করি। কিন্তু সমস্যা: যদি কোনও ডুফাস FooInternalভবিষ্যতে দৃশ্যমানতা বাড়ানোর সিদ্ধান্ত নেয় , তবে কী?

— এডিটিসি

আসলে, আমি অন্য পথে যাব। FooIntern এর কোডটি 4 টি টুকরো করে বিভক্ত করা উচিত: 2 বুলিয়ান সত্য / মিথ্যা কেস পরিচালনা করার জন্য দুটি ফাংশন, এর আগে ঘটে যাওয়া কাজের জন্য এবং অন্যটি পরে ঘটে যাওয়া কাজের জন্য। তারপর, আপনার Foo1হয়ে: { doWork(); HandleTrueCase(); doMoreWork() }। আদর্শভাবে, doWorkএবং doMoreWorkক্রিয়াকলাপগুলি বিভক্ত হওয়ার জন্য কেবল দুটি ফাংশন নয়, প্রতিটি (এক বা একাধিক) পৃথক ক্রিয়া (অর্থাত্ পৃথক ফাংশন হিসাবে) অর্থপূর্ণ অংশে বিভক্ত হয়।

— jpaugh

Answer 7

আমি নির্মাতাদের পদ্ধতিগুলির মাধ্যমে আচরণকে অনুকূলিতকরণের পদ্ধতিকে পছন্দ করি যা অপরিবর্তনীয় দৃষ্টান্তগুলি ফিরিয়ে দেয়। পেয়ারাSplitter এটি কীভাবে ব্যবহার করে তা এখানে:

private static final Splitter MY_SPLITTER = Splitter.on(',')
       .trimResults()
       .omitEmptyStrings();

MY_SPLITTER.split("one,,,,  two,three");

এর সুবিধাগুলি হ'ল:

• উচ্চতর পাঠযোগ্যতা
• বনাম ক্রিয়া পদ্ধতিতে কনফিগারেশনের পৃথক পৃথককরণ
• বস্তুটি কী, এটি কী করা উচিত এবং কী করা উচিত নয় তা ভেবে আপনাকে জোর করে সংহতি প্রচার করে। এই ক্ষেত্রে এটি একটি Splitter। আপনি কখনই someVaguelyStringRelatedOperation(List<Entity> myEntities)ক্লাসে ডাকাবেন না Splitter, তবে ক্লাসে এটি স্ট্যাটিক পদ্ধতি হিসাবে রাখার বিষয়ে আপনি ভাবেন StringUtils।
• উদাহরণগুলি প্রাক-কনফিগার করা তাই সহজে নির্ভরতা-ইনজেকটেবল। সঠিক আচরণ পাওয়ার জন্য ক্লায়েন্টকে পাস করতে হবে trueবা falseকোনও পদ্ধতিতে যেতে হবে কিনা তা নিয়ে চিন্তার দরকার নেই ।

Comments

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

— রায়

আমি কনফিগারেশন এবং অ্যাক্টন পদ্ধতি পৃথক করার ধারণা পছন্দ করি!

— Sher10ck

পেয়ারা লাইব্রেরির লিঙ্কগুলি নষ্ট হয়েছে

— জোশ নো

Answer 8

অবশ্যই একটি কোড গন্ধ । যদি এটি একক দায়িত্বের নীতি লঙ্ঘন করে না তবে এটি সম্ভবত বলুন, জিজ্ঞাসা করবেন না লঙ্ঘন করে । বিবেচনা:

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

যদি এই দুটি মূল নীতির মধ্যে কোনও একটি লঙ্ঘন না হয়ে থাকে তবে আপনার এখনও একটি এনাম ব্যবহার করা উচিত। বুলিয়ান পতাকাগুলি ম্যাজিক সংখ্যার বুলিয়ান সমতুল্য । foo(false)হিসাবে হিসাবে অনেক জ্ঞান তোলে bar(42)। এনামগুলি কৌশল প্যাটার্নের জন্য দরকারী হতে পারে এবং আপনাকে অন্য কৌশল যুক্ত করতে দেওয়ার নমনীয়তা থাকতে পারে। (কেবল তাদের নাম যথাযথভাবে মনে রাখবেন ))

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

Answer 9

TL; DR: বুলিয়ান আর্গুমেন্ট ব্যবহার করবেন না।

নিচে দেখুন কেন তারা খারাপ হয়, এবং কিভাবে তাদের প্রতিস্থাপন (বোল্ড মুখে)।

---

বুলিয়ান যুক্তিগুলি পড়া খুব শক্ত এবং এইভাবে বজায় রাখা কঠিন difficult মূল সমস্যাটি হ'ল উদ্দেশ্যটি পরিষ্কার হয় যখন আপনি সেই পদ্ধতিটির স্বাক্ষরটি পড়েন যেখানে আর্গুমেন্টটির নাম দেওয়া হয়েছে। তবে সাধারণত বেশিরভাগ ভাষায় প্যারামিটারের নামকরণের প্রয়োজন হয় না। সুতরাং আপনার মতো অ্যান্টি-প্যাটার্ন থাকবে RSACryptoServiceProvider#encrypt(Byte[], Boolean)যেখানে বুলেটিয়ান প্যারামিটার ফাংশনে কোন ধরণের এনক্রিপশন ব্যবহার করতে হবে তা নির্ধারণ করে।

সুতরাং আপনি যেমন একটি কল পাবেন:

rsaProvider.encrypt(data, true);

যেখানে পাঠককে নরকের trueআসলে কী অর্থ হতে পারে তা নির্ধারণ করার জন্য পদ্ধতির স্বাক্ষরটি সন্ধান করতে হয়। পূর্ণসংখ্যা পাস করা ঠিক ততটাই খারাপ:

rsaProvider.encrypt(data, 1);

আপনাকে যতটা বলবে - বা বরং: ঠিক তত কম। এমনকি আপনি যদি পূর্ণসংখ্যার জন্য ব্যবহারের জন্য ধ্রুবকগুলি সংজ্ঞায়িত করেন তবে ফাংশনের ব্যবহারকারীরা কেবল এগুলি উপেক্ষা করতে পারেন এবং আক্ষরিক মান ব্যবহার করতে পারেন।

এটি সমাধানের সর্বোত্তম উপায় হল একটি গণনা ব্যবহার করা । যদি আপনাকে RSAPaddingদুটি মান সহ একটি এনাম পাস করতে হয় : OAEPবা PKCS1_V1_5তারপরে আপনি তত্ক্ষণাত কোডটি পড়তে সক্ষম হবেন:

rsaProvider.encrypt(data, RSAPadding.OAEP);

---

বুলিয়ানদের কেবল দুটি মান থাকতে পারে। এর অর্থ হ'ল যদি আপনার কাছে তৃতীয় বিকল্প থাকে তবে আপনাকে নিজের স্বাক্ষরটি রিফ্যাক্টর করতে হবে। পিছনে সামঞ্জস্যতা যদি কোনও সমস্যা হয় তবে সাধারণত এটি সহজে সম্পাদন করা যায় না, সুতরাং আপনাকে অন্য পাবলিক পদ্ধতির সাথে কোনও পাবলিক ক্লাস প্রসারিত করতে হবে। মাইক্রোসফ্ট অবশেষে এটি করেছিল যখন তারা RSACryptoServiceProvider#encrypt(Byte[], RSAEncryptionPadding)বুলিয়ানের পরিবর্তে একটি গণনা (বা অন্তত একটি শ্রেণি অনুকরণের অনুকরণ করে) ব্যবহার করেছিল where

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

---

বুলিয়ান প্যারামিটারগুলিও ইঙ্গিত করতে পারে যে পদ্ধতি বা শ্রেণিটি ভালভাবে ডিজাইন করা হয়নি। উপরের উদাহরণের মতো:। নেট ব্যতীত অন্য কোনও ক্রিপ্টোগ্রাফিক লাইব্রেরি পদ্ধতিতে স্বাক্ষরে কোনও প্যাডিং পতাকা ব্যবহার করে না।

---

আমি প্রায় সমস্ত সফ্টওয়্যার গুরুগুলি পছন্দ করি যেগুলি বুলিয়ান যুক্তিগুলির বিরুদ্ধে সতর্ক করে দেয়। উদাহরণস্বরূপ, জোশুয়া ব্লচ তাদের বিরুদ্ধে অত্যন্ত প্রশংসিত বই "কার্যকর জাভা" তে সতর্ক করেছেন। সাধারণভাবে এগুলি কেবল ব্যবহার করা উচিত নয়। আপনি তর্ক করতে পারেন যে এগুলি ব্যবহার করা যেতে পারে যদি এমন একটি পরামিতি থাকে যা বোঝা সহজ। তবুও: Bit.set(boolean)সম্ভবত দুটি পদ্ধতি ব্যবহার করে আরও ভাল প্রয়োগ করা হয়েছে : Bit.set()এবং Bit.unset()।

---

আপনি যদি কোডটি সরাসরি সংশোধন করতে না পারেন তবে অন্তত তাদের আরও পাঠযোগ্য করে তুলতে আপনি ধ্রুবককে সংজ্ঞায়িত করতে পারেন :

const boolean ENCRYPT = true;
const boolean DECRYPT = false;

...

cipher.init(key, ENCRYPT);

এর চেয়ে অনেক বেশি পঠনযোগ্য:

cipher.init(key, true);

এমনকি যদি আপনি এটি চেয়েছিলেন:

cipher.initForEncryption(key);
cipher.initForDecryption(key);

পরিবর্তে.

Answer 10

আমি অবাক হয়েছি, কেউ নাম-পরামিতি উল্লেখ করেনি ।

বুলিয়ান-ফ্ল্যাগগুলির সাথে আমি যে সমস্যাটি দেখছি তা হ'ল তারা পাঠযোগ্যতার ক্ষতি করে। উদাহরণস্বরূপ, কি trueমধ্যে

myObject.UpdateTimestamps(true);

না? আমার কোন ধারণা নাই. কিন্তু কি ব্যাপারে:

myObject.UpdateTimestamps(saveChanges: true);

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

---

অবশ্যই, আপনি আপনার শ্রেণীর ব্যবহারকারীদের নামকরণ-পরামিতি ব্যবহার করতে বাধ্য করতে পারবেন না। এই কারণে, enumআপনার ডিফল্ট কেসটি কতটা সাধারণ তার উপর নির্ভর করে একটি বা দুটি পৃথক পদ্ধতি সাধারণত পছন্দনীয়। এটি ঠিক তাই। নেট কি:

//Enum used
double a = Math.Round(b, MidpointRounding.AwayFromZero);

//Two separate methods used
IEnumerable<Stuff> ascendingList = c.OrderBy(o => o.Key);
IEnumerable<Stuff> descendingList = c.OrderByDescending(o => o.Key); 

Comments

পতাকা নির্ধারণের আচরণের চেয়ে কী পছন্দনীয় তা প্রশ্নটি নয়, এটি এমন পতাকা একটি গন্ধ কিনা, এবং যদি তাই হয় তবে কেন

— রে

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

— ব্লুরাজা - ড্যানি পিফ্লুঘুফ্ট

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

— ইনগো

@ ইঙ্গো আমি রাজি নই এটি একটি জেনেরিক প্রোগ্রামিং সমস্যা; আপনি সহজেই অন্য একটি SaveBigনাম নির্ধারণ করতে পারেন । যে কোনও কোড স্ক্রু করা যেতে পারে, এই জাতীয় স্ক্রু আপ নামকরণ পরামিতিগুলির জন্য বিশেষ নয়।

— মার্টেন বোদেউয়েস

@ ইঙ্গো: আপনি যদি বোকা বেষ্টিত থাকেন তবে আপনি গিয়ে অন্য কোথাও একটি কাজ খুঁজে পাবেন। এই জাতীয় জিনিসটির জন্য আপনার কোড পর্যালোচনা রয়েছে।

— gnasher729

Answer 11

আমি এ সম্পর্কে কী ভুল তা বেশ স্পষ্ট করে বলতে পারি না।

যদি এটি কোনও কোডের গন্ধের মতো লাগে, একটি কোড গন্ধের মতো মনে হয় এবং - ভাল - একটি কোড গন্ধের মতো গন্ধ হয়, এটি সম্ভবত একটি কোডের গন্ধ।

আপনি যা করতে চান তা হ'ল:

1) পার্শ্ব প্রতিক্রিয়া সহ পদ্ধতিগুলি এড়িয়ে চলুন।

2) একটি কেন্দ্রীয়, আনুষ্ঠানিক রাষ্ট্র-মেশিন ( এই জাতীয় ) দিয়ে প্রয়োজনীয় রাজ্যগুলি পরিচালনা করুন ।

Answer 12

আমি বুলিয়ান প্যারামিটারগুলি ব্যবহারের কার্যকারিতা নির্ধারণের জন্য সমস্ত উদ্বেগের সাথে একমত; উন্নতি, পাঠযোগ্যতা, নির্ভরযোগ্যতা, জটিলতা হ্রাস, দুর্বল এনক্যাপসুলেশন এবং সংহতি থেকে ঝুঁকি হ্রাস এবং রক্ষণাবেক্ষণের সাথে মালিকানার কম মোট ব্যয়।

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

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

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

তবে এখন প্রচুর স্মৃতি এবং ওওকে স্বাচ্ছন্দ্যের সাথে এনক্যাপসুলেশন হ'ল আজ একটি প্রয়োজনীয় উপাদান তবে একটি পেনাল্টি যখন কোডটি রিয়েল টাইম এবং এসসিএডিএ মেশিন কোডের জন্য বাইটে গণনা করা হত ..

Answer 13

এটি অগত্যা ভুল নয়, তবে "ব্যবহারকারী" এর কিছু বৈশিষ্ট্যের উপর নির্ভর করে আপনার ক্রিয়াটির দৃ example় উদাহরণে আমি পতাকাটির পরিবর্তে ব্যবহারকারীর কাছে একটি রেফারেন্স দিয়ে যাব।

এটি স্পষ্ট করে এবং বিভিন্ন উপায়ে সহায়তা করে।

আমন্ত্রণমূলক স্টেটমেন্টটি যে কেউ পড়বেন তা বুঝতে পারবেন যে ব্যবহারকারীর উপর নির্ভর করে ফলাফল পরিবর্তন হবে।

শেষ পর্যন্ত বলা হয় এমন ফাংশনে আপনি আরও জটিল ব্যবসায়ের নিয়ম সহজেই প্রয়োগ করতে পারেন কারণ আপনি যে কোনও ব্যবহারকারীর বৈশিষ্ট্য অ্যাক্সেস করতে পারেন।

যদি "শৃঙ্খলে" একটি ফাংশন / পদ্ধতি ব্যবহারকারীর বৈশিষ্ট্যের উপর নির্ভর করে কিছু আলাদা করে তোলে তবে সম্ভবত এটি সম্ভবত "শৃঙ্খলে" থাকা অন্যান্য পদ্ধতির কিছুতে ব্যবহারকারীর বৈশিষ্ট্যের উপর অনুরূপ নির্ভরতা প্রবর্তিত হবে।

Answer 14

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

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

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

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

Comments

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

— মার্টেন বোদেউয়েস

Answer 15

প্রসঙ্গটি গুরুত্বপূর্ণ। আইওএস-এ এই জাতীয় পদ্ধতিগুলি বেশ সাধারণ। কেবলমাত্র ব্যবহৃত একটি উদাহরণ হিসাবে, ইউআইএনএভিগেশন কন্ট্রোলার পদ্ধতিটি সরবরাহ করে -pushViewController:animated:এবং animatedপরামিতিটি একটি বিওওএল। পদ্ধতিটি মূলত একইভাবে একইভাবে ফাংশনটি সম্পাদন করে তবে আপনি যদি হ্যাঁ পাস করেন তবে এটি একটি ভিউ কন্ট্রোলার থেকে অন্যটিতে রূপান্তরটি অ্যানিমেট করে pass এটি সম্পূর্ণ যুক্তিসঙ্গত বলে মনে হয়; এটির পরিবর্তে দুটি পদ্ধতি সরবরাহ করা নির্বোধ হবে যাতে আপনি অ্যানিমেশনটি ব্যবহার করবেন কিনা তা আপনি নির্ধারণ করতে পারেন।

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

file.saveWithEncryption(false);    // is there any doubt about the meaning of 'false' here?

Comments

প্রকৃতপক্ষে আমার কোনও উদাহরণ নেই falseযা file.saveWithEncryptionউদাহরণ বলতে বোঝায় । এর অর্থ কি এটি এনক্রিপশন ছাড়াই সংরক্ষণ করবে? যদি তা হয় তবে বিশ্বে কেন এই পদ্ধতিটি নামের সাথে "এনক্রিপশন সহ" থাকবে? আমি এর মতো একটি পদ্ধতিটি বুঝতে পারি save(boolean withEncryption), তবে আমি যখন দেখি file.save(false), এটি এক নজরে মোটেই স্পষ্ট নয় যে প্যারামিটারটি ইঙ্গিত দেয় যে এটি এনক্রিপশন সহ বা থাকবে be আমি মনে করি, বাস্তবে, এটি এনাম ব্যবহার সম্পর্কে জেমস ইয়ংম্যানের প্রথম পয়েন্টটি তৈরি করে।

— রায়

একটি বিকল্প অনুমানের falseঅর্থ হ'ল, একই নামের কোনও বিদ্যমান ফাইলকে ওভাররাইট করবেন না। কৃত্রিমুখী উদাহরণ আমি জানি, তবে আপনাকে অবশ্যই ফাংশনের জন্য ডকুমেন্টেশন (বা কোড) পরীক্ষা করতে হবে।

— জেমস ইয়ংম্যান

এমন একটি নামযুক্ত পদ্ধতি saveWithEncryptionযা কখনও কখনও এনক্রিপশন সহ সংরক্ষণ করে না একটি বাগ is এটি সম্ভবত file.encrypt().save()বা জাভাসের মতো হওয়া উচিত new EncryptingOutputStream(new FileOutputStream(...)).write(file)।

— ক্রিস্টোফার হামার্সট্রিম

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

— ক্রিস্টোফার হামার্সট্রিম

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

— ক্রিস্টোফার হামারস্ট্রিম