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

39

মতে আচরণ নির্ধারণের জন্য বুলিয়ান প্যারামিটার ব্যবহার করা কি ভুল? , আমি কোনও আচরণ নির্ধারণের জন্য বুলিয়ান প্যারামিটারগুলি ব্যবহার এড়ানোর গুরুত্ব জানি eg

মূল সংস্করণ 

public void setState(boolean flag){
    if(flag){
        a();
    }else{
        b();
    }
    c();
}

নতুন সংস্করণ:

public void setStateTrue(){
    a();
    c();
}

public void setStateFalse(){
    b();
    c();
}

তবে কীভাবে যে বুলিয়ান প্যারামিটার ব্যবহারের পরিবর্তে মানগুলি নির্ধারণ করতে ব্যবহৃত হয়? উদাহরণ:

public void setHint(boolean isHintOn){
    this.layer1.visible=isHintOn;
    this.layer2.visible=!isHintOn;
    this.layer3.visible=isHintOn;
}

আমি হিটঅন পতাকাটি অপসারণ এবং 2 টি পৃথক ফাংশন তৈরি করার চেষ্টা করছি:

public void setHintOn(){
    this.layer1.visible=true;
    this.layer2.visible=false;
    this.layer3.visible=true;
}

public void setHintOff(){
    this.layer1.visible=false;
    this.layer2.visible=true;
    this.layer3.visible=false;
}

তবে পরিবর্তিত সংস্করণটি কম রক্ষণাবেক্ষণযোগ্য বলে মনে হচ্ছে কারণ:

  1. এটির মূল সংস্করণটির চেয়ে বেশি কোড রয়েছে

  2. এটি পরিষ্কারভাবে দেখাতে পারে না যে স্তর 2 এর দৃশ্যমানতা ইঙ্গিত বিকল্পের বিপরীতে

  3. যখন একটি নতুন স্তর (উদা: স্তর 4) যুক্ত করা হয় তখন আমার যুক্ত হওয়া দরকার 

    this.layer4.visible=false;

    এবং

    this.layer4.visible=true;

    setHintOn () এবং setHintOff () এ আলাদাভাবে আলাদা করুন into

সুতরাং আমার প্রশ্নটি হল, যদি বুলিয়ান প্যারামিটারটি কেবল মানগুলি নির্ধারণ করতে ব্যবহৃত হয় তবে আচরণগুলি নয় (যেমন: me প্যারামিটারটিতে যদি অন্য কোনও নয়) তবে কী এখনও বুলিয়ান প্যারামিটারটি অপসারণ করার পরামর্শ দেওয়া হয়?

design  object-oriented-design  coding-style  parameters  boolean 
— ocomfd
সূত্র
26
ফলাফলের কোডটি আরও পঠনযোগ্য এবং বজায় রাখতে সক্ষম হয় তবে এটি কখনই ভুল নয় ;-) আমি দুটি পৃথক পদ্ধতির পরিবর্তে একক পদ্ধতি ব্যবহারের পরামর্শ দেব।
— helb
32
আপনি একটি বাধ্যতামূলক যুক্তি উপস্থাপন করেন যে এই বুলিয়ানগুলি নির্ধারণ করে এমন কোনও পদ্ধতির একক প্রয়োগের ফলে শ্রেণিটির রক্ষণাবেক্ষণ ও এর বাস্তবায়ন বোঝার ফলাফল হবে। খুব ভাল; এগুলি বৈধ বিবেচনা তবে শ্রেণীর পাবলিক ইন্টারফেসগুলিকে এগুলিকে সামঞ্জস্য করার জন্য বিকৃত করা দরকার না। যদি পৃথক পদ্ধতিগুলি জনসাধারণের ইন্টারফেসকে বুঝতে এবং তার সাথে কাজ করা আরও সহজ করে তোলে, আপনার setHint(boolean isHintOn)একটি ব্যক্তিগত পদ্ধতি হিসাবে সংজ্ঞায়িত করুন এবং সর্বজনীন setHintOnএবং setHintOffপদ্ধতিগুলি যথাক্রমে কল করুন setHint(true)এবং setHint(false)।
— মার্ক অ্যামেরি
9
আমি এই পদ্ধতির নামগুলি নিয়ে খুব অসন্তুষ্ট হব: তারা সত্যিকার অর্থে কোনও সুবিধা দেয় না setHint(true|false)। আলু পোটাওতো। কমপক্ষে setHintএবং এর মতো কিছু ব্যবহার করুন unsetHint।
— কনরাড রুডলফ
5
— 26
4
@ কেভিঙ্কলাইন শর্তটি যদি একটি নাম হয় তবে আপনি isশুরুতে লিখবেন । isValidইত্যাদি। সুতরাং কেন দুটি শব্দের জন্য যে পরিবর্তন? এছাড়াও "আরও প্রাকৃতিক" দর্শকের চোখে পড়ে। । আমার জন্য তারপর ইংরেজী বাক্য যেমন উচ্চারণ, আপনি যদি চান একটি "" মধ্যে tucked সঙ্গে "যদি ইঙ্গিত হয়" আছে আরো প্রাকৃতিক হবে
— জনাব লিস্টার

উত্তর:

95

কলিং পাশ থেকে, এপিআই নকশায় এপিআইর কোনও ক্লায়েন্টের পক্ষে সবচেয়ে বেশি ব্যবহারযোগ্য কি তা ফোকাস করা উচিত ।

উদাহরণস্বরূপ, যদি এই নতুন এপিআই এর জন্য নিয়মিত কোড লেখার জন্য কলারের প্রয়োজন হয়

if(flag)
    foo.setStateTrue();
else
    foo.setStateFalse();

তারপরে এটি স্পষ্ট হওয়া উচিত যে পরামিতি এড়ানো এপিআই থাকার চেয়ে খারাপ যা কলারকে লেখার অনুমতি দেয়

 foo.setState(flag);

পূর্ববর্তী সংস্করণটি কেবল একটি ইস্যু তৈরি করে যা তারপরে কলিং সাইডে সমাধান করতে হবে (এবং সম্ভবত একাধিকবার)। এটি না পাঠযোগ্যতা বা রক্ষণাবেক্ষণযোগ্যতা বৃদ্ধি করে না

বাস্তবায়ন পাশ অবশ্য নির্দেশ করা উচিত নয় কিভাবে পাবলিক এপিআই দেখে মনে হচ্ছে। যদি কোনও setHintপ্যারামিটারের মতো কোনও ফাংশন বাস্তবায়নে কম কোডের প্রয়োজন হয় তবে ক্লায়েন্টের জন্য শর্তাদির setHintOn/ setHintOffএআইপিআই ব্যবহার করা আরও সহজ মনে হয়, কেউ এটিকে এটি প্রয়োগ করতে পারে:

private void setHint(boolean isHintOn){
    this.layer1.visible=isHintOn;
    this.layer2.visible=!isHintOn;
    this.layer3.visible=isHintOn;
}

public void setHintOn(){
   setHint(true);
}

public void setHintOff(){
   setHint(false);
}

সুতরাং সর্বজনীন এপিআই-তে কোনও বুলিয়ান প্যারামিটার না থাকলেও এখানে কোনও সদৃশ যুক্তি নেই, সুতরাং যখন নতুন প্রয়োজনীয়তা (প্রশ্নের উদাহরণে) আসে তখন কেবলমাত্র একটি স্থান পরিবর্তন করতে পারে।

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

যদি সন্দেহ হয়, "পরীক্ষা চালিত বিকাশ" (টিডিডি) ব্যবহার করে দেখুন, এটি আপনাকে পাবলিক এপিআই এবং কীভাবে এটি ব্যবহার করবেন সে সম্পর্কে ভাবতে বাধ্য করবে।

— ডক ব্রাউন
সূত্র
ডকব্রাউন, আপনি কি উপযুক্ত বিভাজন লাইনটি বলবেন যে প্রতিটি রাজ্যের সেটিংটিতে জটিল এবং সম্ভবত অ-বিপরীত পার্শ্ব প্রতিক্রিয়া রয়েছে? উদাহরণস্বরূপ, আপনি যদি টিনের উপরে যা বলে তা কেবল টগল করে চলেছেন এবং কোনও অন্তর্নিহিত রাষ্ট্রীয় মেশিন না থাকলে আপনি বিভিন্ন রাজ্যের প্যারামিটারাইজ করতে পারেন। উদাহরণস্বরূপ, উদাহরণস্বরূপ, আপনি কোনও পদ্ধতিটিকে প্যারামিটারাইজ করবেন না SetLoanFacility(bool enabled), কারণ aণ প্রদানের পরে, এটি আবার নেওয়া সহজ হবে না এবং দুটি বিকল্পের মধ্যে সম্পূর্ণ ভিন্ন যুক্তি জড়িত থাকতে পারে - এবং আপনি পৃথক তৈরিতে যেতে চান / সরান পদ্ধতি।
— স্টিভ
15
@ স্টিভ: আপনি এখনও বাস্তবায়নের পক্ষ থেকে যে প্রয়োজনীয়তাগুলি দেখছেন সেগুলি থেকে API ডিজাইনের চেষ্টা করছেন। সোজা হতে: এটি সম্পূর্ণ অপ্রাসঙ্গিক। পাবলিক এপিআই এর যে কোনও প্রকারের ব্যবহার কলিং পক্ষ থেকে ব্যবহার করা সহজ। অভ্যন্তরীণভাবে, আপনি সর্বদা দুটি জনসাধারণের প্যারামিটার দিয়ে ব্যক্তিগতকে কল করতে দিতে পারেন। বা তদ্বিপরীতভাবে, আপনি পৃথক যুক্তি সহ দুটি ব্যক্তিগত পদ্ধতির মধ্যে একটি প্যারামিটার স্যুইচ দিয়ে একটি পদ্ধতি দিতে পারেন।
— ডক ব্রাউন 15
@ স্টিভ: আমার সম্পাদনা দেখুন।
— ডক ব্রাউন 15
আমি আপনার সমস্ত বক্তব্য গ্রহণ করি - আমি প্রকৃতপক্ষে কলারের পক্ষ থেকে এটি সম্পর্কে চিন্তাভাবনা করছি (অতএব "এটি" টিনের উপরে কী বলে "তার প্রতি আমার উল্লেখ)) এবং উপযুক্ত নিয়মটি গঠনের চেষ্টা করছি যেখানে একজন আহ্বানকারী সাধারণত প্রতিটি পদ্ধতির ব্যবহার আশা করে would আমার কাছে মনে হয়েছে যে নিয়ামকটি বারবার কলগুলি আদর্শবান হওয়ার প্রত্যাশা করে, এবং রাষ্ট্রীয় রূপান্তরগুলি নিয়ন্ত্রণহীন এবং জটিল পার্শ্ব প্রতিক্রিয়া ছাড়াই প্রত্যাশা করে whether কোনও রুমের লাইট স্যুইচ চালু এবং বন্ধ টগল করা প্যারামিটারাইজড হবে, একটি আঞ্চলিক পাওয়ার স্টেশন চালু এবং বন্ধ টগল করা একাধিক পদ্ধতি হবে।
— স্টিভ
1
@ স্টিভ সুতরাং যদি ব্যবহারকারীর একটি নির্দিষ্ট সেটিংস নিশ্চিত Toggle()করতে হয় তবে সরবরাহ করা সঠিক ফাংশন নয়। এটাই পুরো বিষয়টি; যদি কলকারী কেবল "এটিকে পরিবর্তন করুন" এবং "এটি কী হিসাবে শেষ হয়" তা নয় Toggle()তবে সেই বিকল্পটি অতিরিক্ত চেকিং এবং সিদ্ধান্ত গ্রহণ এড়ায়। আমি এটিকে একটি সাধারণ ঘটনা বলব না, বা আমি এটি কোনও উপযুক্ত কারণ ছাড়াই উপলব্ধ করার পরামর্শ দেব না, তবে যদি ব্যবহারকারীর একটি টগল প্রয়োজন হয় তবে আমি তাদের একটি টগল দেব।
— কামিল দ্রাকারী
40

মার্টিন ফোলার কেন্ট বেককে পৃথক পৃথক setOn() setOff()পদ্ধতির প্রস্তাব দেওয়ার ক্ষেত্রে উদ্ধৃতি দিয়েছিলেন , তবে আরও বলেছেন যে এটিকে অলঙ্ঘনীয় বলে বিবেচনা করা উচিত নয়:

আপনি যদি কোনও বুলিয়ান উত্স, যেমন কোনও ইউআই নিয়ন্ত্রণ বা ডেটা উত্স থেকে [sic] ডেটা টানেন তবে আমি এর setSwitch(aValue)চেয়ে বেশি চাইতাম

if (aValue)
  setOn();
else
  setOff();

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

আর একটি সুপারিশ হ'ল একটি গণনা করা মান বা পতাকা প্রকারটি প্রসঙ্গ-নির্দিষ্ট নাম দেওয়ার জন্য trueএবং falseআরও ভাল হিসাবে ব্যবহার করা। আপনার উদাহরণে, showHintএবং hideHintআরও ভাল হতে পারে।

— গ্রাহাম লি
সূত্র
16
আমার অভিজ্ঞতায় setSwitch (মান) প্রায়শই setOn / setOff এর চেয়ে কম সামগ্রিক কোডে ফলাফল দেয় কারণ আপনার উত্তরটিতে উদ্ধৃত যদি / অন্য কোডের কারণে। আমি ডেভেলপারদের অভিশাপ দেই যারা আমাকে সেটসুইচ (মান) না দিয়ে সেটঅন / সেটঅফের একটি এপিআই দেয়।
— 26
1
অনুরূপ লেন্স থেকে এটির দিকে তাকানো: মানটি কী হবে আপনার হার্ডকোডের দরকার হলে তা উভয়ের মাধ্যমেই সহজ। যাইহোক, আপনি যদি এটি সেট করার প্রয়োজন হয়, বলুন, ব্যবহারকারী ইনপুট, আপনি যদি সরাসরি মানটি সরাসরি প্রবেশ করতে পারেন তবে এটি একটি পদক্ষেপ সংরক্ষণ করে।
— নিক হার্টলি
@ 17of26 একটি কংক্রিট কাউন্টারিক্স নমুনা হিসাবে (এটি দেখানোর জন্য যে "এটি নির্ভর করে" তার চেয়ে অন্যটির চেয়ে একটি পছন্দনীয়), অ্যাপলের অ্যাপকিতে এমন একটি -[NSView setNeedsDisplay:]পদ্ধতি রয়েছে যেখানে আপনি পাস করে YESযদি কোনও ভিউ পুনরায় আঁকা উচিত এবং NOযদি তা না হয়। আপনার এটি কখনই না বলার দরকার নেই, তাই ইউআইকিটটির -[UIView setNeedsDisplay]কোনও প্যারামিটার নেই। এটি সম্পর্কিত -setDoesNotNeedDisplayপদ্ধতি নেই।
— গ্রাহাম লি
2
@ গ্রাহামলি, আমি মনে করি ফওলারের যুক্তিটি বেশ সূক্ষ্ম এবং সত্যই বিচারের উপর নির্ভর করে। আমি bool isPremiumতার উদাহরণে কোনও পতাকা ব্যবহার করব না BookingType bookingType, তবে প্রতিটি বুকিংয়ের যুক্তিটি ভিন্ন না হলে আমি একই পদ্ধতিটির পরামিতি করতে একটি এনাম ( ) ব্যবহার করব । ফাউলারের যে "জট যুক্তি" বোঝায় তা প্রায়শই কাঙ্ক্ষিত হয় যদি কেউ যদি দুটি পদ্ধতির মধ্যে পার্থক্য কী তা দেখতে সক্ষম হতে চায়। এবং যদি সেগুলি মূলত আলাদা হয় তবে আমি প্যারামিটারাইজড পদ্ধতিটি বাহ্যিকভাবে প্রকাশ করব এবং অভ্যন্তরীণভাবে পৃথক পদ্ধতিগুলি প্রয়োগ করব।
— স্টিভ
3

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

আসুন, উভয়ই এপিআই দিয়ে শুরু করা যাক:

public void setHint(boolean isHintOn)

এবং:

public void setHintOn()
public void setHintOff()

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

setHint(true)
// Do your process
…
setHint(false)

দ্বিতীয় বিকল্পটি আপনাকে এটি দেয়:

setHintOn()
// Do your process
…
setHintOff()

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

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

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

private void setHint(boolean isHintOn){
    this.layer1.visible=isHintOn;
    this.layer2.visible=!isHintOn;
    this.layer3.visible=isHintOn;
}

public void setHintOn(){
   setHint(true);
}

public void setHintOff(){
   setHint(false);
}

বিপরীতক্রমে, আসুন আমরা setHint(boolean isHintOn)আমাদের একটি API বেছে নিয়েছি তবে আসুন ইঙ্গিতটি সেট করার যে কোনও কারণেই সেটটি বন্ধ করে দেওয়ার ক্ষেত্রে সম্পূর্ণ পৃথক হওয়ার কারণে আপনার উদাহরণটি উল্টো করুন। এই ক্ষেত্রে আমরা নিম্নলিখিত হিসাবে এটি বাস্তবায়ন করতে পারে:

public void setHint(boolean isHintOn){
    if(isHintOn){
        // Set it On
    } else {
        // Set it Off
    }    
}

অথবা এমনকি:

public void setHint(boolean isHintOn){    
    if(isHintOn){
        setHintOn()
    } else {
        setHintOff()
   }    
}

private void setHintOn(){
   // Set it On
}

private void setHintOff(){
   // Set it Off 
}

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

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

— jesm00
সূত্র
3
একটি সাইড নোট হিসাবে, যদি এর সিউডো-ব্লক (এক শেষে শুরুতে বিবৃতি, এক) ভালো কিছু, আপনি সম্ভবত ব্যবহার করা উচিত beginএবং endবা প্রতিশব্দের, শুধু এটা স্পষ্টভাবে পরিষ্কার যে, তারা কি করব করতে, এবং যে একটি পরোক্ষভাবে শুরুতে একটি শেষ এবং তদ্বিপরীত থাকতে হয়।
— নিক হার্টলি
আমি নিকের সাথে একমত, এবং যোগ করব: আপনি যদি নিশ্চিত করতে চান যে শুরু এবং শেষগুলি সর্বদা মিলিত হয় তবে আপনার জন্য ভাষা-নির্দিষ্ট আইডিয়ামও সরবরাহ করা উচিত: সি ++ তে আরআইআই / স্কোপ গার্ড, usingসি # তে ব্লক, withপাইথনে স্টেটমেন্ট কনটেক্সট ম্যানেজার, পাস করা লাশ একটি ল্যামডা বা callable বস্তুর (যেমন রুবি ব্লক সিনট্যাক্স), ইত্যাদি
— ড্যানিয়েল Pryden
আমি উভয় পয়েন্টের সাথে একমত, আমি কেবলমাত্র অন্য কেসটি বর্ণনা করার জন্য একটি সাধারণ উদাহরণ দেওয়ার চেষ্টা করছিলাম (যদিও এটি উভয়ই আপনাকে দেখানো :) এটি একটি খারাপ উদাহরণ)।
— jesm00
2

প্রথম জিনিসগুলি: কোডটি স্বয়ংক্রিয়ভাবে কম রক্ষণাবেক্ষণযোগ্য হয় না, কারণ এটি কিছুটা দীর্ঘ। স্পষ্টতা যা গুরুত্বপূর্ণ।

এখন, যদি আপনি সত্যিই কেবল ডেটা নিয়েই কাজ করেন, তবে আপনার কাছে যা আছে তা বুলিয়ান সম্পত্তি জন্য একটি সেটার ter সেক্ষেত্রে আপনি কেবল সেই মানটি সরাসরি সঞ্চয় করতে এবং স্তরটির দৃশ্যমানতা অর্জন করতে চাইতে পারেন

bool isBackgroundVisible() {
    return isHintVisible;
}    

bool isContentVisible() {
    return !isHintVisible;
}

(স্তরগুলিকে প্রকৃত নাম দেওয়ার জন্য আমি স্বাধীনতা নিয়েছি - যদি আপনার মূল কোডটিতে এটি না থাকে তবে আমি এটি দিয়েই শুরু করব)

এটি এখনও একটি setHintVisibility(bool)পদ্ধতি আছে কিনা তা নিয়ে আপনাকে প্রশ্ন ছেড়ে দেয় । ব্যক্তিগতভাবে, আমি এটিকে একটি showHint()এবং hideHint()পদ্ধতিতে প্রতিস্থাপনের পরামর্শ দেব - উভয়ই সত্যই সহজ হবে এবং আপনি স্তরগুলি যুক্ত করার সময় আপনাকে এগুলি পরিবর্তন করতে হবে না। এটি কোনও সঠিক / সঠিক কাট নয়।

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

— আপনি দ্বিগুণ
সূত্র
সুতরাং tl; ডাঃ হ'ল: আপনি দুটি ফাংশনে বিভক্ত হওয়ার পরামর্শ দিচ্ছেন কারণ স্তরগুলি যুক্ত করার সময় আপনাকে সেগুলি পরিবর্তন করতে হবে না? যদি একটি স্তর 4 যুক্ত করা হয় তবে আমাদের "this.layer4.visibility = isHintOn" বলতেও পারে, সুতরাং আমি নিশ্চিত নই যে আমি সম্মত। যদি কিছু থাকে তবে এটির বিরুদ্ধে একটি মানসিক চাপ, যেমন এখন একটি স্তর যুক্ত করা হয় কেবল একটি নয়, আমাদের দুটি ফাংশন সম্পাদনা করতে হবে।
— এরদিক আয়রনরোজ
না আমি (দুর্বলভাবে) স্পষ্টতার জন্য এটি ( showHintবনাম setHintVisibility) প্রস্তাব দিই । আমি ওপিকে নিয়ে চিন্তিত হওয়ার কারণে আমি নতুন স্তরটি উল্লেখ করেছি। এছাড়াও, আমরা শুধু একটা নতুন পদ্ধতি যোগ করার জন্য প্রয়োজন: isLayer4Visible। showHintএবং hideHintকেবল isHintVisibleসত্য / মিথ্যা হিসাবে অ্যাট্রিবিউট সেট করুন এবং এটি পরিবর্তন হয় না।
— দ্বিগুণ আপনি
1
@ ডাবল ইউ, আপনি বলেন দীর্ঘতর কোডটি স্বয়ংক্রিয়ভাবে কম রক্ষণাবেক্ষণযোগ্য নয়। আমি বলব যে কোডের দৈর্ঘ্য হ'ল রক্ষণাবেক্ষণযোগ্যতা এবং স্বচ্ছতার অন্যতম প্রধান পরিবর্তনশীল, কেবল কাঠামোগত জটিলতায় ওভারটপ হয়। যে কোডগুলি দীর্ঘতর এবং কাঠামোগত জটিল হয়ে ওঠে সেগুলি অবশ্যই তার প্রাপ্য হওয়া উচিত, অন্যথায় সরল সমস্যাগুলি কোডের উপযুক্ত হওয়ার চেয়ে কোডে আরও জটিল চিকিত্সা গ্রহণ করে এবং কোডবেজ অপ্রয়োজনীয় লাইন ("অনেকগুলি স্তর নির্দেশনা" সমস্যা) কেটে নেয়।
— স্টিভ
@ স্টিভ আমি সম্পূর্ণরূপে একমত যে আপনি জিনিসগুলি বেশি ইঞ্জিনিয়ার করতে পারবেন, অর্থাত্ কোডটি আরও পরিষ্কার না করেই আরও দীর্ঘ করতে পারবেন - ওতোহ, আপনি সর্বদা স্বচ্ছতার ব্যয়ে কোডকে আরও ছোট করতে পারেন, সুতরাং এখানে 1: 1 সম্পর্ক নেই।
— ডাবলু আপনি
@Steve মনে "কোড গলফ" - এই ধরনের কোড গ্রহণ এবং আরো লাইনে এটা rewriting নেই সাধারণত স্বচ্ছ করে তুলতে। "কোড গল্ফ" একটি চূড়ান্ত, কিন্তু এখনও অনেক প্রোগ্রামার রয়েছেন যারা মনে করেন যে সমস্ত কিছুকে একটি চতুর অভিব্যক্তি হিসাবে ক্র্যামিং করা "মার্জিত" এবং সম্ভবত এটি আরও দ্রুত কারণ সংকলকরা যথেষ্ট ভালটিকে অপ্টিমাইজ করে না।
— ব্ল্যাকজ্যাক
1

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

প্রথম উদাহরণটি যদিও সমস্যাযুক্ত কারণ নামকরণটি একটি সেটার পদ্ধতি নির্দেশ করে তবে বাস্তবায়নগুলি অন্যরকম বলে মনে হয়। সুতরাং আপনার কাছে আচরণ-স্যুইচিং অ্যান্টিপ্যাটার্ন এবং একটি বিভ্রান্তিকরভাবে নামকরণ পদ্ধতি। তবে পদ্ধতিটি যদি নিয়মিত সেটার হয় (আচরণে স্যুইচিং ছাড়াই) তবে সমস্যা নেই setState(boolean)। দুটি পদ্ধতি রয়েছে setStateTrue()এবং setStateFalse()অকারণে কোনও লাভের জন্য বিষয়গুলিকে জটিল করে তুলছে।

— JacquesB
সূত্র
1

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

উদাহরণস্বরূপ, জাভাতে, আপনি এটি করতে পারেন:

public enum HintState {
    SHOW_HINT(true, false, true),
    HIDE_HINT(false, true, false);

    private HintState(boolean layer1Visible, boolean layer2Visible, boolean layer3Visible) {
         // constructor body and accessors omitted for clarity
    }
}

এবং তারপরে আপনার কলার কোডটি দেখতে এরকম হবে:

setHint(HintState.SHOW_HINT);

এবং আপনার বাস্তবায়ন কোডটি দেখতে এরকম হবে:

public void setHint(HintState hint) {
    this.layer1Visible = hint.isLayer1Visible();
    this.layer2Visible = hint.isLayer2Visible();
    this.layer3Visible = hint.isLayer3Visible();
}

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

— ড্যানিয়েল প্রাইডেন
সূত্র
0

সুতরাং আমার প্রশ্নটি হল, যদি বুলিয়ান প্যারামিটারটি কেবল মানগুলি নির্ধারণ করতে ব্যবহৃত হয় তবে আচরণগুলি নয় (যেমন: me প্যারামিটারটিতে যদি অন্য কোনও নয়) তবে কী এখনও বুলিয়ান প্যারামিটারটি অপসারণ করার পরামর্শ দেওয়া হয়?

আমার যখন এ জাতীয় বিষয় নিয়ে সন্দেহ হয়। আমি স্ট্যাক ট্রেস দেখতে কেমন তা চিত্রিত করতে চাই।

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

এখানে একটি স্ট্যাক ট্রেস উদাহরণ রয়েছে:

function visible() : line 440
function parent() : line 398
function mode() : line 384
function run() : line 5

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

এখন বুলিয়ান মানের উপর ভিত্তি করে A বা B আচরণ রয়েছে এমন একটি ক্রিয়াকলাপের জন্য স্ট্যাক ট্রেসের সাথে কাজ করার চিত্র।

function bar() : line 92
function setVisible() : line 120
function foo() : line 492
function setVisible() : line 120
function run() : line 5

আমাকে জিজ্ঞাসা করলে তা বিভ্রান্তিকর। একই setVisibleলাইন দুটি আলাদা ট্রেস পাথ দেয় yield

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

এখানে কিছু টিপস রয়েছে:

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

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

— Reactgular
সূত্র
1
setVisibleস্ট্যাক ট্রেস সম্পর্কে আমার কাছে বিভ্রান্তিকর বিষয়টি হ'ল যে কলিংয়ের setVisible(true)ফলে কল আসে setVisible(false)(বা অন্যভাবে আপনি কীভাবে সেই ট্রেসটি পেয়েছিলেন তার উপর নির্ভর করে)।
— ডেভিড কে
0

booleanকোনও কিছুর আচরণ পরিবর্তন করার জন্য আপনি পতাকা হিসাবে একটি পদ্ধতিতে একটি পরামিতি দিয়ে যাচ্ছেন এমন প্রায় প্রতিটি ক্ষেত্রেই আপনার আরও কিছু বিবেচনা করা উচিত স্পষ্ট এবং টাইপসেফ উপায় ।

আপনি যদি ব্যবহার ব্যতীত আর কিছু না করেন Enum রাষ্ট্রের প্রতিনিধিত্ব করে এমন যা আপনি আপনার কোডের বোঝার উন্নতি করেছেন।

এই উদাহরণটি Nodeক্লাসটি থেকে ব্যবহার করে JavaFX:

public enum Visiblity
{
    SHOW, HIDE

    public boolean toggleVisibility(@Nonnull final Node node) {
        node.setVisible(!node.isVisible());
    }
}

অনেক JavaFXবস্তুতে পাওয়া মত এর চেয়ে সর্বদা ভাল :

public void setVisiblity(final boolean flag);

তবে আমি মনে করি .setVisible()এবং পতাকাটি.setHidden() এমন অবস্থার সর্বোত্তম সমাধান solution একটি হল booleanযেমন সবচেয়ে স্পষ্ট এবং অন্তত বাগাড়ম্বরপূর্ণ হয়।

একাধিক নির্বাচনের সাথে কোনও কিছুর ক্ষেত্রে এটি এইভাবে করা আরও বেশি গুরুত্বপূর্ণ। EnumSetশুধুমাত্র এই কারণে বিদ্যমান।

এড মানের ঠিক এই বিষয়ে একটি ভাল ব্লগ পোস্ট রয়েছে। আমি যা বলি ঠিক তেমনই আমি প্যারাফ্রেজ করতে যাচ্ছিলাম, তাই অনুলিপি প্রয়াস না করে আমি এই উত্তরটির সংযোজন হিসাবে কেবল তার ব্লগ পোস্টে একটি লিঙ্ক পোস্ট করব ।

0

যখন কোনও ইন্টারফেসের জন্য কোনও পদ্ধতির মধ্যে সিদ্ধান্ত নেওয়ার সময় (বুলিয়ান) প্যারামিটার বনাম ওভারলোডেড পদ্ধতিগুলি ডাব্লু / ও প্যারামিটারটি বলে, তখন গ্রাহকরা ক্লায়েন্টদের দিকে তাকাবেন।

যদি সমস্ত ব্যবহারগুলি ধ্রুবক মানগুলি (যেমন সত্য, মিথ্যা) পাস করে তবে তা ওভারলোডগুলির পক্ষে যুক্তি দেয়।

যদি সমস্ত ব্যবহারের একটি ভেরিয়েবল মান পাস হয় তবে প্যারামিটার পদ্ধতির সাথে সেই পদ্ধতির পক্ষে যুক্তি রয়েছে।

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

— এরিক tদ
সূত্র
আপনি যদি একটি সমন্বিত সিস্টেম নকশা করব এবং আপনি হয় পরিণামে উভয় কোড প্রযোজক এবং কোডের "গ্রাসকারী ক্লায়েন্ট"? একজন গ্রাহক গ্রাহকের জুতোতে দাঁড়িয়ে একজন ব্যক্তির কীভাবে অন্যের থেকে এক পদ্ধতির জন্য তাদের অগ্রাধিকারটি নির্ধারণ করা উচিত?
— স্টিভ
@ স্টিভ, গ্রাহক ক্লায়েন্ট হিসাবে আপনি জানেন যে আপনি একটি ধ্রুবক বা পরিবর্তনশীল পাস করছেন কিনা not ধ্রুবকগুলি যদি পাস হয় তবে ওভারলোডগুলি w / o পরামিতিটি পছন্দ করুন prefer
— এরিক tদ
তবে কেন বিষয়টি হওয়া উচিত তা আমি উচ্চারণে আগ্রহী। কেন বেশিরভাগ ভাষায় এই ধরণের উদ্দেশ্যটির জন্য সুনির্দিষ্টভাবে নকশাকৃত ডিজাইনের তৈরির কারণে সীমিত সংখ্যক কনস্ট্যান্টের জন্য এনামগুলিকে নিয়োগ করবেন না?
— স্টিভ
@ স্টিভ, যদি আমরা ডিজাইনের সময় / সংকলনের সময় জানতে পারি যে ক্লায়েন্টরা সব ক্ষেত্রেই একটি ধ্রুবক মান (সত্য / মিথ্যা) ব্যবহার করে, তবে তার থেকে বোঝা যায় যে একটি সাধারণীকরণ পদ্ধতির পরিবর্তে সত্যিই দুটি পৃথক নির্দিষ্ট পদ্ধতি রয়েছে (এটি একটি প্যারামিটার নেয়)। প্যারামিটারাইজড পদ্ধতির সাধারণতা প্রবর্তনের বিরুদ্ধে তর্ক করব যখন এটি ব্যবহৃত হয় না - এটি একটি YAGNI যুক্তি।
— এরিক tদ
0

নকশা করার জন্য দুটি বিবেচনা রয়েছে:

  • এপিআই: আপনি কোন ইন্টারফেস ব্যবহারকারীর সামনে উপস্থাপন করেন,
  • বাস্তবায়ন: স্পষ্টতা, প্রধানত্ব, ইত্যাদি ...

তাদের বিবাদ করা উচিত নয়।

এটি পুরোপুরি ঠিক:

  • একক প্রয়োগের জন্য API প্রতিনিধিতে একাধিক পদ্ধতি রয়েছে,
  • শর্তের উপর নির্ভর করে একাধিক বাস্তবায়নে এপিআই প্রেরণের একটি পদ্ধতি আছে।

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

এপিআই সাইডে

প্রোগ্রামার হিসাবে আমি সাধারণত প্রোগ্রামযোগ্য এপিআইয়ের পক্ষে থাকব। কোডটি তখন আরও স্পষ্ট হয় যখন কোন ফাংশনটি কল করতে হবে তা ঠিক করার জন্য যখন মানটির if/ switchস্টেটমেন্টের প্রয়োজন হয় তার চেয়ে যখন আমি কোনও মান ফরোয়ার্ড করতে পারি ।

পরেরটি প্রয়োজনীয় হতে পারে যদি প্রতিটি ফাংশন বিভিন্ন যুক্তি প্রত্যাশা করে।

আপনার ক্ষেত্রে, এইভাবে, একটি একক পদ্ধতি setState(type value) আরও ভাল বলে মনে হচ্ছে।

তবে সেখানে নামহীন চেয়ে খারাপ কিছু নয় true, false, 2, ইত্যাদি ... ঐ যাদু মান তাদের নিজস্ব কোন অর্থ আছে। আদিম আবেগ এড়ানো এবং শক্ত টাইপিং আলিঙ্গন করুন।

সুতরাং, একটি API অপেশাদার থেকে, আমি চাই: setState(State state)।

বাস্তবায়ন পক্ষের দিকে

আমি যা কিছু সহজ তা করার পরামর্শ দিই।

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

অবশেষে, গ্রুপিং বিবেচনা করুন ।

আপনার উদাহরণে (পঠনযোগ্যতার জন্য যুক্ত সাদা অংশ সহ):

this.layer1.visible = isHintOn;
this.layer2.visible = ! isHintOn;
this.layer3.visible = isHintOn;

layer2বকিং ট্রেন্ড কেন ? এটি একটি বৈশিষ্ট্য বা এটি একটি বাগ?

2 টি তালিকা [layer1, layer3]এবং কীভাবে তাদের একত্রে গোষ্ঠীভুক্ত করা হয়েছে তার কারণের [layer2]সাথে একটি সুস্পষ্ট নাম যুক্ত করা সম্ভব এবং তারপরে সেই তালিকাগুলি পুনরাবৃত্তি করতে পারে।

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

for (auto layer : this.mainLayers) { // layer2
    layer.visible = ! isHintOn;
}
for (auto layer : this.hintLayers) { // layer1 and layer3
    layer.visible = isHintOn;
}

কোডটি নিজের পক্ষে কথা বলে, এটি দুটি গ্রুপ এবং তাদের আচরণের পার্থক্য কেন তা পরিষ্কার ।

— ম্যাথিউ এম।
সূত্র
0

setOn() + setOff()বনাম set(flag)প্রশ্ন থেকে পৃথকভাবে , আমি এখানে বুলিয়ান প্রকারটি সবচেয়ে ভাল কিনা তা আমি সাবধানতার সাথে বিবেচনা করব। আপনি কি নিশ্চিত যে কোনও তৃতীয় বিকল্প কখনই থাকবে না?

এটি বুলিয়ানের পরিবর্তে এনাম বিবেচনা করা উপযুক্ত। এক্সটেনসিবিলিটির অনুমতি দেওয়ার পাশাপাশি এটি বুলেটিয়ানকে ভুল উপায়ে পাওয়া আরও শক্ত করে তোলে যেমন:

setHint(false)

বনাম

setHint(Visibility::HIDE)

এনামের সাহায্যে, কেউ যখন সিদ্ধান্ত নেন যে তারা যদি 'যদি প্রয়োজন হয়' বিকল্প চান তবে তাদের প্রসারিত করা আরও সহজ হবে:

enum class Visibility {
  SHOW,
  HIDE,
  IF_NEEDED // New
}

বনাম

setHint(false)
setHint(true)
setHintAutomaticMode(true) // New
— ফিল
সূত্র
0

... এর মতে, আমি কোনও আচরণ নির্ধারণের জন্য বুলিয়ান প্যারামিটারগুলি ব্যবহার এড়ানোর গুরুত্ব জানি

আমি এই জ্ঞানটির পুনরায় মূল্যায়ন করার পরামর্শ দেব।

প্রথমত, আমি এই সিদ্ধান্তটি দেখতে পাচ্ছি না যে আপনি যে SE টি লিঙ্ক করেছেন তাতে আপনি প্রস্তাব দিচ্ছেন। তারা বেশিরভাগ পদ্ধতি কলের বিভিন্ন ধাপে একটি পরামিতি ফরোয়ার্ড করার বিষয়ে কথা বলছেন, যেখানে এটি চেইনের নিচে খুব মূল্যায়ন করা হয়।

আপনার উদাহরণে, আপনি ঠিক আপনার পদ্ধতিতে প্যারামিটারটি মূল্যায়ন করছেন। সেই ক্ষেত্রে, এটি অন্য কোনও ধরণের প্যারামিটারের থেকে একেবারেই পৃথক নয়।

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

— AnoE
সূত্র
0

প্রশ্নের সংজ্ঞা দেওয়া হচ্ছে

আপনার শিরোনাম প্রশ্ন "এটি কি ভুল [[]]?" - তবে "ভুল" বলতে আপনার কী বোঝ?

কোনও সি # বা জাভা সংকলক অনুসারে, এটি ভুল নয়। আমি নিশ্চিত আপনি এটি সম্পর্কে অবগত এবং আপনি যা জিজ্ঞাসা করছেন এটি তা নয়। আমি এর বাইরেও ভয় পাই, আমাদের কেবল nপ্রোগ্রামারদের n+1বিভিন্ন মতামত রয়েছে। ক্লিন কোড বইটি এই সম্পর্কে কী বলে তা এই উত্তরটি উপস্থাপন করে ।

উত্তর

ক্লিন কোড সাধারণভাবে ফাংশন আর্গুমেন্টের বিরুদ্ধে একটি শক্তিশালী মামলা করে:

যুক্তিগুলি শক্ত। তারা প্রচুর ধারণাগত শক্তি গ্রহণ করে। [...] আমাদের পাঠকরা যতবার দেখেছে ততবার এটি ব্যাখ্যা করতে হবে।

এখানে একটি "পাঠক" এপিআই গ্রাহক হতে পারেন। এটি পরবর্তী কোডারও হতে পারে, যারা এখনও জানেন না যে এই কোডটি এখনও কী করে - যা এক মাসে আপনি হতে পারেন। তারা হয় 2 টি আলাদাভাবে বা 1 ফাংশনের মধ্য দিয়ে দু'বার , একবার রাখবেন trueএবং একবার falseমনে রাখবেন।
সংক্ষেপে, যতটা সম্ভব আর্গুমেন্ট ব্যবহার করুন ।

পতাকা আর্গুমেন্টের নির্দিষ্ট ক্ষেত্রে পরে সরাসরি সম্বোধন করা হয়:

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

আপনার প্রশ্নের সরাসরি উত্তর দেওয়ার
জন্য: ক্লিন কোড অনুসারে , সেই পরামিতিটি অপসারণ করার পরামর্শ দেওয়া হয়।

অতিরিক্ত তথ্য:

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

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

if (isAfterSunset) light.TurnOn();
else light.TurnOff();

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

আপনি টেস্টিং করেন কিনা তা আমি জানি না - সেক্ষেত্রে এটিকেও বিবেচনা করুন:

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

— আর। স্মিটজ
সূত্র
আপনি এখানে লিডটি সত্যিই সমাহিত করেছেন: "... আপনার প্রথম বাক্যে" কোনও আচরণ নির্ধারণের জন্য বুলিয়ান প্যারামিটারগুলি ব্যবহার করা এড়ানোর [sic] গুরুত্ব "উল্লেখ করা হচ্ছে এবং এটি পুরো প্রশ্নের ভিত্তি। আমি দেখছি না এপিআই ব্যবহারকারীর পক্ষে এটি করা সহজ যা খারাপ তা করার একটি কারণ "। এটি একটি আকর্ষণীয় বিষয়, তবে আপনি বরং নিজের শেষ অনুচ্ছেদে নিজের যুক্তিটিকে ক্ষুণ্ন করেছেন।
— ওয়াইল্ডকার্ড
লাড্ডি দাও? এই উত্তরের মূলটি হ'ল "যতটা সম্ভব ছোট যুক্তি ব্যবহার করুন", যা এই উত্তরের প্রথমার্ধে ব্যাখ্যা করা হয়েছে। তার পরে সমস্ত কিছু কেবলমাত্র অতিরিক্ত তথ্য: একটি বিবাদী তর্ককে খণ্ডন করা (অন্য ব্যবহারকারী দ্বারা, ওপি নয়) এবং এমন কিছু যা প্রত্যেকের জন্য প্রযোজ্য নয়।
— আর স্মিটজ
শেষ অনুচ্ছেদটি কেবল পরিষ্কার করার চেষ্টা করছে যে শিরোনামের প্রশ্নের উত্তর দেওয়ার মতো যথেষ্ট সংজ্ঞা দেওয়া হয়নি। ওপি জিজ্ঞাসা করেছে এটি "ভুল" কিনা, তবে কে বা কোনটি অনুসারে তা বলে না। সংকলক অনুসারে? বৈধ কোড বলে মনে হচ্ছে, তাই ভুল নয়। ক্লিন কোড বই অনুসারে? এটি একটি পতাকা যুক্তি ব্যবহার করে, তাই হ্যাঁ এটি "ভুল"। যাইহোক, আমি পরিবর্তে "প্রস্তাবিত" লিখি, কারণ বাস্তববাদী> কৌতুকপূর্ণ। আপনি কি মনে করেন আমার আরও পরিষ্কার করে দেওয়া দরকার?
— আর স্মিটজ
সুতরাং অপেক্ষা করুন, আপনার উত্তরটির প্রতিরক্ষা কি শিরোনাম প্রশ্নের উত্তর দেওয়া খুব অস্পষ্ট? : ডি ঠিক আছে ... আমি আসলে আমার মনে হয়েছিল যে পয়েন্টটি উদ্ধৃত করেছি তা একটি আকর্ষণীয় তাজা গ্রহণ।
— ওয়াইল্ডকার্ড
1
স্পষ্টত এখন পরিষ্কার; সাবাশ!
— ওয়াইল্ডকার্ড
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.